Internet Draft INTERNET-DRAFT Networking Working Group L. Conroy Internet Draft M. Lautenbacher, Expires on 7 January 1998 R. Scholl Roke Manor Research Siemens AG Analysis of Services and Interfaces used when Interworking Between the Internet and the Intelligent Network (I.N.) <draft-conroy-interfaces-in-net-00.txt> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The plethora of networks comprising the Internet have been getting bigger and faster in the past at a tremendous rate. In the future, to address all of the current and future pervasive services, the Internet will also have to get better, i.e. it will need more intelligence created by clever software deployed throughout the network. This Internet Draft advances the discussion on the issues involved in interconnecting the Internet and Public Switched Telephone Networks (PSTNs), focusing on potential interfaces between Internet-based devices and Intelligent Network (I.N.) devices. Services based on the interplay of PSTN / I.N. and the Internet are discussed and classified, and an outline of a protocol architecture for the interface between the Internet and the Intelligent Network is given. L. Conroy, M. Lautenbacher, and R. Scholl [Page 1] Service and Interface Analysis with Internet/I.N. Interworking Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . 2 1.2. Context . . . . . . . . . . . . . . . . . . . . . . 3 2. Intelligent Network Entities and their Roles . . . . 3 3. Services Offered over I.N./Internet Interface. . . . 6 4. Interfaces and Interaction . . . . . . . . . . . . . 8 5. Protocol Architecture . . . . . . . . . . . . . . . 9 6. Security Considerations. . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . 14 8. Authors' Address . . . . . . . . . . . . . . . . . . 15 Appendix: PSTN-101 . . . . . . . . . . . . . . . . . . . . 16 1. Introduction This document carries on the work started in an earlier Internet Draft [1] to contribute to the task of developing Internet protocols that can engender services to be provided between Public Switched Telecommunications Network (PSTN) terminals, using Intelligent Network (I.N.) entities to control those services within the PSTN. This draft explores potential interfaces between Internet-based devices and Intelligent Network (I.N.) devices. Due to the large number of possible interactions between Internet and PSTN-connected devices, it is proposed that the set of services to be provided and the kind of interaction available be limited in a first stage, so making the task of defining a particular Interface and the behavioural repertoire of entities corresponding over it manageable. The document provides an initial classification of services proposed in the earlier Internet Draft [1]. This classification is used to highlight the kinds of behaviour expected of the corresponding entities, and is not intended as an exhaustive analysis of the services themselves. From this classification the kinds of interaction across the Internet/I.N. boundary are considered, focusing on the roles taken by the correspondents. In turn, the kinds of interaction involved are used to describe the protocols that could be used to carry messages implied by these interactions, and the way in which these protocols work together. Security issues raised by Internet/I.N. interaction are of particular concern and must be addressed before any such interface will be acceptable. This is a significant task, but this document lists some of the concerns that must be resolved. L. Conroy, M. Lautenbacher, and R. Scholl [Page 2] Service and Interface Analysis with Internet/I.N. Interworking 1.2. Context This draft is NOT intended to define standards that will be implemented inside the Public Switched Telephone Network (PSTN). The IETF is perceived as being the centre for expertise on the operation of the Internet, and the behaviours described here are used to help clarify the kinds of interaction expected and so the protocols to be carried over the Internet. Implementation of the physical interface between the Internet and the Intelligent Network (I.N.) is not addressed here, as it will, of necessity, be the province of the International Telecommunications Union (ITU) Standards Group responsible for Intelligent Network Recommendations (SG11) and the regional telecommunications standardisation bodies (e.g. ANSI and ETSI). Definition of the logical interface between the Internet and the I.N. will have to be the result of co-operation between the ITU and the IETF. By restricting the kinds of services offered across the interface and the patterns of interaction between Internet and Intelligent Network entities, the behaviours and protocols implied can be limited. This has the advantage of reducing the work needed to provide a definition for an "Initial Protocol". Preparatory work during the first phase will give a framework for the services to be provided and for future enhancements to the protocols used between the Internet and Intelligent Network. This work is important as the services offered across the interface will be "hybrids". They will be delivered by a combination of Internet Services and I.N. Services. If a framework for the services and behaviours expected across the Interface is created, then the work of specifying the I.N. Services needed can be decoupled from that implied by the Internet protocols, allowing the appropriate ITU Study Group to carry it out. This in turn will ensure that Telecommunications Equipment Manufacturers can work with clear service definitions in order to provide interoperating equipment and similar services to their customers. It also means that Internet based devices can be provided with a protocol set and expected behaviour to allow them to interact with the I.N. (and thus the PSTN "beyond") in a controlled manner, without having to understand the details of I.N. operation. 2. Intelligent Network Entities and their Roles This section mentions the roles carried out by components of the Intelligent Network, at least as far as required for the provision of the services described next. For an introduction to the operation of the I.N. and the way that services are provided using it on the PSTN, see [2] or [3], whilst the set of recommendations defining the operation of the Intelligent Network are in [4]. A brief introduction is also given in [1], with another in the appendix to this draft. L. Conroy, M. Lautenbacher, and R. Scholl [Page 3] Service and Interface Analysis with Internet/I.N. Interworking Services provided on the PSTN with I.N. components take the idea of a simple call between two PSTN terminals (such as telephones or telefax machines) beyond the basic task of connecting them together through the network. Each terminal will be connected to a Central Office (or Telephone Exchange). The basic call consists of a user opening a channel to the Central Office, passing a number that is to be interpreted as the address of the terminal with which they want to make contact, and the processor in that Central Office forming a route through the network towards the destination, in collaboration with the "cloud" of its peer Central Offices. The destination terminal will be alerted to the requested call, the called user will "pick up the phone", and the correspondents can then communicate. From the perspective of the Intelligent Network, this is a basic call service, and is carried out by a set of functional entities collectively called the Call Control Function (CCF), with the Call Control Agent Function (CCAF) at either "end" of the route dealing with decoding the calling user's dialled number and managing the status of the terminals. The I.N. approach adds several functional entities to this (see diagrams in the appendix), allowing extra services to be provided in a flexible manner. To the CCF is added an extra set of functionality called the Service Switching Function (SSF). This can be configured to detect particular events (such as a certain pattern of digits having been dialled). It can instruct the CCF to manipulate the state of a call so that it can, for example, make a temporary connection to another terminal and then clear the connection without closing the call, or drop the call immediately, or dial out to another number from the one dialled by the user. Another entity has been added, called the Service Control Function, or SCF. As the name suggests, this can be given "executive control" of the call, and can pass instructions to the SSF telling it how to handle the request. With most services, the SSF "triggers" on detecting a particular event like a pattern of digits dialled, and will suspend the call whilst it passes control to the SCF by sending it a request for instructions. This will invoke a program on the SCF that takes the request for instructions from the SSF, operates on the parameters passed (such as the digits dialled), and eventually tells the SSF to continue execution, optionally passing parameters back to it for it to use in processing the call (such as the number to use as the destination for this call). Where further information is required to clarify the call request (such as account codes or PINs) the SCF can instruct the SSF to connect the user, temporarily, to another entity called a Specialised Resource Function (SRF). This component holds units that can decode extra digits dialled by the user in response to announcement or prompt messages it sends to them under command of the SCF. Once this has been done, the SCF can ask for a report on the digits dialled, and when a message holding this has been returned to it, the SCF can instruct the L. Conroy, M. Lautenbacher, and R. Scholl [Page 4] Service and Interface Analysis with Internet/I.N. Interworking SSF to remove the temporary connection to the SRF and can continue its deliberations on the call request (for example by checking the validity of the account code and PIN by querying an associated entity called a Service Data Function, or SDF). When the SCF has decided on the next course of action, it will pass back instructions to the SSF to progress the call. Note that the SCF operates by receiving request messages from the SSF and sending messages back to it. It has no direct contact with the user (or the digits they dial) and is a "pure" processor; it is a computer running specialised programs, but these interact with the other components via messages rather than by interpreting the user's requests directly. It always uses the SSF or the SRF as "middlemen" when interaction with a user is needed. In general, I.N. services can be modelled as having a request phase (where digits are used both to select the request and as parameters to that request), optionally an extra parameter phase to specialise the request or to validate the user, and an implementation phase during which the service is performed as requested. By breaking down a call into these different sub-transactions, a fine degree of control can be exercised, and a wide range of extra services can be provided that range from Freephone or Premium Rate calls to Personal Number or Wake Up calls. The Intelligent Network approach has proved successful in that the tasks of collecting the requests are separated from those of exerting executive control and implementing any eventual routing through the network. In the traditional Central Office, all of these aspects are combined, and providing services on every Central Office in a PSTN can prove unworkably cumbersome. From the perspective of the Internet, it could be said that the Intelligent Network is "services done properly". When looking at services that are carried over the PSTN but are requested from the Internet, however, the relationships between the users and the entities fulfilling their requests are somewhat different. For example, the request parameters are not restricted to strings of digits, and the way in which the requests are generated (for example, by submitting a form to a web server) is quite different. Instead of collecting the parameters in a sequence of commanded interactions between an SRF and the user making the request, the request can be built up on the Internet, with the complete request being sent to the Intelligent Network "en bloc". There is no interaction between the SSF and the requesting device, with all instructions "coming down" from the entity running the service. As will be seen, there IS a role for the SRF in one category of services requested from the Internet, but its role is restricted to transcoding of data rather than collecting request parameters as well. L. Conroy, M. Lautenbacher, and R. Scholl [Page 5] Service and Interface Analysis with Internet/I.N. Interworking 3. Services Offered over I.N./Internet Interface There is a wide range of services that could be provided by collaboration between the Internet and the Intelligent Network. Several such services were mentioned in an earlier Internet Draft [1]. They are analysed here, along with an initial attempt at categorising them. The first of these services was called "Click to Dial". The premise is that a user has (somehow) generated a request at an Internet-based server, asking for a telephone call to be placed between two terminals connected to the PSTN. This request is sent from the Internet server to the I.N. system, and that equipment instructs the Central Offices to place the call. From the Internet perspective, the request has been made; the detection and implementation of that request are carried out solely in the Intelligent Network. The particular scenario chosen was an example of a Web-Activated Callback Service. The user selects a page on the Web provided by a company, fills in a form to indicate the phone number of a telephone at their location, and submits this to a Web server. The form is processed, a request is constructed and sent to the Intelligent Network, and this provides a telecommunications service, selecting a free agent and making a call from that agent to the customer supplied phone number. Note that "Click to Dial" is a slight misnomer, as the service provided is a call back, and there is no speech data sent between the Internet and the Intelligent Network. The next service was called "Click to Fax". The premise here is that an Internet-connected user has some data that they would like converted into a fax and sent to a telefax machine (on the PSTN). This service is more involved than Click to Dial, as it requires data to be collected from the Internet-connected user, together with the fax number of the intended destination. The request and the data to be sent are passed to the I.N. system, and this sets about converting the data into a form suitable for sending as a fax, makes the call to the destination telefax machine, and sends the generated facsimile to it. Another "Fax related" service mentioned was called "Click to Fax Back". The premise in this case is that an Internet connected user generates a request including the fax number of the machine to which they would like information to be sent, and that, together with an indication of the information they would like, is constructed into a request that is sent to the Intelligent Network. This will use the information reference passed in the request to select a particular document, will convert this as needed into a form suitable for sending as a fax, and will then arrange for a call to be made to the customer's telefax machine, sending the information they requested to it. Unlike the Click to Fax service, this one involves (on the Internet side) just sending a request; no data is sent to the Intelligent Network. L. Conroy, M. Lautenbacher, and R. Scholl [Page 6] Service and Interface Analysis with Internet/I.N. Interworking However, there is an "operational" problem here. The Internet generated request will have to contain a reference to the information (held in the I.N. or the PSTN) to be "faxed back". Ensuring that the reference passed in the request is valid, particularly if that reference is embedded in a Web page, may prove difficult. The last service mentioned was called "Voice Access to Content". This is designed to allow a customer to have some subset of Web page content delivered to them in speech form, via their telephone (on the PSTN). It will require that the person making the request has some way of identifying the phone number of the telephone to which they want the speech version of the information to be sent, along with data holding the web content to be processed. From the perspective of the Internet, this service is similar to the "Click to Fax" service mentioned earlier. The differences lie in the way that the Intelligent Network treats the data it is passed. Although not mentioned in these descriptions, any "production quality" service will ensure that the requesting entity be kept informed of the status of their request. The implication here is that there would be at least an acknowledgement sent back from the I.N. to the Internet-connected device that made the request of the Intelligent Network. One option is for this to be arranged using a connection-oriented transaction (using TCP to deal with the request/response pair in the same way as version 1.0 of the HyperText Transfer Protocol, or HTTP [5]). There are drawbacks with the simple TCP-based approach, however. The TCP connection setup and tear-down process takes time, and opening and closing a TCP connection for each request can limit performance whilst consuming bandwidth. A similar consideration was made when work began on enhancements to HTTP, with the decision being taken to "reuse" the TCP connection for subsequent requests in later versions of the protocol. In this case, however, the rate of requests that are likely to be carried over the boundary between the Internet and the I.N. is lower, so this may not become a limiting factor. Overall, it seems at least a valid choice. Of the services described, there are some implications on the configuration of the I.N. components. For example, the "Click to Fax" service requires equipment to convert the passed data into a format suitable for sending as a telefax, along with a unit that can engage in a fax call. Similarly, the "Voice Access to Content" service needs specialised text to speech equipment within the Intelligent Network. In both cases it is assumed that this specialised equipment is available; otherwise it is not possible to provide the services. L. Conroy, M. Lautenbacher, and R. Scholl [Page 7] Service and Interface Analysis with Internet/I.N. Interworking Generalising from the individual services, there are some common features that may be used to classify them. For example, in both the "Click to Dial" and the "Click to Fax Back" service the Intelliligent Network receives a request with two service parameters; the phone or fax number to be used as the destination of a PSTN call it is to arrange, along with an "information reference" to show the topic in which the customer was interested. In some variants of these services there might be another parameter indicating the location of the company providing the information (akin to the xxyyzzz in a 1-800-xxy-yzzz number) or, potentially, the location of the "faxback" information store. In the case of the "Click to Fax" and "Voice Access to Content" services, a request is sent to the I.N. from the Internet with a parameter giving the phone or fax number to be used as destination for the requested call. In addition, however, a component of the I.N. is performing a transcoding of data that is also sent from the Internet; the I.N. converts the data into a different form and sends it to a different kind of PSTN terminal, but the overall process is similar. The essential difference between these services and the others is that, in this case a package of data must be sent from the Internet along with the request, whilst in the case of the "Click to Fax Back" and "Click to Dial" services, only the request is sent; in effect, it contains control information only. The services described here (and a number of others that involve delivering I.N. services initiated from the Internet) fall into the categories of "control interaction only", or "data transcoding" services. Note that these two categories both require discrete messages to be sent to and from the Intelligent Network. Any services involving speech or a continuing data stream being passed across the boundary are outside the scope of this work, and would form yet another category of services. 4. Interfaces and Interaction As mentioned above, there are potentially two separate information exchanges between the Internet and the Intelligent Network. The first of these is the initial request with its needed parameters, sent from an Internet device to the Intelligent Network. The second is any data that is to be processed within the I.N. and so is also passed to it from the Internet. The Service Node consists of an implementation of several Intelligent Network functional entities tied together in a particular configuration (see, for example ITU Q.1215 for details of some of the options). It contains equipment providing the Service Control Function, units acting as the Service Data Function, an embedded Switch providing the Service Switching Function (for the local SCF only), and a set of auxiliary equipments that provide the Specialised Resource Function. L. Conroy, M. Lautenbacher, and R. Scholl [Page 8] Service and Interface Analysis with Internet/I.N. Interworking There are very good reasons for defining a Service Node as the Intelligent Network system that interacts with Internet devices (see section on Security), and this draft assumes that a Service Node is used rather than any other physical configuration of the Intelligent Network. If a Service Node is to be dedicated to interaction with the Internet, then it is likely that the Specialised Resources it contains would be quite different from those installed in other nodes. The two "transcoder" resources needed for the "Click to Fax" and "Voice Access to Content" services are unlikely to be required in services provided solely on the PSTN (with no Internet involvement). The kinds of information flowing between the Internet and the Service Node might also reflect different destinations. On the PSTN, the SCF receives requests (and request parameters) from the SSF. It may also receive extra parameters from the SRF. However, the reason that requests originate at the SSF is that the SSF has a "direct" connection to the user's data stream, whilst the SCF doesn't. Similarly, the SRF can be connected to the user's data stream, so it can prompt and collect digits to be used as request parameters. The situation is somewhat different where requests are generated and delivered from the Internet. It is possible to construct a message to be sent to the Service Node including all information needed by its SCF, encoded into a format that is convenient to that SCF. At least conceptually, this could be modelled as being sent directly to the SCF, even if (in practice) it is handled in a different way. Similarly, any response to the request will appear to be dispatched from this entity back to the Internet. The data that may be associated with a request, however, is almost certain to be dealt with by the Specialised Resources. There is no need for it to be passed "onwards" from the Service Node, nor for it to be passed to any other components within the Service Node. The nett result of this is that there could be considered to be two destinations within the Service Node that receive information from the Internet; one of them receives the requests and service parameters, whilst the other one deals with any data that is processed as part of the service. The Interface between the Service Node and the Internet actually consists of two sub-interfaces, each with its own destination logical end node. 5. Protocol Architecture This section covers the kind of protocols to be used across the interface between the Internet and Intelligent Network. As yet, the work on provision of services across this interface has just started. The details of the protocol messages to be exchanged require refinement. L. Conroy, M. Lautenbacher, and R. Scholl [Page 9] Service and Interface Analysis with Internet/I.N. Interworking However, it is possible to consider what the protocols have to do and so how the protocols work. The entities that will interact to provide a service over the PSTN have been introduced already. This section is intended to make some initial choices on the way that messages can be sent between them across the Internet/I.N. boundary. As mentioned in the separate section on Security Considerations (as required in [6]), there is a need for a protected link between the Internet-based device making a request and the Service Node. The protocols needed to ensure this protection are not covered here; further work is needed on this topic before provision of any Internet requested service will be acceptable to some Network Operators (and Governments)and for now it is assumed that such a link has been set up before the message exchanges mentioned here are started. As already suggested, there are two distinct forms of message exchange. The first one is used to pass the service request, along with the parameters needed for the particular service being requested. It will also be used to pass responses back from the Intelligent Network to the requesting Internet-connected device. This will be needed for all services being requested across the boundary. The second kind of transfer is needed for a category of services in which data is sent from the Internet, is processed and converted by the Service Node, and is used as the basis for data to be sent across the PSTN. Each package of data is related to a specific request. The logical entity consuming it within the Service Node is different from that dealing with the associated request. The pattern of interaction between the requesting Internet entity and the one dealing with the request in the Service Node is, at least initially, straightforward. The services described earlier can be arranged with a simple invocation and response sequence. This differs from the situation that occurs in "traditional" I.N. services, where any extra service parameters are collected as the result of an extended user interaction phase. With Internet-based requests, however, it is quite possible to formulate a message with all of the parameters required and then to send them all in one message. It is possible that future services will require an extended dialogue, but this is not needed at present. The timing of the response (and its meaning) is significant. With other Internet protocols (such as HTTP or Finger) the time taken to perform the requested transaction and send back a response is short. This means that the requesting entity can open a TCP connection to the server, pass the request, hold the connection open, and expect the response soon afterwards, after which the connection can be closed. The requesting entity can set a time-out value so that, if a response is not received in a certain time, the request is deemed to have failed and the connection can be closed. However, when services are delivered by a Service Node it can take a significant amount of time before the requested transaction has become fully active. In particular, the time until the PSTN part of the service has completed L. Conroy, M. Lautenbacher, and R. Scholl [Page 10] Service and Interface Analysis with Internet/I.N. Interworking can be excessive. If the request is for a Web Activated Callback Service, for example, the transaction may not be considered terminated until after the call has completed; this could be (quite reasonably) a considerable time. In order to limit the time before an inoperative interface can be detected, it is suggested that the protocol response should indicate that the request has been received and accepted by the Service Node. It is then the responsibility of that Service Node to carry out the request. The way in which this is done is completely internal to the Intelligent Network and so outside the scope of this work. This does mean that a request may be accepted by the Service Node (as indicated in the response sent back to the Internet) and then the service may subsequently fail due to problems encountered in the PSTN. However, the goal of restricting the "Initial Protocol" interactions to simple request/response pairs makes this unavoidable. It also means that all transactions are initiated by the Internet device, without a separate event indication being initiated from the Service Node. If such a Service-Node initiated transaction were to be introduced it would add considerable complications, not only to the protocols carried over the Internet but also in the internal operation of the Service Node. As such it would require closer coordination between the groups defining the operation of the Intelligent Network components (ITU SG11 and the regional telecommunications standards bodies) and the IETF. This would (at least) delay the introduction of the services. As work develops in these external bodies, the Internet protocols can be enhanced, but initially the gain is not worth the wait. The "transcoding" category of service requires data to be sent, as well as the basic request message. The security requirement of the information carried in these two protocols is different. As mentioned in the section on Security Considerations, the request message may well carry information that has charging significance; it may include parameters that validate or authorise the request and so must be protected. As someone may be charged for the provision of the service, it is important that any PIN is kept secure. The data message that is needed for one category of services has a lesser requirement. Whilst it is unfortunate if the content of an email is intercepted, it should not have a financial significance. Likewise, the content of the data sent to the Service Node may be intercepted, but the consequences of this are not as potentially severe. In the category of service mentioned above (and initially described in [1]) that requires a data message to be sent, the transaction is again initiated from the Internet. The data is sent from the Internet-connected device making the request, and is delivered to the Service Node. As such, this transaction can be organised using a straightforward TCP-based file transfer protocol. The connection is opened by the requesting entity, the title and then the data is sent and acknowledged, and then the connection is closed. L. Conroy, M. Lautenbacher, and R. Scholl [Page 11] Service and Interface Analysis with Internet/I.N. Interworking Where two messages are needed to carry the information needed to process the service, these need to be coordinated. The request message needs to be "tied in" with the data message. This can be done either by a request parameter holding a reference that is used as the title for the data transfer, or by the Service Node sending back a reference number in its response to the request, with this being used as the title for the data transfer. The choice has an implication on the meaning of the rest of the response. If the reference required by the data transfer is passed back to the Internet device making the request in the response from the Service Node, then any "success" parameter concerns the validity of the request data, not that the overall request has been successful; at this point the data transfer has not started. As an alternative, if the Internet device generates its own reference number and passes this TO the Service Node in its initial request then the acknowledgement back from the Service Node to the Request can be delayed until any data transfer has completed. This means that the response can indicate the success or failure of the whole service request. Unfortunately, there are problems with this scheme. There may well be a number of Internet devices making requests of a Service Node concurrently. There is a possibility that the reference numbers passed in their requests are not unique, with the potential for ambiguity in which data transfer relates to which request. As such, it is suggested that the former scheme is used, whereby the Service Node generates a unique reference number and sends it back to the requesting device, with this value used as an identifier in any related data transfer. In this case, acceptance of the overall service request requires a positive acknowledgement both to the initial request and to the separate data transfer (if any such transfer is needed for the service requested). The following diagram shows the two stage protocols sent between the requesting Internet-based device and the Service Node. Note that the second phase of the transaction is used only where the service requires extra data to be sent. Note also that, although shown as separate entities, the service node components may share the same address and appear as one item to the requesting device. To enable this, the entities responding to the service request and the optional data transfer could register on different TCP ports. Internet Device SN Request Handler SN Data Handler |-service request -------------------> . <-- request ack (+optional ref.no)---| |-- (optional) request data + ref.no ------------------> . <-- data ack ------------------------------------------| L. Conroy, M. Lautenbacher, and R. Scholl [Page 12] Service and Interface Analysis with Internet/I.N. Interworking 6. Security Considerations It is of utmost importance that the operation of the PSTN must not be damaged by operation of this interface. Two levels of protection are needed to ensure this: (i) the Interface is associated with a Service Node. This choice means that interaction with rest of the PSTN is restricted; there is NO connection to the SS7 Network from a Service Node, and any Central Office to which the Service Node is connected can use its "normal" access protection features to isolate it if it starts to behave incorrectly. The use of a Service Control Point (or SCP - a unit that implements just the SCF and has a connection to the SS7 network) might be considered. However, if an association were to be made between the Internet and an SCP rather than a Service Node, then any subversion of this unit would put the whole of the Telephone Network's signalling system in jeopardy and (as it has access via the SS7 network to all SSPs and so to all of the Central Offices) the whole of the Telephone Network. (ii) the Interface must allow access control and secured exchanges between I.N. components and Internet connected devices. There are several reasons for this, and these are indicated briefly here. A large proportion of the information flowing across this interface will have charging and billing significance; PSTN Network Providers' customers being provided with services will be charged for them, so any information authorising or authenticating users that is passed over the Internet towards the interface must be protected against interception. Where service requests are accepted and transferred across this interface from a restricted set of nodes, protection against source spoofing, "man in the middle" and replay attacks must be considered. The interface must be designed so that the impact on operation of the Service Node, and, more generally, the PSTN, of denial of service attacks can be minimised. Where possible, the interface should be designed so that service can continue to be provided to some Internet nodes in the face of such attacks from errant or malicious sources on the Internet. L. Conroy, M. Lautenbacher, and R. Scholl [Page 13] Service and Interface Analysis with Internet/I.N. Interworking Integrity of charging information is important, and enough information must be collected to assure non-repudiation of charges. This presents a problem where the source of a request is on an untrusted network; mutual authentication may well be required, and this implies that there will be a definite lifecycle to the relationship between the Service Node and the Internet Devices that generate the requests. This lifecycle in turn may be the subject of attack in terms of state synchronisation disruption. Where the Internet devices that send requests to the Service Node are themselves acting as servers for other Internet connected users (such as a Web Server providing a Web-Activated Callback Service to browsers), there may also be a need to ensure that authentication information passed from the "end user" is available and can be passed on to the Service Node in a secure manner. 7. References [1] I. Faynberg, M. Krishnaswamy, and H. Lu. INTERNET-DRAFT:draft-faynberg-telephone-sw-net-00.txt, "A Proposal for Internet and Public Switched Telephone Networks (PSTN) Internetworking". Issued March 1997 [2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The Intelligent Network Standards, their Application to Services". McGraw-Hill, 1996 [3] J. Thorner, "Intelligent Networks". Artech, 1994 [4] ITU-T Q.12xx Recommendation Series, Geneva, 1995. [5] T. Berners-Lee, R. Fielding & H. Frystyk, RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0". May 1996 [6] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993 L. Conroy, M. Lautenbacher, and R. Scholl [Page 14] Service and Interface Analysis with Internet/I.N. Interworking 8. Authors Addresses Lawrence Conroy E-mail: lwc@roke.co.uk Telephone: +44-1794-833666 Fax: +44-1794-833434 Roke Manor Research Limited IT&N-INIA Group Roke Manor, Old Salisbury Lane, Romsey, Hampshire SO51 0ZN U.K. Markus Lautenbacher E-mail:markus.lautenbacher@oen.siemens.de Telephone: +49-89-722-37805 Fax: +49-89-722-23528 Siemens OEN MD13 Machtlfinger Strasse 10 Munich D-81359 Germany Reinhard Scholl E-mail:reinhard.scholl@oen.siemens.de Telephone: +49-89-722-22119 Fax: +49-89-722-62366 Siemens OEN MB21 Hofmannstrasse 51 Munich D-81359 Germany L. Conroy, M. Lautenbacher, and R. Scholl [Page 15] Service and Interface Analysis with Internet/I.N. Interworking Appendix: PSTN-101 What is normally considered as "the Telephone Network" consists of a set of interconnected networks. Potentially, each of these networks could be owned by a different Network Operator. The official name for such a network is Public Switched Telecommunications Network (PSTN). A simple PSTN consists of a set of Switches (called Central Offices or Telephone Exchanges) with links interconnecting them to make up the network, along with a set of access connections by which terminals are attached. The PSTN is used to deliver calls between terminals connected to itself or to other PSTNs with which it is interconnected. Calls on the PSTN are circuit switched; that is, a bi-directional connection is made between the calling and called terminals for the duration of the call. In PSTNs the connection is usually carried through the network in digital format occupying a fixed bandwidth; this is usually 56 or 64 Kbps. Messages are sent between the Switches to make and dissolve connections through the network on demand and to indicate the status of terminals involved in a call; these "signalling" messages are carried over a separate (resilient) data network dedicated to this purpose. This signalling network is also known as the Common Channel Signalling (CCS) or Signalling System Number 7 (or SS7) network after the names of the signalling protocol suite used. As yet, the majority of access connections to a PSTN carry analogue signals, with simple (analogue) telephones as terminals. Call requests are indicated to the Central Office to which a telephone is connected either by a sequence of pulses or tone pairs being sent. Notifications on the status of the request are sent back to the telephone in the form of tones. Indication from a Central Office that a call is being offered to a telephone is arranged by sending an alternating voltage down the access connection which in turn causes the ringer in the telephone to sound. These access lines have a unique address associated with them and can support a single call. However, with analogue or digital multi-line connections, or Integrated Service Digital Network (ISDN) Basic or Primary Rate Interfaces (BRI or PRI), several concurrent calls are possible and a set of addresses are associated with them. The new ISDN access connections are designed so that data exchanged with the network is in multiplexed digital form, and there is an individual channel for each of the potential connections, together with a separate channel dedicated to sending and receiving call request and call alert data as well as carrying packet switched user data. These call request and call alert messages the equivalent of the pulses or tones that are sent when dialling, and the ringing signal that is sent to a telephone when a call is being made to it. L. Conroy, M. Lautenbacher, and R. Scholl [Page 16] Service and Interface Analysis with Internet/I.N. Interworking The operation of the call request is fairly simple in most cases. The user presses a sequence of numbers on a telephone handset, and the telephone passes a sequence of digits (either as pulses or tone pairs) to the Central Office via the access line. The Central Office contains a processor that will be notified that the user has made a request and the digit string that is the sole parameter of the request. This digit string is taken to be the unique address of an access line connected either to itself or to another Central Office. There is a hierarchical addressing scheme, so that the digit string can be parsed easily. A call request to a terminal connected to a remote Central office can be routed by examining the digit string passed; the Central Office will extract the part of the passed address that corresponds to the remote Central Office in question, and can route the request onward, forming an inter-switch call request and passing it via the signalling network. At the same time it will allocate one of its available transmission channels towards the remote Central Office. This scheme has been used since the 1950s, and suffices for the majority of calls. However, there are a range of other services that can (and have been) provided, enhancing this basic call processing. Freephone or Premium Rate services (1-800 or 1-900 services)are good examples of the supplementary services that have been introduced. Apart from the important feature that the cost of these calls is varied so that the caller does not pay for a freephone call, or pays an extra charge for a premium rate call, they have the similarity that the number dialled must be translated to arrive at the "real" address of the destination terminal. They are known as number translation services, and make up the bulk of all supplementary services delivered today. These were originally programmed into each Central Office, but the complexity of maintaining the data tables on each processor grew cumbersome, so a more general solution was sought. After a considerable gestation period, the eventual solution was the Intelligent Network. This takes the separation of Central Offices and the network links interconnecting them a stage further. The Central Offices are considered to provide the Call Control Function (CCF). In addition, the Service Switching Function (SSF) is provided to "enhance" the operation of these Switches by detecting when a particular request has been made (such as by dialling 1-800). If this pattern is detected, the equipment implementing the SSF will send a specialised request message over the signalling network to a separate computer that implements the Service Control Function (SCF). This entity is responsible for querying service specific data (held in a unit providing the Service Data Function, or SDF), performing any digit translations necessary, and sending the details of how to proceed back to the SSF, where they are obeyed and the call is put through to the "real" destination. L. Conroy, M. Lautenbacher, and R. Scholl [Page 17] Service and Interface Analysis with Internet/I.N. Interworking The advantage is that there can be a much smaller number of physical units dedicated to the SCF, and as they are connected to the signalling network they can be contacted by, and can send instructions back to, all of the units providing the SCF. In another enhancement, a separate entity called the Special Resource Function (SRF) was defined. Equipment implementing this function includes announcement units to play recorded messages (for example, prompts to enter digits) to callers. It will also include the tone decoders needed to capture any digits pressed by the caller in response to the prompts. Finally, it will include a connection (directly or indirectly) back to the SCF. This allows the digits pressed by a caller to be passed to the SCF on demand. For example, the SCF can ask an SSF handling a call to route the caller temporarily through to an SRF. It can then instruct the SRF to play an announcement and to collect a set of digits from the caller. Once this has been achieved, the SCF can ask for the temporary connection to be dissolved, can ask for a message giving the digit string collected, and can use this as an extra parameter to the service request. This pattern of user interaction is commonly used where telephone charge cards are used to make a call, in which case the extra account information and PIN can be captured in this way, passed on to the SCF, where it can be checked against the correct values stored in the service database prior to allowing the call to proceed. An overall diagram showing the functional entities involved in a PSTN/I.N. combination is shown in Figure A. One possible configuration for these entities is shown in Figure B. However, where Internet connection is intended, the configuration is slightly different, as shown in figure C. L. Conroy, M. Lautenbacher, and R. Scholl [Page 18] Service and Interface Analysis with Internet/I.N. Interworking FIGURE A: [SCF] [SDF] | | ____________-_________-_______________________ | | | | o^o [ SSF ] | [ SSF ] o-o | /\----------[CCF].........[CCF].......[CCF]------/\ | -- \ -- | \ | -----------------------------------------[SRF] key: ____ signalling relationship ---- access relationship .... inter-switch relationship FIGURE B: [SCP] [SDP] | | ____________-_________-_______________________ | | | | o^o [ SSP ] | [ SSP ] o-o | /\----------[CCP]..........[CO]......[CCP]-------/\ | -- \ -- | \ | -----------------------------[Intelligent Peripheral] key: ____ signalling (SS7) network ---- access line .... inter-switch (trunk) lines SSP = Service Switching Point - a unit that implements the Service Switching Function CCP = Call Control Point - a unit that performs call control functions. This is normally a kind of Central Office (shown as CO above) SCP = Service Control Point - a unit implementing the Service Control Function. NOTE that this is connected to the SS7 Network and uses this connection for all of its communications. Intelligent Peripheral - this is a unit (also known as an IP) that contains specialised resources (like announcement units, tone decoders). In effect, it implements Special Resource Functions. L. Conroy, M. Lautenbacher, and R. Scholl [Page 19] Service and Interface Analysis with Internet/I.N. Interworking FIGURE C: -----[Service Node] - - - - (Interface) - - [Internet Device] \ \ \ _______________________ o^o \ | | | o-o /\----------[CO].........[CO]......[CO]--------/\ -- -- Note: The Service Node is only connected to the Central Office as a peripheral; it has NO connection to the SS7 network. It performs a similar task to the SCP, SDP, SSP/CCP, and Intelligent Peripheral in figure B. L. Conroy, M. Lautenbacher, and R. Scholl [Page 20]