TSAS:

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 Presentation to the TINA 2000 ConferenceConference

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

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

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:

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

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 Architecture

Domain Y

General principle

Provider

User

Domain X

Provider

User

TSAS Architecture

ServiceProviderDomain

RetailerDomain

ConsumerDomain

Business Model

Subscriber

End-User

Segmentation principles

Domain A Domain B Domain C

Domains and interfaces

Example of a segment

, segments

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

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 Domains and Roles


RetailerDomain

ConsumerDomain

Subscriber

End-User


User Provider

Initial

Authentication

Access

These are symmetrical interfaces



RetailerDomain

ConsumerDomain

Subscriber

End-User

Same interfaces re-used here

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

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

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.

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)

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)

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.

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

};

Some naming conventions


RetailerDomain

ConsumerDomain

RetCons

RetRet

SPRet

SPSP

Business Model







Subscription Segment (section 6)


Subscription business model

Subscriber

Retailer

User

Signs contract about service

usage

Uses services

Authorize

Service Provider subscription

Service Provider

Retailer

Sign contract about service retailing

Subscription business model con’t

Provide service

Subscription Segments


RetailerDomain

ConsumerDomain

Subscriber

End-User

Subscriber/

End-UserAdmin

End-UserCustomiza

tion

Service ProviderAdmin

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)

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







Subscription Segment (section 6)


Compliance points

Three compliance points defined:

Core segment

Service access segments

Subscription segments

TSAS:

Documents

Transcript of TSAS: