"TSAS- TINA reference points become an OMG standard"

Page 1

:TSAS:TSAS

Linda Strick, GMD [email protected]

Marcel Mampaey, [email protected]

TINA Reference Points becomeTINA Reference Points become

an OMG Standardan OMG Standard

Presentation to the TINA 2000 ConferencePresentation to the TINA 2000 Conference

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

Page 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.

Page 4

Submitters

◆ 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

Also supported by:

Page 5

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

Page 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

Page 7









Page 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

Page 9









Page 10

TSAS Architecture

Domain Y

General principle

Provider

User

Domain X

Provider

User

Page 11

TSAS Architecture

ServiceProviderDomain

RetailerDomain

ConsumerDomain

Business Model

Subscriber

End-User

Page 12

Segmentation principles

Domain A Domain B Domain C

Domains and interfaces

Example of a segment

, segments

Page 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

Page 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

Page 15









Page 16

TSAS Domains and Roles


RetailerDomain

ConsumerDomain

Subscriber

End-User

Page 17


User Provider

Initial

Authentication

Access

These are symmetrical interfaces

Page 18



RetailerDomain

ConsumerDomain

Subscriber

End-User

Same interfaces re-used here

Page 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

Page 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

Page 21

TSAS phases: initial contact

TSAS Client DfTsas::Initial

Initial Contact

TSAS Client gains areference to DfTsas::Initialof TSAS Provider

Authentication

initiate_authentication( ) Client initiates Authentication.CORBA Security, TSASAuthentication, or anothermethod may be used

request_access( )Access(start ofaccess phase)

Client requests anaccess interface.TSAS Accessinterface is returned.

Page 22

TSAS Client DfTsas::Initial DfTsas::Authentication

DfTsas::Access

Initial Contact


TSAS Client contacts TSAS Provider(application level authentication)

initiate_authentication( )

select_auth_method( )

authenticate( )

( authenticate( ) )

Authentication

request_access( )Access(start ofaccess phase)

Page 23

TSAS Client contacts TSAS Provider(CORBA Security used for authentication)

request_access( ) CORBA Security is identified as themechanism used to authenticate domains.DfTsas::Authentication interfacesare not used.

TSAS Client DfTsas::Initial DfTsas::Access

Initial Contact


Authentication

Access(start ofaccess phase)

Page 24

DfTsas::Authentication (on Provider)

TSAS Client DfTsas::InitialDfTsas::Authentication (on client)

TSAS Provider

initiate_authentication( ) TSAS Client's DfTsas::Authentication reference is passed to TSAS Provider, and its DfTsas::Authentication is returned.

TSAS Client contacts TSAS Provider(mutual authentication)

select_auth_method( )

authenticate( )

authenticate( )

This is an example of a sequenceof authenticate operations. Differentauthentication protocols may havedifference requirements on the order ofoperations.

( authenticate( ) )

( authenticate( ) )

request_access( ) If TSAS Client supports DfTsas::Access itfce,its reference is passed to TSAS Provider.TSAS Provider's i_tsasAccess is returned.

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

};

Page 26









Page 27

Some naming conventions


RetailerDomain

ConsumerDomain

RetCons

RetRet

SPRet

SPSP

Business Model

Page 28







◆ Subscription Segment (section 6)


Page 29

Subscription business model

Subscriber

Retailer

User

Signs contract about service

usage

Uses services

Authorize

Page 30

Service Provider s ubs cription

Service Provider

Retailer

Sign contract about service retailing

Subscription business model con’t

Provide service

Page 31

Subscription Segments


RetailerDomain

ConsumerDomain

Subscriber

End-User

/Subs criber-End Us er

Admin

-End Us erCus tomiza

tion

ServiceProviderAdmin

Page 32

Simple Subscription

: SubscriberMgmt

:ServiceProfileMgmt : ServiceTemplate

Mgmt

: ServiceContract

Mgmt : Subscriber : Service

Provider

1: deploy_service(in ProviderId, in ServiceTemplate)

2: create_subscriber(in Subscriber)

3: create_service_contract(in SubscriberId, in ServiceContract)

assign profile

(service or contract)

to subscriber4: assign(in SubscriberId, in SAGId, in ServiceProfileId)

Page 33

Subscription with user management

6: create_sag(in SubscriberId, in SAG, in UserIdList)

9: modify_user_service_profile(in SubscriberId, in UserId, in ServiceTemplateId, in PropertyList)

: Subscriber : End User

: UserDescriptionMgmt

: ServiceProfileMgmt : SAGMgmt

7: create_service_profile(in SubscriberId, in ServiceProfileId, in ServiceProfile)

8: assign(in SubscriberId, in SAGId, in ServiceProfileId)repeat for each

service profile

5: create_user(in SubscriberId, in UserDescription)

Repeat foreach user

Page 34







◆ Subscription Segment (section 6)


Page 35

Compliance points

◆ Three compliance points defined:

■ Core segment

■ Service access segments

■ Subscription segments

Page 36