INTERNET DRAFT Michael McGrew Date: November 1998 Lucent Technologies Inc. Expires: May 1999 Transport SS7 Signalling Over IP 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 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document proposes the transport of SS7 signalling messages over IP in a way that utilizes the existing SS7 network (MTP and SCCP) layers to ensure 'carrier class' service as expected by existing users of SS7. The transport of SS7 user information could use TCP connections or UDP. The SS7 signalling messages would include ISUP or SCCP or, if the network services are not needed, could include only TCAP. Work should begin to define the necessary adaptation layers to make these transport methods possible. Table of Contents 1.0 Purpose and Scope 2.0 Overview 3.0 Discussion 4.0 Proposals 4.1 Emulate MTP Transport 4.2 Point-to-Point Transport 5.0 Conclusion and Recommendations 6.0 Acronyms 7.0 MTP Transfer Primitives 8.0 References 9.0 Author 1.0 Purpose and Scope This paper addresses the need to transport over an IP network SS7 signalling between any two network elements which have an SS7 protocol stack at Message Transfer Part (MTP) Level 3 and/or above. In architectures that have been discussed for transport SS7 signalling over IP, a common thread is that the end user protocols need to understand SS7. The motivation is that SS7 users need the interface with IP to give them more flexibility to communicate with a more widely distributed SS7 user community of the future. Some SS7 users might not have the SS7 protocol stack, but instead rely on transport over IP. Other SS7 network nodes will already be on the standard SS7 network and have a full SS7 protocol stack, but have a need to communicate with the nodes that have only IP-based access. When the latter is deployed on SS7 Signalling Transfer Points (STPs), they can act as gateways to open up access to the SS7 nodes on the large installed base of SS7 networks that should need to have no knowledge of the IP network interconnection. All nodes such as Service Switching Point (SSP) nodes and Service Control Point (SCP) database nodes would be included in this new community. There will be many SS7 user needs, and this contribution describes a limited set of solutions that can be applied comprehensively to meet those various needs. This contribution describes interfaces or "adaptation layers", or protocol layers that allow the SS7 transport to take place, that incorporate the needs of these various nodes. It proposes that work begin to define what details are needed in these adaptation layers, to adapt the SS7 protocol being transported to the underlying UDP/TCP/IP transport. 2.0 Overview This general view of "SS7 transport over IP" considers that SS7 user protocols residing on various network nodes need to maintain their existing peer-to-peer relationship when they communicate. SS7 user information maintained in its original form can be transported over IP and facilitate this communication between nodes on a SS7 network, on an IP network or both. A goal is to provide reliable "carrier class" transport of the pure SS7 user information. This document assumes that transport over IP would be based on the Transmission Control Protocol (TCP) suite that is already defined and includes: * UDP (User Datagram Protocol) -- Connectionless Packet Delivery Service which provides efficient but unverified message delivery. * TCP connections -- Reliable Stream Transport Service which is a connection-oriented data delivery service. When used in a sub- network for SS7, would need to be permanently maintained because SS7 nodes are permanent (not fleeting) members of the network community, and reliable service would have to avoid the delay and uncertainty of opening a TCP connection when it is needed. TCP failure detection may take substantial amounts of time. An adaptation layer between MTP Level 3 users and the TCP/IP transport service) needs to provide: * Encapsulation/unencapsulation (to provide MTP transport of MSUs without application processing) * Mapping between SS7 point codes and IP addresses for transfer in both directions between the two networks. As will be seen in the proposals, anIP address might be used in different ways, to identify an emulated SS7 signalling link or to identify the entire SS7 node. * Interfaces to the MTP users above and underlying TCP/IP or UDP/IP transport below. * Other functionality to conform with the SS7 transport characteristics such as performance, reliable in-sequence delivery and signalling network management. The SS7 networks have MTP transfer capabilities and performance requirements. These same capabilities will need to be provided when interfacing with the adaptation layer and transporting over UDP/TCP/IP. The MTP transfer primitives are summarized section 7 and performance objectives are included in the references. In this contribution, "transport" may be regarded as "encapsulation" and not "interworking". "Interworking" implies that there is a mapping between the functions performed by the two protocols. There is no intention to provide such a mapping in this proposal. Transport encapsulation occurs when a common protocol has interfaces to two transport protocols, e.g., in this case, * SS7 MTP users over MTP-3 or over a adaptation layer that emulates MTP-3. * MTP-3 over MTP-2 or over a adaptation layer that emulates MTP-2. The transport of SS7 can be accomplished using UDP or TCP connections over IP. Either can be considered and each places unique requirements on the adaptation layer. Then there are different ways to fit the adaptation layer(s) into the SS7 network stack as well. 2.1 Scope and Limitations To limit the scope of this proposal, capabilities that are not included are: * Do not redefine traditional SS7 STP gateway functionality such as screening * Do not define interworking between different protocols * Do not include interworking between different versions of the same protocols * Do not include SCCP functionality * Assuming that a traditional switch may be decomposed into a signalling gateway and a media gateway, do not attempt to include protocols to accommodate unique requirements between those elements. These capabilities may be useful in a gateway between an SS7 network and an IP sub-network which is used to transport SS7 signalling, but they are not included because they are outside the scope of this contribution. In general, IP transport proposed here will allow nodes without the full SS7 signalling resources to: * provide ISUP connection control and interface with ISUP switches * gain access to services that are part of the Intelligent Network capabilities in traditional SS7 voice networks * inter-operate between circuit networks and Voice-over-IP networks. 3.0 Discussion Following is a list of steps to provide transport of SS7 over IP: 1. Encapsulate the SS7 information in an envelope. SS7 information may be, e.g., ISDN User Part (ISUP), Signalling Connection Control Part (SCCP), probably but not necessarily the Message Transfer Part (MTP), or possibly Transaction Capabilities Application Part (TCAP) directly ("directly" meaning without the MTP/SCCP layers -- normally in SS7, TCAP is over SCCP, a user of the MTP). 2. Provide the necessary protocol to transport this envelope over TCP/IP. This protocol is being called an "adaptation layer". 3. Provide the necessary modifications, if necessary to the existing protocols as required to fit the new protocol into their existing protocol stacks. 4. Remember in the design that this protocol is a peer-to-peer communication layer and does not look inside the envelope or change the contents of the envelope. Only the SS7 processing nodes can do that, using procedures that are already defined. 5. Be sure to consider not only the protocol communication itself but also the performance, delay, message loss, in-sequence delivery, etc. characteristics that provide the SS7 "carrier class" equivalent service that the SS7 users expect. [A variation of this is to consider if there are any special users (e.g., SS7's TCAP simple query/response) which do not require the SS7 "carrier class" service. To accommodate the special needs of these users, there could be compromises of the service (e.g., permitting longer delays or not requiring in-sequence delivery).] 3.1 Network Examples First, consider an SS7 network adjacent to a sub-network that incorporates IP as a transport service. Assume because the end users are SS7, the protocol data unit being transferred is ISUP, SCCP or TCAP. Four types of nodes may be defined: 1. SS7 network Signalling Transfer Point (full MTP capabilities are required) 2. SS7 network Signalling End Points (because there is no STP function, the MTP transfer function and many of the signalling network management functions of MTP Level 3 are not needed) 3. IP network Signalling Transfer Point with full MTP Level 3 (the network diagram would look like SS7 within the IP network) 4. IP network Signalling End Points without STP function, possibly without MTP Level 3, might have only above MTP-3, SCCP as needed. This type of node depends on point-to-point communication among other nodes of the same type and, therefore, does not require the SS7 MTP routing label. Any node of this type may have specific functionality (applications) e.g.,: * SCP - Service Control Point (implies SCCP layer and database application) * SEP - Signalling End Point (implies ISUP) * SSP - Service Switching Point (implies ISUP and SCCP layer). In any case, for the purpose of this transport, the end users are the existing users of the SS7 MTP, i.e., ISUP and SCCP/TCAP. Mate STPs are redundant SS7 network nodes, each with a unique signalling point code but also load sharing capability. In North America, STPs are capable of sharing a common signalling point code for access to identical SCCP functionality that is usually distributed between the two STPs. Similarly, duplicate SS7 interfaces or nodes having identical functionality, such as mate STPs, should be able to share a signalling point code in the IP environment. The specific services of TCP (e.g., TCP connections or UDP datagrams) are discussed later and depend on the needs of the specific adaptation layer being defined. The adaptation layers under the existing SS7 layer and over TCP/IP each have unique needs as will be discussed for each case. Also, this document assumes that the addition of the adaptation layer is intended to minimize the impact on existing SS7 and TCP/IP protocols. 4.0 Proposals The following describes two approaches to providing SS7 transport over TCP/IP, namely to emulate reliable MTP network transport and to provide reliable point-to-point transport. 4.1 Emulate MTP Transport Figure 1 shows a complete SS7 protocol stack with two data link layers (MTP-2 and SAAL) as already defined and two new possible data link layers as could be defined over IP to emulate reliable MTP level 3 transport. 1. SUAL: Signalling UDP/IP Adaptation Layer (the services required of TCP would be UDP datagrams). To provide SS7 quality, UDP transport can be enhanced by providing error monitoring, retransmission and guaranteed in-sequence delivery. (Note that Real Time Protocol (RTP) provides many of these services.) 2. SCAL: Signalling TCP Connection/IP Adaptation Layer (the services required of TCP would TCP connections over IP). In this case, the TCP already provides reliable transport, but is not message-based, and could be used to establish a network of point- to-point connections. Failure detection would have to be faster than usually associated with TCP connections. Figure 1 Adaptation of SS7 and IP network supporting transport of SS7 MTP interface USERS OF SS7 ------------------------------------------------ | | +---------+ +------------------------------+ | TC USER/| | ISDN-UP | | TCAP | | ISDN-UP | +---------+ +------------+ | | | | | +------------------------+ +-----------------+ | SCCP | | +------------------------+ | | | +----------------------------------------------+ | MTP-3 (B-MTP-3) | +----------------------------------------------+ | | | | +-------+ +------+ +---------+ +---------+ | MTP-2 | | SAAL | | SUAL | | SCAL | +-------+ +------+ +---------+ +---------+ | | | | +-------+ +------+ +---------+ +---------+ | MTP-1 | | ATM | | UDP/TCP | | TCP | +-------+ +------+ +---------+ +---------+ | | +----------------------+ | IP | +----------------------+ Both of the examples in Figure 1 require the "full" MTP-3 implementation at each SS7 network node (for SEP or STP as appropriate). Both of these methods communicate with standard SS7 MTP-3, including the newer version over ATM. Both of these methods have the advantage that they provide transparent transport for all MTP users. 4.2 Point-to-Point Transport Figure 2 shows the SS7 protocol stack without the MTP Level 3 layer because the SS7 users need only communicate point-to-point, without the benefit of SS7 MTP networking. This implementation would not require the full MTP-3 at each SS7 network node, e.g., because the nodes have no MTP Level 2 signalling links. Consider two variations of this approach: 1. No MTP-3 routing label is provided because no SS7 point codes need to be involved in the communication. All communication is point-to-point using the IP address of the node interface. If the MTP-3 routing label were omitted, communication with the "standard" SS7 nodes would be excluded. 2. An MTP-3 routing label is provided by the adaptation layer, thus enabling compatibility with other nodes. Any node implementing these interfaces can communicate with any other similar node in either the SS7 or IP network. The network can be a mix of these. The MTP Level 3 routing label can be present, even though full MTP functionality is lacking. This variation then merely distinguishes Figure 2 from Figure 1. If there is a network failure, the adaptation layer must rapidly detect the problem and provide any desired backup to provide SS7 "carrier class" service. Figure 2 Adaptation of SS7 network and IP network supporting transport of SS7 user's interface USERS OF SS7 ------------------------------------------------ | | +---------+ +------------------------------+ | TC USER/| | ISDN-UP | | TCAP | | ISDN-UP | +---------+ +------------+ | | | | | | | +------------------+ +-----------------+ | | SCCP | | | +------------------+ | | | | +----------------------------------------------+ | SPIAL | +----------------------------------------------+ | +----------+ | TCP | +----------+ | +----------+ | IP | +----------+ Adaptation Layer: SPIAL = Signalling Point-to-Point IP Adaptation Layer For transfer of TCAP over IP, two interfaces are shhown. If the services of the SCCP layer are needed, e.g., are used by a peer user at one end of a signalling relation, then the TCAP interfaces with the SCCP layer, which then has an interface with the SPIAP adaptation layer. If a point-to-point signalling relation does not require the SCCP layer, then a direct interface from TCAP to SPIAP could be possible. UDP could also be used with this method, but it is not considered in this contribution only because there is not a comparable transport method for SS7 over ATM, as there is in the datalink case. Three user interfaces are shown and each could each generate unique requirements on the adaptation layer. For example, it is possible for transactions to be simple query/responses, not requiring the message sequencing that is assumed for all SS7 users. This contribution assumes that no distinction should be made among different SS7 user requirements at this time, and the objective should be to develop one common adaptation layer that meets all these users' needs, consistent with an objective of providing SS7 "carrier class" performance and reliability. 4.3 Comparison Many comparisons are possible, but as an introduction, here are major ones: * One set of solutions (Section 4.1) create a datalink layer so the full MTP level 3 routing and signalling network management is available for the network communication. This would use an IP address for each datalink. * The other set of solutions (Section 4.2) is for point-to-point communication and does not have the intermediate network management. This would require an IP address for the virtual SS7 signalling point code. Any network management can be provided in the adaptation layer. * Adaptation layers that depend on TCP connection service have the advantage of reliable delivery already provided. However, they also have the overhead of TCP connections, which might be considerable to support a large network and tweaking to improve the failure response time would only increase the overhead. 5.0 Conclusion and Recommendations Three adaptation layers are described here: 1. Signalling UDP/IP Adaptation Layer 2. Signalling TCP Connection/IP Adaptation Layer (It is probably sufficient to define only #1 or #2) 3. Signalling Point-to-point Adaptation Layer Because any of the adaptation layers may have applicability in particular situations, work should be started to define them. Each solution needs to evaluate the services of the underlying TCP connections or UDP datagrams to ensure that the solution is viable. 6.0 Acronyms ATM Asynchronous Transfer Mode BISDN Broadband ISDN BMTP Broadband MTP IP Internet Protocol ISDN Integrated Services Digital Network ISUP ISDN User Part MTP Message Transfer Part RTP Real Time Protocol SAAL Signalling ATM Adaptation Layer SCCP Signalling Connection Control Part SCP Service Control Point SEP Signalling End Point SSP Service Switching Point SS7 Signalling System No. 7 STP Signalling Transfer Point TCAP Transaction Capabilities Application Part TCP Transmission Control Protocol UDP User Datagram Protocol 7.0 SS7 MTP Transfer Primitives The SS7 networks have MTP transfer capabilities: * primitives MTP Pause/Resume/Congestion * congestion level * Point Code * MTP Transfer * Originating Point Code * Destination Point Code * load sharing parameter (Signaling Link Selection) * Message based, 4k bytes/message, including MTP Level 3 header The requirements imposed on the MTP include undetected errors, message loss, messages out-of-sequence or duplicated, failure response time and MSU transfer time. Relevant Standards for evaluating the needs and performance of MTP transport over IP include are given in the references and are based on the E series documents that are the basis for the performance, Quality of Service, Dependability of Service, etc., of the SS7 series. 8.0 References [1] ITU-T Recommendation Q.700, "Introduction To ITU-T Signalling System No. 7" [2] ITU-T Recommendation Q.701-Q.705, "Signalling System No. 7 (SS7) - Message Transfer Part (MTP)" [3] ITU-T Recommendation Q.706, "Signalling System No. 7 (SS7) - Message Transfer Part Signalling Performance" [3] ITU-T Recommendation Q.709, "Hypothetical Signalling Reference Connection" [4] ITU-T Recommendation Q.711-Q.714, "Signalling System No. 7 (SS7) - SignalingConnection Control Part (SCCP)" [5] ITU-T Recommendation Q.761-Q.764, "Signalling System No. 7 (SS7) - Integrated Services Digital Network User Part (ISUP)" [6] ITU-T Recommendation Q.766, "Performance Objectives in the ISDN Application" [7] ITU-T Recommendation Q.771-775, "Signalling System No. 7 (SS7) - TransactionCapabilities Application Part (TCAP)" 9.0 Author Michael A. McGrew Lucent Technologies, Inc. 6200 East Broad Street Columbus, Ohio 43213 USA Tel: +1-614-860-3585 Email: mmcgrew@lucent.com INTERNET DRAFT Transport SS7 Signalling Over IP Date: November 1998 Expires: May 1999