idnits 2.17.1 draft-lecorgne-pint-tina-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 399 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 56 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'VP' on line 190 -- Looks like a reference, but probably isn't: 'PS' on line 190 -- Looks like a reference, but probably isn't: 'PBX' on line 190 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Abdul Akram, Sprint 2 Expiration: 06 January 1998 Anastasius Gavras, Deutsche Telekom AG 3 06 July 1998 Gilles Lecorgne, France Telecom 4 draft-lecorgne-pint-tina-00.txt 6 A TINA service architecture experiment in 7 Internet / PSTN interworking 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as ``work 20 in progress.'' 22 Abstract 24 Nowadays, Internet offers different information and communication 25 services (web pages, email, file transfer, IP telephony, ...). The use 26 of those services increases significantly. Internet trends to become 27 the major multimedia and communication application support. On the 28 other side, PSTN (Public Switched Telephone Network) services are 29 commonly used with high quality, performance and security , and they 30 evolve with a lot of value added services (free call, call waiting, 31 vocal mail, ...). But today, there are few interactions between 32 Internet services and PSTN services. In that way, it is very 33 interesting to develop new services which offer synergy as defined 34 by the PSTN / Internet Inter-Networking (PINT) working group. 35 Internet and PSTN are considered to be two different business 36 domains. So, it is necessary to identify the interfaces for the 37 interworking. 38 The TINA (Telecommunication Information Networking Architecture) 39 architecture is a common software architecture for information and 40 telecommunication services, defined by the TINA consortium. The 41 architecture is applicable to different services (telephony, video 42 on demand, Web, ...) and different transport networks (IP, PSTN, ATM, 43 ...). 44 This internet draft is about the use of TINA architecture in the 45 development of a common control platform for the Internet / PSTN 46 interworking. Our aim is to apply TINA service architecture for both 47 internet and PSTN service platforms in order to allow interactions. 49 The TINA architecture is first introduced. The architecture of our 50 experiment is described ; and the relevant contributions for PINT 51 are identified. 53 Table of contents 54 1. Introduction 56 2. TINA service architecture 58 3. Internet / PSTN architecture experiment 60 4. Services components interfaces 62 5. Conclusion 64 6. References 66 7. Authors' Information 68 1 Introduction 70 The objective of the PINT WG is to define an architecture and a 71 protocol, considering security issues, to offer services like click- 72 to-dial, click-to-fax. In reference to the figure 1, The PINT 73 protocol (1) is independent of the underlying network functions (2) 74 which could be IN, with INAP (Intelligent Network Application 75 Protocol) interface, or PBX (Private Automatic Branch eXchange), 76 with CTI (Computer Telephony Integration) interface. In the context 77 of the PINT charter, this draft consists in identifying how the TINA 78 service architecture can be used to offer a protocol to control the 79 public switched telephone network services from the internet. 81 _____ _______________ ________________ 82 |____| | | | | 83 /++++/ ---(1)---| PINT Platform |+++(2)++| CSN* functions | 84 PINT client |_______________| |________________| 85 CSN : Circuit Switching Network 86 Figure 1. General Architecture 88 The TINA architecture has been specified by the TINA-C consortium. 89 Its main objectives were to define a common software architecture to 90 increase the development of new telecommunication and information 91 services, along with service synergy. Three architectures are 92 defined : the service architecture, the network architecture and the 93 DPE (Distributed Processing Environment) architecture. In the PINT 94 context, the service architecture [1] is more precisely described. 96 In our experiment, two different gateways were developed in order to 97 interact with an IN equipment and with a PBX equipment. The 98 interface between the internet client and the TINA platform, which 99 is needed for the PINT protocol, is highlighted. 101 2. TINA architecture 103 Architecture 104 TINA business model defines the different domains related to 105 information and communication services, and particularly : consumer, 106 retailer, connectivity provider and third party service provider. 108 _________ ________ ___________________________ 109 |Consumer | |Retailer| |3rd party service provider | 110 --------- ---------- --------------------------- 111 ______________________ 112 |Connectivity Provider | 113 ---------------------- 115 In addition, it identifies and specifies reference points between 116 domains. The protocol between the internet client and the PINT 117 platform relates to the Consumer/Retailer reference point in order 118 to establish a secure access and to initiate the usage of service ; 119 and a usage relationship between Consumer and 3rd party service 120 provider is used for the service logic execution. 122 The TINA service architecture defines the concept of access and 123 usage. The access part includes the messages to initiate a session 124 as a secure and authenticated relationship. Then, the access session 125 controls the context of the access and the relative consumer profile 126 in order to request services. One example is the access to an 127 Internet Access Provider. 129 The usage part concerns the way to control the usage of a service 130 and to support management capabilities like accounting. It is 131 included in a service session. It is split in generic interfaces 132 which are common for different types of services (multi-parties 133 control, accounting, ...) and in service logic specific interfaces. 134 One example is the request of a Video-conference service. 136 If the service execution needs explicit usage of network resources, 137 in order to exchange information flows, then it sets up a 138 communication session. The communication session manages the logical 139 link with network resources, independently of the underlying 140 network. One example is the setup of an ISDN link for video and 141 audio transport. 143 The TINA service architecture defines the service components for the 144 above functions. They are specified with the language IDL/OMG 145 (Interface Definition Language of the Object Management Group). It 146 allows to define the architecture independently of the different 147 technologies for the implementation (operating system, language, 148 network, ...). 150 3. Internet / PSTN architecture experiment 152 The TINA service architecture is applicable to the domains of 153 Internet and PSTN/IN. The experiment has been completed for the Tina 154 Test Trial. The TINA Test Trial is a project involving Global One 155 partners (DT, FT, Sprint and Global One) and aiming at validating 156 the TINA concepts and architecture through a large-scale prototype 157 (France, Germany and USA). This project started at the beginning of 158 1997. A prototype is available now. 160 One of the advantages of TINA architecture is that service 161 components are deployed on a same control network and they can 162 interact as their interfaces are open. In the context of the PINT 163 services, the interaction consists in giving access to the PSTN / IN 164 services through the internet. The architecture is as below : 166 PS : Programmable Switch 167 VP : Voice Peripheral 168 (1) IIOP 169 (2) HTTP 170 (3) VP API / Corba gateway 171 (4) INAP-like / Corba gateway 172 (5) CTI / Corba gateway 174 user terminal 175 _____ __________________________________________ 176 |____| | --------------- TINA Control Platform | 177 /++++/ --(1)-------|| Authentication | (over Corba DPE) | 178 | | ---------------- ---------------- | 179 (2) __ | | User Profile | | 180 |_ | |(1)| ---------------- | 181 |_| | -------------------- | 182 web server | | Service Session Mgr| ---------------- | 183 | -------------------- |..TINA component| | 184 | ---------------- | 185 |__________________________________________| 186 /(3)\ /(4)\ /(5)\ 187 \___/ \___/ \___/ 188 | | | 189 | | | 190 [VP] [PS] [PBX] 191 | | | 192 |___________ | ______| 193 o^o | | / o^o 194 /__\=============== [CO]=============/__\ 196 Figure 2. Experiment Architecture 198 The access is under the control of a TINA platform which identifies 199 and authenticates the user. Depending on the access terminal (PC, 200 phone, ...) and on the user profile and authorization, services are 201 made available : electronic mail, web service, call completion, 202 voice mail, ... 204 The platform allows the use of services like click-to-dial and 205 voice-access-to-content. And in order to control the different 206 network equipments, a gateway between IIOP and a programmable switch 207 with INAP-like protocol (4) and a gateway between IIOP and a pbx 208 with CTI protocol (5) are deployed. 210 Infrastructure 211 TINA service components are deployed on a DPE (Distributed 212 Processing Environment) platform. The DPE is Corba 2.0 (Common 213 Object Request Broker Architecture) compliant. In addition, the use 214 of CORBA2.0 interoperability architecture, namely GIOP (Generic 215 Inter-ORB Protocol) specialized as IIOP (Internet Inter-ORB 216 Protocol) over TCP/IP, offers universal signaling protocol for all 217 component interactions and provides transparent distribution 218 depending on traffic, load balancing or users locations, ... 219 Indeed, if the user's terminal is 'intelligent' (i.e. off-the- 220 shelves terminals with 'Java/Corba' capabilities) then it can 221 execute some service components and interact directly with the 222 control platform. The use of a protocol like Corba2.0 allows to 223 offer secure and transactional features as the session persists 224 while the link between a client and an object server is still 225 active. This is difficult to achieve with a protocol like HTTP which 226 is a native stateless protocol for the request of hypertext document 227 and which has not been designed to specify interactions for 228 controlling the access to networks and services. In the case of a 229 dump terminal, gateways can be deployed in the network and be used 230 on its behalf. 232 For the internet access, the application protocol between the 233 terminal and the TINA platform are IIOP (1) or HTTP (2). In the case 234 of HTTP, a gateway is used to translate HTTP messages into IIOP 235 messages and to maintain the access session context. 237 Scenario 239 Click-to-Dial scenario 240 An example of service is a web-based phone directory. The user is 241 connected to the platform and consulting a directory in order to 242 find the callee reference. He can click a button to request a call 243 completion. 244 The service request is sent to the TINA platform. It checks the 245 authorization and a service session is created. Then the service 246 identifies the user phone number with his profile and requests the 247 call setup with the callee, from a communication session manager. As 248 the control platform is distributed (DT, FT, Sprint control points), 249 and depending on call parties locations, the communication session 250 manager can control network functions in an optimized way. In 251 addition, the call status can be delivered to the client and 252 information can be managed, such as the billing party, date/time to 253 complete the call, ... 255 Voice access to web content scenario 257 As in the previous scenario, the user is connected to the platform 258 and consults a web page. A specific request can establish a phone 259 call with the user and send the voice translation of the HTML page. 260 The service request is sent to the TINA platform which checks the 261 authorization and starts a service session. The service identifies 262 the user phone number with his profile and requests the call setup, 263 with a voice peripheral, from a communication session manager. The 264 communication session manager controls the network functions. When 265 the call is set up, the service session requests the translation of 266 the page content, that is played by the voice peripheral. 268 4. Service components of the experiment 269 Access : 270 The interfaces of the access part are the ones defined in the Ret 271 reference point [2]. It concerns the interactions between the 272 consumer domain and the retailer domain : secure access 273 initialization, identification & authentication, request of service 274 session and authorization checking, ... 276 usage : 277 The usage of a service is under the control of a service session. 278 The interfaces defined for the PINT services are specific to our 279 experiment. 280 But the goal is not to define a new protocol. PINT protocol will be 281 defined from the SIP/SDP (Session Initiation Protocol / Session 282 Description Protocol). In fact, our view is to contribute to define 283 those service usage interfaces based on SIP for example, ie to 284 define the IDL interfaces which correspond to the SIP messages. The 285 difference is not so important since the service invitation 286 interfaces in the Ret reference point are defined according to the 287 SIP standard. 289 The figure below summarizes the interfaces for the PINT context. 291 ______ 292 |User| 293 ------ 294 ********** ********** 295 * Access * * Usage * 296 * Ret RP * * SIP/IDL* 297 ********** ********** 298 ____________________ 299 | | 300 | PINT | 301 | | 302 | functions | 303 | | 304 -------------------- 305 *************** 306 * IN protocol * 307 *************** 308 ____________________ 309 | | 310 | IN functions | 311 | (SCF, SRF, ...) | 312 -------------------- 313 Figure 3. Interfaces 315 5. Conclusion 316 The aims of our experiment were to develop a platform prototype of 317 TINA service architecture for Internet and PSTN access and to 318 identify its interest to offer synergy between Internet and PSTN 319 services. 321 One output of the experiment is that a common architecture, TINA, 322 can be used for different domains : Internet and IN. Also, the 323 conformity to reference points allows different control platforms 324 (DT, FT, Sprint) to cooperate. In addition, the use of the Corba 325 architecture allows to define a service component by their 326 interfaces and then to offer their access through a common 327 communication protocol which is independent of its location and the 328 underlying infrastructure. It enables an easy interworking between 329 Internet and PSTN services. 331 Then, our contributions are about security, interface and protocol 332 issues. 333 The access part interfaces are defined by the Ret reference point. 334 The usage part interfaces could be defined by IDL interfaces from 335 SIP/SDP messages. 336 The security concerns first a secure identification and 337 authentication relative to the access session, and secondly, the 338 authorization for the service usage. 339 In the experiment, the IIOP protocol is used to offer a common 340 service interaction protocol. 342 6. References 343 [1] TINA-C consortium, " Service Architecture - Version 5.0 ", June 344 1997. 346 [2] TINA-C consortium, " Ret Reference Point Specifications - 347 Version 1.0 ", January 1998 349 7. Authors Information 350 Abdul Akram 351 E-mail : Abdul.Akram@mail.sprint.com 352 Telephone : +1-913-534-5586 353 Fax : +1-913-534-2526 355 Anastasius Gavras 356 E-mail : gravras@tzd.telekom.de 357 Telephone : +49 6151 83-1369 358 Fax : +49 6151 83-4484 360 Gilles Lecorgne 361 E-mail : Gilles.Lecorgne@cnet.francetelecom.fr 362 Telephone : +33 2 96 06 35 38 363 Fax : +33 2 96 05 37 84 365 Internet Draft TINA architecture and PSTN/Internet Interworking 367