Network Working Group L. Slutsman Internet Draft AT&T draft-slutsman-softswitch-00.txt I. Faynberg Expires December 2000 H. Lu Lucent Technologies IN/Internet Interworking in Support of Software Switches Status of this Memo This document is an Internet-Draft and is in full conformance wit all provisions of Section 10 of RFC2026. This document outlines a proposal to the IETF for a new work item in support of service delivery in converging networks. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The goal of this document is to identify and propose a new work item for the IETF. To this end, the document defines the term "software switch" for the purposes of describing a mechanism by which existing PSTN Intelligent Network (IN) service control can be reused in IP networks. IP telephony is one application that can benefit from this mechanism, but there are other potential applications of interest (for example, Unified Messaging) which this draft does not address. Specifically, the document illustrates the role of the software switch in IP telephony. The document then narrows, for practical purposes, the scope of the software switch so as to identify an architecture and mechanism for interworking of Session Initiation Protocol (SIP) and Intelligent Network Application Part Protocol (INAP). The so defined mechanism can be implemented as an application layer protocol, when architectural entities reside in different machines, or inter-process communications protocol, if they reside in the same machine. It is the proposal of this document to define at a minimum a meta-protocol (from which particular implementations can be derived) as a work item in the IETF. Some (but not all) parts of this work have already been discussed in the IETF. To help delineating the proposed work item, this Internet draft explains how it relates to the efforts of the existing IETF working groups that deal with the SIP-IN-Slutsman-Faynberg-Lu June 2000 [Page 2] protocols for PSTN/Internet interworking (IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN) and ITU-T. 2. Introduction This document first defines the term "software switch" for the purposes of describing a mechanism by which existing PSTN Intelligent Network (IN) service control can be reused in IP networks. IP telephony is one application that can benefit from this mechanism, but there are other potential applications of interest (for example, Unified Messaging) which this draft does not address. Specifically, the document illustrates the role of the software switch in IP telephony. The document then narrows, for practical purposes, the scope of the software switch so as to identify an architecture and mechanism for interworking of Session Initiation Protocol (SIP) and Intelligent Network Application Part Protocol (INAP). The so defined mechanism can be implemented as an application layer protocol, when architectural entities reside in different machines, or inter-process communications protocol, if they reside in the same machine. It is the proposal of this document to define at least a meta-protocol (from which particular implementations can be derived) a work item in the IETF. Some (but not all) parts of this work have already been discussed in the IETF. To help delineating the proposed work item, this Internet draft explains how it relates to the efforts of the existing IETF working groups that deal with the protocols for PSTN/Internet interworking (IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN) and ITU-T. The remaining sections of this document present, in this order, the problem statement, proposed area of standardization and service examples, relation of the proposal to the existing work in the IETF and other standards bodies, security considerations, conclusion, references and acknowledgements. 3. Problem Statement In a nutshell, the problem addressed here is that of porting a large class of services that exist today in the PSTN network to the IP telephony. Specifically, these are the services that are provided through the mechanism known as Intelligent Network (IN) [1]. Such services include the "freephone" (known as "800 number" in the United States), Local Number Portability (LNP), Virtual Private Network (VPN), and so forth. (In general, any service can be provided with IN, although not all are implemented this way.) To explain what "porting" means here, we first explain the basics of IN. Figure 1 depicts a (much) simplified IN architecture, in which telephone switches (called Service Switching Points [SSPs]) are connected (via a fast packet network called Signaling System No. 7 [SS7]) to Service Control Points (SCPs), which are general purpose computers. At certain points in calls, a switch can interrupt a call and request instructions from an SCP. (The points where a call can be interrupted are standardized within the Basic Call State Model [BCSM]. SIP-IN-Slutsman-Faynberg-Lu June 2000 [Page 3] +--------------+ | SCP | +--------------+ / \ INAP INAP / \ +-----------+ ISUP +-----------+ | SSP |--------| SSP | +-----------+ +-----------+ Figure 1: Simplified IN Architecture It is important to note that the BCSM models two separate processes-the originating and terminating ones.) When the SCP gets an instruction, it can reply with a single response (such a simple number translation augmented by criteria like time of day or day of week), or, in turn, get into a complex dialog with the switch. The situation is further complicated by the necessity to engage other specialized devices, which collect digits, play recorded announcement, perform text-to-speech (and vice versa) conversion, etc. (These devices are not discussed here.) The related protocol (as well as BCSM) is standardized by ITU-T and known as the Intelligent Network Application Part Protocol (INAP). Conversely, only the protocol--but not the SCP API--has been standardized. The reality in the industry today is that a multitude of SCP platforms and related service logic programs exist. While SCPs can well interwork with switches in a multi-vendor environment, "porting" a service from one SCP platform to another (sometimes, even when both platforms are built by the same vendor) is a matter of dealing with millions of lines of code (some running at an interrupt level and programmed in a machine language) that had been tuned to work on a particular processor and in a particular environment. As a rule, such an effort is prohibitively expensive if at all feasible even for what is perceived as "basic" services (like "800"). +--------------+ | SCP | +--------------+ | |INAP | +------------+ +-------------+ +------------+ | SIP | TBD | Software | ISUP | PSTN | | Servers |----------| Switch |----------| Switches | +------------+ +-------------+ +------------+ Figure 2: Simplified Software Switch Architecture To deal with this and many other complexities, the industry came up with the concept of "software switch" (see www.softswich.org). At the highest level of abstraction and in most general terms, a software switch is a process that behaves like 1) a PSTN switch to any PSTN entity (such as SCP or SSP) and 2) like a "friendly" entity to any SIP-IN-Slutsman-Faynberg-Lu June 2000 [Page 4] particular IP telephony function. As depicted in Figure 2, a software switch can "talk" SS7 to SCPs and PSTN switches (thus acting as an SSP), and communicating with SIP servers. The latter capability--is the matter of this proposal. In addition (not depicted in Figure 2), a software switch may act as a Media Gateway Controller to a Media Gateway, and "speak" H.323 to a Gatekeeper. While the products that implement all the facets of the software switch concepts are being built, for the purposes of this particular proposal, the term "software switch", however, refers only to the means of mediation between the communications with the SCP on the one hand and SIP servers on the other hand. In other words, the proposal deals with porting the existing PSTN services to SIP networks in support of IP telephony, especially the calls that traverse both the PSTN and IP networks. (The proposal intentionally avoids the discussion of the OA&M and, particularly, AAA issues at this point so as to avoid the complexity. At a certain point, however, if this work item is accepted by the IETF, these issues will definitely need to be addressed.) +--------------+ | SCP | +--------------+ | |INAP | +--------------+ TBD | Software | TBD +---------| Switch |---------+ | +--------------+ | | | | | TBD| | | | | +--------------+ +--------------+ +------------+ | SIP UAC | | SIP "Forking"| | SIP UAS | | (OFSM) | | Proxy | | (TFSM) | +--------------+ | (PFSM) | +------------+ +--------------+ Figure 3: Software Switch for SIP-IN Interworking Figure 3 zooms in on the subject of the proposal. Here, the software switch is modeled as a process that communicates with the three SIP processes: SIP User Agent Client, SIP User Agent Server, and SIP Forking Proxy. It is true, that all these processes (or rather their respective functional entities) can be grouped in the same box with the software switch; there is however a concern that this may be too much for a single piece of equipment. It is better to assume (similarly to the architecture adopted by the MEGACO WG) that the processes do run on different processors, which would in turn require a definition of the protocol between the software switch and these functions. But even if that were not the case, this proposal argues that a standard for interworking (if only on the inter-process level) between the software switch and these processes is needed to resolve the potential implementations problems and to help SIP work seamlessly with IN. To this end, a number of proposals [3, 4, 5] that deal with one important SIP-IN-Slutsman-Faynberg-Lu June 2000 [Page 5] part of the problem--the mapping of the BCSM to the SIP "call model"--have already been presented in the IPTEL WG. This proposal attempts, for the first time, to summarize all aspects of the SIP/IN interworking. Specific details and service examples elucidating the proposal are presented in the next section. 4. The Proposed Area of Standardization and Service Examples As noted earlier, an important part of the SIP/IN interworking has to do with the SIP and PSTN/IN call models and their differences. We start with a quick overview of both call models. 4.1 SIP "Call Model" The SIP call model may be derived from sections 10-12 of RFC 2543 [2] that describe the behavior of all SIP network components: SIP User Agent Clients and Servers, SIP Proxies, SIP Redirect Servers, and SIP Registrar Servers. The formal description of SIP FSMs is the first step in standardization of SIP/IN. Only "stateful" SIP servers (i.e., those that keep track of end-to-end call states) are important; "stateless" SIP proxies, which just forward SIP messages are not part of the call model. The SIP servers of interest are UAC, UAS, and "forking" Proxy. (Redirect Server is similar in its nature to UAS.) The bottom part of Figure 3 shows three major SIP FSMs: + Originating FSM (OFSM) that formalizes the call process in a UAC, sending and re-transmitting INVITE, and, finally, sending ACK and returning to the initial state (see Figure 12 in [2]). + Terminating FSM (TFSM) that formalizes the call process in a UAS, receiving INVITE, sending back responds (informational and/or final), and, finally, receiving ACK and returning to the initial state. + Proxy FSM (PFSM) that formalizes the call process in a "forking" proxy, essentially, PFSM may be broken in to two interworking state machines (not shown in Figure 3): Proxy Originating FSM (POFSM) and Proxy Terminating FSM. Thus a stateful proxy acts as a virtual UAS/UAC. It implements the server state machine (PTFSM) when receiving requests, and the client state machine (POFSM) for generating outgoing requests, with the exception of receiving a 2xx response to an INVITE. Instead of generating an ACK, the 2xx response is always forwarded upstream towards the caller. Furthermore, ACKs for 200 responses to INVITEs are always proxied downstream towards the UAS, as they would be for a stateless proxy. 4.2 The IN Call Model--Basic Call State Model (BCSM) BCSM is standardized in the ITU-T Recommendation Q.1204 (general aspects), Q.1214 (IN Capability Set 1 aspects), and Q.1224 (IN Capability Set 2 aspects); Chap. 5 of [1] also discusses the development of the concept. The model guides all the aspects of the service request imitation. Because neither the "internal" call models SIP-IN-Slutsman-Faynberg-Lu June 2000 [Page 6] (i.e., the ones that support switch-based services) nor the internal SN interfaces (i.e., interfaces between the call processing and service processing) are standardized, the SPIRITS protocol can be influenced normatively only by the BCSM and the protocol, Intelligent Network Application Part (INAP), that accompanies it. (The respective general, IN Capability Set 1, IN Capability Set 2, and tutorial references are ITU-T Recommendations Q.1208, Q.1218, and Q.1228; and Chap. 6 of [1].) Internet Draft [4] describes in detail the general IN BCSM. The BCSM specifies two finite state machines: one for the originating, and one for the terminating part of the call. In addition to a call state (called Point in Call [PIC]), each part also specifies special states called Detection Points (DPs) that are associated with the transitions between PICs. The PICs are best viewed as "primary" states in that DPs are directly associated with the transitions from PIC to PIC. Thus, the basic construct of the BCSM is PIC-->DP-->PIC, although non-DP-associated transitions (i.e., PIC-->PIC) also exist. If a transition passes through a DP, the Central Office pauses and examines 1) whether a DP is armed (i.e., active) and 2) whether it meets the criteria for launching an IN query or sending a notification. If a DP is armed (off-line) from the Service Management System (SMS), it is called a trigger. The trigger is static in that it is armed "forever." (All SPIRITS services, for example, are initiated by triggers.) But the same DPs that can be set "off-line" as triggers can also be set "on line"--for the duration of a particular call and only for that call--by the SCP. Regardless of whether they are armed statically or dynamically, DPs can be armed either as notifications or requests. Correspondingly, depending on the type of the active DP, the Central Office can either issue a notification (and transit to the next PIC) or, suspending call processing, issue a request to the SCP, and wait for the response. When the response comes back, it may contain an instruction on how to continue with the call. (Such an instruction may even "break" the model by causing a "go-to"-type transition to any other PIC.) The use of SMS can sometimes be avoided by implementing its service distribution and trigger-setting function by other means. The SMS thus is included here for completeness. 4.3 The Interworking of SIP and IN Call Models We propose a general approach for the interworking of SIP and IN call models. As illustrated in Figure 3, any of SIP stateful servers communicates with the software switch which: 1) accepts incoming message from SIP servers and translates them into INAP messages to SCP, and 2) accepts incoming INAP messages from the SCP and translates them to appropriate responses to SIP servers involved. The protocol for interaction between the SIP server and the software switch is the main output of IETF, while the mapping algorithm may be that of ITU-T. 4.4 Service Example: "Hidden Free Phone Call" In this example the call is originated by A who wants to call B. At the time of the call, B has logged on at two workstations X and Y. In addition, B is actively participating in a conference call and has SIP-IN-Slutsman-Faynberg-Lu June 2000 [Page 7] registered the conference bridge toll-free number Z. The call may proceed as the following: 1. UAC (see Figure 3) sends an INVITE message using B's SIP address and reports its current status to the software switch, which in turn initiates its OBCSM. 2. The PFSM, acting as a virtual UAC forks three invites to X, Y, and Z and sends the status to the software switch, which in turn initiates its TBCSM. 3. The Proxy receives 402 (Not Found) response from X and acting as a virtual UAS terminates this call and it may also send the status to the software switch. 4. The proxy receives 2xx form Y, verifies that this address has no PSTN significance forwards 2xx upstream to the UAC. In addition, the status is sent to software switch. 5. The UAC sends the ACK messages via proxy and to X, and sends the status to the software switch. 6. The proxy receives the 2xx from Z and detects that the call has a PSTN significance. The proxy sends the status to the software switch. 7. The software switch sends a message to the proxy, indicating that it can support only one end point. 8. Meanwhile, A contacts B at Y, and figures out that person he wants to talk to is not at Y. The UAC sends BYE via the proxy to Y. In addition UAC sends the status to the software switch. 9. Left with one termination point, the software switch sends a query the SCP and upon receiving the response sends a notification to the proxy. 10. Proxy forwards the 2xx response to the UAC. 11. The UAC sends an ACK message directly or via the proxy to Z. 12. B is connected to the conference bridge. 5. The Relation of the Proposal to the Existing Work in the IETF IETF WGs that deal with similar issues are (in alphabetical order) IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN. Again, there are other groups (such as AAA) whose results are relevant and essential to completing the proposed work item, but this proposal concentrates on the groups that deal with the PSTN/Internet Interworking directly. IPTEL: The subject and nature of this WG are perhaps the closest to the subject and nature of the present proposal. In fact, the original proposes for call model mapping have all been presented to IPTEL. Yet IPTEL deals with specific items: 1) Call Processing Syntax (actually, a language); 2) Service Models; and Gateway Attribute Distribution Protocol. None of these items is immediately related to the proposal. MEGACO: This WG develops the Media Gateway Control Protocol. While this work could naturally be extended (see Fig. 2) to an important issue of interworking INAP and that protocol for the software switch, it is not relevant to the proposal. PINT and SPIRITS: These (symmetric in nature) WGs address the "other side" (relative to the software switch) of Figure 2--which is interworking of the service control with the Internet-provided SIP-IN-Slutsman-Faynberg-Lu June 2000 [Page 8] services. As such neither group has anything to do with the software switch and, consequently, the proposal. SIGTRAN: This WG specifies the transport layer protocol for carrying SS7. A software switch located "inside" the IP network will use the protocol just for that. Alternatively, a software switch located at the edge of the PSTN in that it has a direct connection to the Service Transfer Point (STP)--the SS7 "router" will not need SIGTRAN. In either case, the nature of SIGTRAN has nothing to do with the application protocol interworking issues addressed in this proposal. 6. The Relation of the Proposal to the Work of Other Standards Bodies Interworking of SIP and INAP has been addressed as an issue in what used to be the ITU-T SG 11. There is a reorganization of the ITU-T structure going on presently, but it is likely that this item will remain with the group that will work on IN. No detailed discussion has taken place, but it should be expected that this item would be worked jointly with the IETF (where the SIP expertise resides). It is part of this proposal to organize the work on this item jointly with ITU-T. 7. Security Considerations Security issues for the proposed item include, without an exception, all the general ones with which the IP telephony is concerned: authentication, integrity, confidentiality, and availability. The necessity to develop especially strict security mechanisms is magnified because of the communications with the (traditionally secure) PSTN. 8. Conclusion This document has identified and proposed a new work item for the IETF. To this end, the document defines the term "software switch" for the purposes of describing a mechanism by which existing PSTN Intelligent Network (IN) service control can be reused in IP networks. IP telephony is one application that can benefit from this mechanism. Specifically, the document illustrates the role of the software switch in IP telephony. The document then narrowed, for practical purposes, the scope of the software switch so as to identify an architecture and mechanism for interworking of Session Initiation Protocol (SIP) and Intelligent Network Application Part Protocol (INAP). The so defined mechanism can be implemented as an application layer protocol, when architectural entities reside in different machines, or inter-process communications protocol, if they reside in the same machine. It is the proposal of this document to define at least a meta-protocol (from which particular implementations can be derived) as a work item in the IETF. Some (but not all) parts of this work have already been discussed in the IETF. To help delineating the proposed work item, this Internet draft explained how it relates to the efforts of the existing IETF working groups that deal with the protocols for PSTN/Internet interworking (IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN) and ITU-T. SIP-IN-Slutsman-Faynberg-Lu June 2000 [Page 9] 9. References [1] I. Faynberg et al., "The Intelligent Network Standards, Their Application to Services", McGraw-Hill, 1996. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", Request for Comments (Proposed Standard) RFC 2543, Internet Engineering Task Force, March 1999. [3]. "Framework and Requirements for the Internet Intelligent Networks (IIN)", Draft , Internet Engineering Task Force, September 2000, work in progress. [4] V. Gurbani, "Accessing IN Services from SIP Networks," Internet Draft , Internet Engineering Task Force, December 1999, work in progress. Internet Engineering Task Force, December 1999, work in progress. [5] F. Haerens, "Intelligent Network Application Support of the SIP/SDP Architecture", Internet Draft , November 1999, work in progress. 10. Acknowledgments We are grateful to Jerry Ash, Janusz Dobrowloski, Vijay Gurbani, Frans Haerens, Jack Kozik, Warren Montgomery, and Jonathan Rosenberg for many useful discussions of and contributions to the call-model-related issues. (Janusz was the first to bring the discussion to the IETF.) We thank Henning Schulzrinne for a very insightful initial discussion of this proposal. We should point out that our acknowledgements are by no means to imply the endorsement of this proposal by those whom we thank. 11. Author's Addresses Lev Slutsman AT&T Laboratories 200 Laurel Ave. Middletown, New Jersey, 07748 Phone: (732) 420-3752 Email: lslutsman@att.com Igor Faynberg Bell Labs/Lucent Technologies Room 4C-611A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733 Phone: (732) 949-0137 Email: faynberg@lucent.com Hui-Lan Lu Bell Labs/Lucent Technologies Room 4C-607A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733 Phone: (732) 949-0321 Email: huilanlu@lucent.com SIP-IN-Slutsman-Faynberg-Lu June 2000 [Page 10] Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SIP-IN-Slutsman-Faynberg-Lu June 2000