TSAS:
description
Transcript of TSAS:
![Page 1: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/1.jpg)
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 Presentation to the TINA 2000 ConferenceConference
![Page 2: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/2.jpg)
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: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/3.jpg)
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: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/4.jpg)
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:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/5.jpg)
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:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/6.jpg)
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: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/7.jpg)
Page 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)
![Page 8: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/8.jpg)
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: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/9.jpg)
Page 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)
![Page 10: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/10.jpg)
Page 10
TSAS Architecture
Domain Y
General principle
Provider
User
Domain X
Provider
User
![Page 11: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/11.jpg)
Page 11
TSAS Architecture
ServiceProviderDomain
RetailerDomain
ConsumerDomain
Business Model
Subscriber
End-User
![Page 12: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/12.jpg)
Page 12
Segmentation principles
Domain A Domain B Domain C
Domains and interfaces
Example of a segment
, segments
![Page 13: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/13.jpg)
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: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/14.jpg)
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: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/15.jpg)
Page 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)
![Page 16: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/16.jpg)
Page 16
TSAS Domains and Roles
ServiceProviderDomain
RetailerDomain
ConsumerDomain
Subscriber
End-User
![Page 17: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/17.jpg)
Page 17
TSAS Domains and Roles
User Provider
Initial
Authentication
Access
These are symmetrical interfaces
![Page 18: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/18.jpg)
Page 18
TSAS Domains and Roles
ServiceProviderDomain
RetailerDomain
ConsumerDomain
Subscriber
End-User
Same interfaces re-used here
![Page 19: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/19.jpg)
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:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/20.jpg)
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:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/21.jpg)
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:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/22.jpg)
Page 22
TSAS Client DfTsas::Initial DfTsas::Authentication
DfTsas::Access
Initial Contact
TSAS Client gains areference to DfTsas::Initialof TSAS Provider
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:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/23.jpg)
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
TSAS Client gains areference to DfTsas::Initialof TSAS Provider
Authentication
Access(start ofaccess phase)
![Page 24: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/24.jpg)
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: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/25.jpg)
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: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/26.jpg)
Page 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)
![Page 27: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/27.jpg)
Page 27
Some naming conventions
ServiceProviderDomain
RetailerDomain
ConsumerDomain
RetCons
RetRet
SPRet
SPSP
Business Model
![Page 28: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/28.jpg)
Page 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)
![Page 29: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/29.jpg)
Page 29
Subscription business model
Subscriber
Retailer
User
Signs contract about service
usage
Uses services
Authorize
![Page 30: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/30.jpg)
Page 30
Service Provider subscription
Service Provider
Retailer
Sign contract about service retailing
Subscription business model con’t
Provide service
![Page 31: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/31.jpg)
Page 31
Subscription Segments
ServiceProviderDomain
RetailerDomain
ConsumerDomain
Subscriber
End-User
Subscriber/
End-UserAdmin
End-UserCustomiza
tion
Service ProviderAdmin
![Page 32: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/32.jpg)
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: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/33.jpg)
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: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/34.jpg)
Page 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)
![Page 35: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/35.jpg)
Page 35
Compliance points
Three compliance points defined:
Core segment
Service access segments
Subscription segments
![Page 36: TSAS:](https://reader036.fdocuments.us/reader036/viewer/2022062422/56813ad6550346895da31429/html5/thumbnails/36.jpg)
Page 36