1 / 36

TSAS:

TINA Reference Points become an OMG Standard Presentation to the TINA 2000 Conference. TSAS:. Marcel Mampaey, Alcatel marcel.mampaey@alcatel.be. Linda Strick, GMD Fokus strick@fokus.gmd.de. Overview of the presentation and Structure of Submitted Document.

danil
Télécharger la présentation

TSAS:

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TINA Reference Points become an OMG StandardPresentation to the TINA 2000 Conference TSAS: Marcel Mampaey, Alcatel marcel.mampaey@alcatel.be Linda Strick, GMD Fokus strick@fokus.gmd.de

  2. Overview of the presentationand Structure of Submitted Document • Objectives of the submission (section 1) • Submitters (section 1) • Response to RFP Requirements (section 2) • Architecture (section 3) • Core Segment (section 4) • Service Access Segments (section 5) • Subscription Segments (section 6) • Compliance Points (section 8)

  3. Objectives • The service requested consists of standardized interfaces and mechanism for • enabling end-users to access and configure a telecommunication service according to their wishes and • to allow value-added service providers to offer their services to End-users. • It manages contracts for end-users and service providers, • locates matches between user requirements and service providers subscription offers • enables the establishment of mutually anonymous, but authenticated, access between end-user and service provider.

  4. Submitters Also supported by: • Alcatel • AT&T • Deutsche Telekom AG • GMD Fokus • Hitachi • Lucent Technologies • Nippon Telegraph andTelephone Corporation • Nortel Networks • Siemens AG • British Telecommunications plc. • Cisco Systems • Humboldt University • IBM TelecommunicationsIndustry • KPN Royal Dutch Telecom • Sprint • Sun Microsystems

  5. Parlay Group Create an open Application Programming Interface (API) that would enable secure, public access to core capabilities of telecommunication and data networks. Members: AT&T, BT, Cegetel, Cisco, Ericsson, IBM, Lucent, Microsoft, Nortel Networks, Siemens, and Ulticom (formerly DGM&S) Release 2.1 out now TSAS: Core part fed into Release 2.0 / 2.1 -> compliant Intend to keep Parlay and TSAS consistent for Service Access and Subscription Provide ‘points of flexibility’ where different approaches are possible e.g. Authentication TSAS and Parlay

  6. TSAS and TINA • Most of the specification is based on TINA specs, BUT: • The entire specification is re-structured according to the flexible ‘segment’ concept and to OMG guidelines, and modernized according to contributors validation work • Core segment is strongly modified and simplified, and aligned with corresponding Parlay 2.1 specs. • Service access segments are re-structured and simplified (over-specification suppressed) • Subscription segments are re-structured and simplified, information model is updated according to recent evolutions • TSAS specs are fed-back to TINA for endorsement by TINA • Liaison to ITU-T after spec stabilization in OMG for aligningthe Q series supplements 27 and 28

  7. Objectives of the submission (section 1) • Submitters (section 1) • Response to RFP Requirements (section 2) • Architecture (section 3) • Core Segment (section 4) • Service Access Segments (section 5) • Subscription Segments (section 6) • Compliance Points (section 8)

  8. Response to RFP requirements • Relationship to existing OMG specifications • Mandatory requirements • Retailer administration interface requirements • Initial access related interface requirements • Service access related interface requirements • Optional requirements • Issues to be discussed • From the points above: none • Security

  9. Objectives of the submission (section 1) • Submitters (section 1) • Response to RFP Requirements (section 2) • Architecture (section 3) • Core Segment (section 4) • Service Access Segments (section 5) • Subscription Segments (section 6) • Compliance Points (section 8)

  10. TSAS Architecture General principle Domain X Domain Y User Provider Provider User

  11. TSAS Architecture Business Model Consumer Domain ServiceProviderDomain RetailerDomain Subscriber End-User

  12. Domains , segments and interfaces Domain A Domain B Domain C Example of a segment Segmentation principles

  13. Segments Framework • The segment is an optional set of functions • A segment can be activated and de-activated with Framework operations • One segment corresponds to either • one set of interface(s) on one domain • two such sets of interface(s), each on one of thepeer domains • The segments are limited to access functionality,access related functionality (such as invitations),or subscription related functionality

  14. Segments defined in TSAS • Core segment (mandatory) • Service access segments • Invitation segment • Context • Access Control • Subscription segments • Subscriber administration • Service provider administration • Service Discovery • Session Control • End-user administration • End-user customization

  15. Objectives of the submission (section 1) • Submitters (section 1) • Response to RFP Requirements (section 2) • Architecture (section 3) • Core Segment (section 4) • Service Access Segments (section 5) • Subscription Segments (section 6) • Compliance Points (section 8)

  16. Consumer Domain ServiceProviderDomain RetailerDomain Subscriber End-User TSAS Domains and Roles

  17. Initial Authentication Access These are symmetrical interfaces TSAS Domains and Roles Provider User

  18. Consumer Domain ServiceProviderDomain RetailerDomain Subscriber End-User Same interfaces re-used here TSAS Domains and Roles

  19. Service Access • Service Access: • A consistent approach to allowing users to access telecoms services in a controlled and secure way. • Three Phases: • Initial Contact • Authentication • Access

  20. TSAS phases • Initial Contact • allow both domains to initiate interaction • interface: DfTsas::Initial • Authenticate • allow both domains to authenticate the identity of the other domain • interface: DfTsas::Authenticate • not used if CORBA security is available • Access • allow both domains to access interfaces and services • interface: DfTsas::Access

  21. TSAS Client DfTsas::Initial TSAS Client gains areference to DfTsas::Initialof TSAS Provider Initial Contact initiate_authentication( ) Client initiates Authentication.CORBA Security, TSASAuthentication, or anothermethod may be used Authentication request_access( ) Client requests anaccess interface.TSAS Accessinterface is returned. Access(start ofaccess phase) TSAS phases: initial contact

  22. DfTsas::Access DfTsas:: TSAS Client DfTsas::Initial Authentication TSAS Client gains areference to DfTsas::Initialof TSAS Provider Initial Contact initiate_authentication( ) Authentication select_auth_method( ) authenticate( ) ( authenticate( ) ) Access(start ofaccess phase) request_access( ) TSAS Client contacts TSAS Provider(application level authentication)

  23. TSAS Client contacts TSAS Provider(CORBA Security used for authentication) DfTsas::Access TSAS Client DfTsas::Initial TSAS Client gains areference to DfTsas::Initialof TSAS Provider Initial Contact Access(start ofaccess phase) request_access( ) CORBA Security is identified as themechanism used to authenticate domains.DfTsas::Authentication interfacesare not used. Authentication

  24. DfTsas::Authentication DfTsas::Authentication (on Provider) TSAS Client DfTsas::Initial TSAS Provider (on client) TSAS Client's DfTsas::Authentication reference is passed to TSAS Provider, and its DfTsas::Authentication is returned. initiate_authentication( ) select_auth_method( ) This is an example of a sequenceof authenticate operations. Differentauthentication protocols may havedifference requirements on the order ofoperations. authenticate( ) authenticate( ) ( authenticate( ) ) ( authenticate( ) ) If TSAS Client supports DfTsas::Access itfce,its reference is passed to TSAS Provider.TSAS Provider's i_tsasAccess is returned. request_access( ) TSAS Client contacts TSAS Provider(mutual authentication)

  25. Operations on Access interface • After successful authentication, an access session exists, and the Access interface is available: • Interface Access{ void select_service ( ) ; void sign_service_agreement ( ) ; void end_session ( ) ; void list_segments ( ) ; void get_segment ( ) ; void release_segments ( ) ; void end_access ( ) ; };

  26. Objectives of the submission (section 1) • Submitters (section 1) • Response to RFP Requirements (section 2) • Architecture (section 3) • Core Segment (section 4) • Service Access Segments (section 5) • Subscription Segments (section 6) • Compliance Points (section 8)

  27. ServiceProviderDomain Consumer RetailerDomain Domain Ret Ret SP SP Cons Ret Ret SP Some naming conventions Business Model

  28. Objectives of the submission (section 1) • Submitters (section 1) • Response to RFP Requirements (section 2) • Architecture (section 3) • Core Segment (section 4) • Service Access Segments (section 5) • Subscription Segment (section 6) • Compliance Points (section 8)

  29. Subscription business model Subscriber Signs contract about service usage Authorize Uses services Retailer User

  30. Subscription business model con’t Service Provider subscription Sign contract about service retailing Provide service Service Provider Retailer

  31. Subscription Segments Consumer RetailerDomain Domain Subscriber/ End-User Admin ServiceProviderDomain Service Provider Admin Subscriber End-User Customiza tion End-User

  32. : ServiceContract Mgmt :ServiceProfile Mgmt : ServiceTemplate Mgmt : Subscriber Mgmt : Service Provider : Subscriber 1: deploy_service(in ProviderId, in ServiceTemplate) 2: create_subscriber(in Subscriber) 3: create_service_contract(in SubscriberId, in ServiceContract) 4: assign(in SubscriberId, in SAGId, in ServiceProfileId) assign profile (service or contract) to subscriber Simple Subscription

  33. : ServiceProfile Mgmt : UserDescrip tionMgmt : SAGMgmt : Subscriber : End User 5: create_user(in SubscriberId, in UserDescription) Repeat for each user 6: create_sag(in SubscriberId, in SAG, in UserIdList) 7: create_service_profile(in SubscriberId, in ServiceProfileId, in ServiceProfile) repeat for each 8: assign(in SubscriberId, in SAGId, in ServiceProfileId) service profile 9: modify_user_service_profile(in SubscriberId, in UserId, in ServiceTemplateId, in PropertyList) Subscription with user management

  34. Objectives of the submission (section 1) • Submitters (section 1) • Response to RFP Requirements (section 2) • Architecture (section 3) • Core Segment (section 4) • Service Access Segments (section 5) • Subscription Segment (section 6) • Compliance Points (section 8)

  35. Compliance points • Three compliance points defined: • Core segment • Service access segments • Subscription segments

  36. Thank you for your attention

More Related