TINA Reference Points become
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

TSAS: PowerPoint PPT Presentation


  • 73 Views
  • Uploaded on
  • Presentation posted in: General

TINA Reference Points become an OMG Standard Presentation to the TINA 2000 Conference. TSAS:. Marcel Mampaey, Alcatel [email protected] Linda Strick, GMD Fokus [email protected] Overview of the presentation and Structure of Submitted Document.

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Tsas

TINA Reference Points become

an OMG StandardPresentation to the TINA 2000 Conference

TSAS:

Marcel Mampaey, Alcatel

[email protected]

Linda Strick, GMD Fokus

[email protected]


Overview of the presentation and structure of submitted document

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)


Objectives

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.


Submitters

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


Tsas and parlay

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


Tsas and tina

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


Tsas

  • 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)


Response to rfp requirements

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


Tsas

  • 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)


Tsas architecture

TSAS Architecture

General principle

Domain X

Domain Y

User

Provider

Provider

User


Tsas architecture1

TSAS Architecture

Business Model

Consumer

Domain

ServiceProviderDomain

RetailerDomain

Subscriber

End-User


Segmentation principles

Domains

, segments

and interfaces

Domain A

Domain B

Domain C

Example of a segment

Segmentation principles


Segments framework

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


Segments defined in tsas

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


Tsas

  • 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)


Tsas domains and roles

Consumer

Domain

ServiceProviderDomain

RetailerDomain

Subscriber

End-User

TSAS Domains and Roles


Tsas domains and roles1

Initial

Authentication

Access

These are symmetrical interfaces

TSAS Domains and Roles

Provider

User


Tsas domains and roles2

Consumer

Domain

ServiceProviderDomain

RetailerDomain

Subscriber

End-User

Same interfaces re-used here

TSAS Domains and Roles


Service access

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


Tsas phases

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


  • Tsas phases initial contact

    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


    Tsas client contacts tsas provider application level authentication

    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)


    Tsas client contacts tsas provider corba security used for authentication

    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


    Tsas client contacts tsas provider mutual authentication

    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)


    Operations on access interface

    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 ( ) ; };


    Tsas

    • 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)


    Some naming conventions

    ServiceProviderDomain

    Consumer

    RetailerDomain

    Domain

    Ret

    Ret

    SP

    SP

    Cons

    Ret

    Ret

    SP

    Some naming conventions

    Business Model


    Tsas

    • 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)


    Subscription business model

    Subscription business model

    Subscriber

    Signs contract about service

    usage

    Authorize

    Uses services

    Retailer

    User


    Tsas

    Subscription business model con’t

    Service Provider subscription

    Sign contract about service

    retailing

    Provide service

    Service Provider

    Retailer


    Subscription segments

    Subscription Segments

    Consumer

    RetailerDomain

    Domain

    Subscriber/

    End-User

    Admin

    ServiceProviderDomain

    Service Provider

    Admin

    Subscriber

    End-User

    Customiza

    tion

    End-User


    Simple subscription

    : 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


    Subscription with user management

    : 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


    Tsas

    • 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)


    Compliance points

    Compliance points

    • Three compliance points defined:

      • Core segment

      • Service access segments

      • Subscription segments


    Tsas

    Thank you for your attention


  • Login