Internet Engineering Task Force INTERNET-DRAFT Authors Transport Working Group Ian Rytina, Ericsson Category: Informational Lyndon Ong, Nortel Networks June 1999 Expires: January 2000 Framework for SIGTRAN Common Transport Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document outlines a framework for the Sigtran protocol that consists of a modular, extensible structure with a common reliable transport protocol used for all signaling transport. This structure initially allows for narrowband SCN signalling protocols to be transported over an IP network in order to support TDM to IP interworking of voice and data services, and allows the protocol to be extended for future use as required. The reliable transport protocol addresses a set of requirements for signaling transport which include persistent associations, reliable data transport and sequence preservation (within a control stream). These requirements imply a TCP-like protocol, with added functions to support: -- elimination of head-of-line blocking -- rapid detection of session failure -- failover to backup session or port -- improved transport delay characteristics suited to signaling. The functional characteristics for the signaling common transport protocol are described in greater detail in the document, and these are compared with TCP characteristics. 1. Introduction 1.1 Overview This document outlines a framework for the Sigtran protocol. The framework provides a modular structure using a common reliable transport protocol for transport needs, and allowing definition of adaptation modules for different SCN control protocols to be added as extensions, without affecting the transport protocol itself. This will allow progress to be made initially on a set of "key" SCN protocols for the first stage of Sigtran activities, and adaptation modules supporting additional protocols to be added at a later date, as required. 1.2 Terminology The following general term is used in this document: Signaling Common Transport Protocol : This is a generic term used to describe the protocol used to transport SCN signaling protocols over IP. It is assumed to have a modular structure that uses UDP for underlying transport functions, but adds functions such as reliability, sequenced delivery, etc., as needed for SCN signaling transport (see also [1]). 1.3 Scope Signaling transport focuses on transparent transport of SCN signaling protocols over IP networks. The signaling transport protocol will be defined in such a way as to support encapsulation and carriage of a variety of application and call control protocols. For more information refer to [1]. It is the intention that the signaling transport protocol be designed in an open manner so that it can be integrated with multimedia frameworks such as H.323 and SIP, to provide transport of SCN protocols in such systems. 2. Protocol Framework Architecture 2.1 Signaling Transport Components The basic architecture, as defined in [1], is as in Figure 1 :- SCN Protocols | | | +--------------------------------+ | SCN Adaptation modules | +--------------------------------+ | +--------------------------------+ | Common Signaling Transport | +--------------------------------+ | +--------------------------------+ | Standard IP Transport | +--------------------------------+ | Network Layer (IP) Figure 1: Signaling Transport Components The three components of Signaling Transport are :- 1) adaptation modules that support specific primitives, e.g. management indications, required by a particular SCN signaling application protocol. 2) a Signaling Common Transport Protocol that supports a common set of reliable transport functions for signaling transport. 3) a standard IP transport protocol (TCP/UDP) provided by the operating system. In some network scenarios, it has been recognised that TCP can provide limited (but sufficient) reliable transport functionality for signaling, and this is discussed later in this document. In order to provide a generic modular structure, the architecture can be further decomposed to allow full optionality according to the SCN protocol being transported. This architecture is outlined in Figure 2a (for UDP) and Figure 2b (for TCP). (*1) || || || || || +------------------+ +------------------------------------+ | |--| Adaptation Modules (ADAL1....ADALn)| | | +------------------------------------+ | | ||(*2) | | +------------------------------------+ | |--| Sequencing Sublayer | | Layer Control | +------------------------------------+ | and | || | Layer Management | +------------------------------------+ | |--| Reliability Sublayer | | | +------------------------------------+ | | || | | +------------------------------------+ | |--| Link Sublayer | +------------------+ +------------------------------------+ ||(*3) +------------------------------------+ | UDP | +------------------------------------+ || = Data | = Management Figure 2a: Signaling Transport Sublayers (Underlying Transport Protocol is UDP) Published (open) interfaces are :- (*1) SCN primitives. Initially, MTP3-user, MTP2-user, Q.921-user. (*2) Common Signaling Transport Protocol upper primitives. (*3) UDP upper primitives. (*1) || || || || || +------------------+ +------------------------------------+ | Layer Control |--| Adaptation Modules (ADAL1....ADALn)| | and | +------------------------------------+ | Layer Management | || +------------------+ ||(*4) +------------------------------------+ | TCP | +------------------------------------+ || = Data | = Management Figure 2b: Signaling Transport Sublayers (Underlying Transport Protocol is TCP) TCP provides the sequencing, reliability and link sublayers, hence these sublayers are null. The published (open) interfaces are :- (*1) SCN primitives. (*4) TCP upper primitives. 2.2 Definition of Sublayer Functionality The function of the sublayers described in Figures 2a and 2b can be defined as follows :- - Link, Reliability, Sequencing sublayers are the Signaling Common Transport Protocol. These sublayers are not exposed to external view, and are only used to model the functions of the Signaling Common Transport Protocol. These sublayers will be empty/null, according to whether the underlying transport is UDP or TCP. The protocol will be based on MDTP [2]. - The Adaptation Modules (ADAL1....ADALn) make up the sublayer that describes the functions expected by a particular SCN signaling protocol. For example, one such function could be the mapping of different SCN primitives to the Signaling Common Transport Protocol primitives (and vice versa). In order to meet the extensibility requirement for transporting existing and future SCN signaling protocols [1] the structure of this sublayer must be made generic, and easily extensible. Two current examples of adaptation modules are the Backhaul Manager [3] and SS7 ISUP Tunneling [4]. 2.3 Peer-to-Peer Relationship The relationship between two peer entities is described in Figure 3. || || || || || || || || +-------+ +--------------------+ +--------------------+ +-------+ | |-| Adaptation Modules |<=====>| Adaptation Modules |-| | | | +--------------------+ +--------------------+ | | | | || || | | | | +--------------------+ +--------------------+ | | | Layer |-| Sequencing SL |<=====>| Sequencing SL |-| Layer | |Control| +--------------------+ +--------------------+ |Control| | & | || || | & | | Mgmnt | +--------------------+ +--------------------+ | Mgmnt | | |-| Reliability SL |<=====>| Reliability SL |-| | | | +--------------------+ +--------------------+ | | | | || || | | | | +--------------------+ +--------------------+ | | | |-| Link SL |<=====>| Link SL |-| | +-------+ +--------------------+ +--------------------+ +-------+ || || +--------------------+ +--------------------+ | TCP/UDP | | TCP/UDP | +--------------------+ +--------------------+ || || +-------------------------------------------------+ | Network Layer (IP) | +-------------------------------------------------+ || = Data | = Management Figure 3: Peer-to-Peer Relationship 3. Generic Protocol Framework 3.1 Generic Protocol Structure The set of SCN control protocols which are to be supported is potentially very large. Since there are many SCN protocols, each with different requirements, this is best addressed by a modular framework which allows addition of modules to support SCN protocols not addressed in the initial specification. The advantage of the architecture described in Section 2 is that it assumes that all SCN protocols have similar transport requirements, so that the only protocol specific considerations are in the adaptation modules. One proposal is that an adaptation module document (RFC) is written for each SCN protocol. (To be decided) Initial work will be carried out on mapping the MTP3-user, the MTP2-user and the Q.921-user primitives to the upper primitives of the Signaling Common Transport Protocol [2]. 3.2 Registration aspects TBD, possibly required to register with IANA for Protocol Identifier, and Port Numbers. 4. Signaling Common Transport Protocol This section documents the reasoning behind the need to use a transport protocol that has similar functionality to TCP (i.e. link, reliability and sequencing) but also suggesting added functions that are specific for signaling transport but are not provided by current TCP. 4.1 Requirements for Signaling Transport Based on the architecture for signaling transport [1], it can be determined that transport of SCN control protocols will have the following requirements: (a) Persistent Associations The applications identified in [1] require transport of signaling messages multiplexed from many different interactions (e.g., many different calls). As a result, the transport association should be persistent, and setup of the association is small relative to the duration of the association. (b) Reliable Transport The performance requirements identified in [1] require that the transport protocol carries data reliably and with minimal errors. (c) Time-Dependent Transport The nature of signaling adds some time-dependency to transport requirements: signaling messages that are delayed in transport are in most cases no longer useful, because the associated SCN protocol or the user will time out and take alternative actions. (d) Availability Since multiplexed signaling affects a large number of users (for example, a single 56 Kbps SS7 link may support signaling for 50,000 individual calls per hour), availability of signaling transport must be high, often implemented through use of redundancy of devices and ports. 4.2 Functions Comparable to TCP A number of the functions for signaling transport can be met by use of TCP for transport, especially: - persistent associations - reliable transport - sequence preservation 4.3 Functions Beyond Current TCP Signaling transport ideally would support a number of functions that are not provided by current TCP: - no head-of-line blocking, i.e. multiple streams - multilink failover for added reliability - keep-alive function for active rapid failure detection - message verses byte sequence numbering - tighter timer control (than standard TCP implementations) - greater fan out (than standard TCP implementations) 4.4 TCP for Reliable Transport It is possible to use TCP for reliable transport, however, certain features will not be provided as identified in the previous section. Also, certain features of TCP may need to be turned off in order to avoid interference with signaling transport requirements. Some of these, for example, are :- - use of the Nagle algorithm (adds delay) - tbd 4.5 Security Since signaling affects a large number of users and carries potentially sensitive information, security is extremely important. SCN protocols are protected by running over private links, and care should be taken to continue this practice when running over IP. When the Signaling Common Transport Protocol is used over a shared IP network, such as the Internet, IPsec protocols (RFC2401, RFC2411) should be used to secure the data and to protect the header of the IP packet. 5. Functions of Target Signaling Common Transport Protocol The following basic functions are provided by the target Signaling Common Transport Protocol :- - Initialization of transport association - Synchronization of association state - Synchronization of sequence numbering - Reliable Data Transfer - Forward and backward sequence numbering - Timers for transmission and acknowledgement - Notification of out-of-sequence - Retransmission of lost messages - Support of multiple control streams - Separate sequence control and delivery of each stream - Request to open new streams - Congestion control - Window flow control - Congestion avoidance based on on TCP methods, e.g. using retransmission backoff, window reduction, etc. - Detection of session failure by active means, e.g. heartbeat - Termination of association 6. References [1] L.Ong, I.Rytina, et al :- Architectural Framework for Signaling Transport , June 1999, work in progress. [2] R. Stewart, Q. Xie, et al :- Multi-Network Datagram Transmission Protocol , June 1999, work in progress. [3] D. Auerbach, D. Berg, K, Morneault :- Signaling Backhaul Protocol , February 1999, work in progress. [4] G. Sidebottom, L. Ong, I. Rytina :- SS7 ISUP Tunneling , June 1999, work in progress. Acknowledgements Credit for the basic architecture diagram should be given to Tom Taylor for supplying the original decomposition. The authors would also like to thank M. Holdridge, C. Sharp and G. Sidebottom for their valuable comments and suggestions. Authors' Addresses Ian Rytina, Lyndon Ong Ericsson Australia, Nortel Networks 37/360 Elizabeth Street, 4401 Great America Parkway Melbourne, Victoria 3000 Santa Clara, CA 95054 Australia USA ian.rytina@ericsson.com long@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (1998). 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 implementation 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 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. This Internet Draft expires in 6 months from June 1999.