Individual Submission Internet Draft J. Loughney (editor) Document: draft-loughney-sctp-sig-prot-00.txt Raquel Sanchez Nokia Expires: December 2002 June 2002 SCTP Layer for Transporting Signaling Protocols Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 The Stream Control Transport Protocol (SCTP) has been standardized to provide a reliable transport services for signaling protocols. SCTP features a number of new features that are useful for transporting signaling protocols, but may require additional information on how to use them to transport existing signaling protocols. Loughney Expires - December 2002 [Page 1] SCTP Layer for Transporting Signaling Protocols June 2002 Table of Contents 1. Introduction...................................................3 1.1 Motivation.................................................3 1.2 Architectural view of SCTP Handler.........................3 1.3 Functional view of SCTP Handler............................3 1.4 Definitions................................................4 1.5 Abbreviations..............................................4 2. Conventions Used in this Document..............................4 3. Services Provided by SCTP Handler..............................5 4. Features of SCTP Handler.......................................5 4.1 Usage of SCTP Associations.................................5 4.2 Usage of SCTP Streams......................................5 4.3 Data Transfer..............................................5 4.4 Identifiers................................................5 4.5 Client-Server Behavior.....................................6 5. Security Considerations........................................6 6. IANA Considerations............................................6 7. References.....................................................6 8. Acknowledgments................................................6 9. Author's Addresses.............................................6 Loughney, et. al Expires - December 2002 [Page 2] SCTP Layer for Transporting Signaling Protocols June 2002 1. Introduction SCTP has been proposed as a reliable transport for signaling protocols. SCTP has a number of features that are desirable for transporting signaling protocols. This document proposes how these features can be used by protocols. Additionally, an example is provided of how an existing protocol can directly use SCTP. 1.1 Motivation Current work in the SIGTRAN Working Group [2719] defines architecture for backhauling SS7 Signalling Protocols over IP. However, no consideration is given for signaling that is completely terminated in IP networks (sometimes called 'all-IP' or 'full-IP' signaling). There is a desire to use SCTP directly for signaling in many networks. However, as SCTP brings new features, many of which may not be able to be directly supported by existing signaling application protocols. On the other hand, currently proposed layer structure for mobile telephone networks, for example, consists on too many layers (based on SS7 protocol stack). As the number of layers increases, the complexity increases and the performance is decreased. Therefore, there is a need to optimize the current control plane protocol stacks (SCCP based). An alternative is the usage of very light adaptation layer on top of SCTP that provides the same services than the based on SS7 protocol stack. The goal of this document is to discuss issues affecting this and to propose a thin layer, as an extended API to SCTP, to allow transport of existing protocols. 1.2 Architectural view of SCTP Handler The SCTP Handler is seen as an extension to the current SCTP API. The socket API is considered in this document, but the proposals are more general and are applicable to other APIs for SCTP. The SCTP Handler allows a much lighter protocol stack, optimized for the transport of typical application part protocols (ex: RANAP, RNSAP, BSSAP) over IP. Optimization is possible by removing the not needed and the redundant functionality provided by the signaling protocol stacks. 1.3 Functional view of SCTP Handler Loughney, et. al Expires - December 2002 [Page 3] SCTP Layer for Transporting Signaling Protocols June 2002 TBD 1.4 Definitions SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time. SCTP endpoint: The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint. SCTP Stream: An unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. Multi-streaming: SCTP feature that allows data to be partitioned into multiple streams that have the property of being delivered independently, so that message loss in any of the streams will only affect delivery within that stream, and not in other streams. 1.5 Abbreviations BSSAP - Base Station Subsystem Application Part IKE - Internet Key Exchange M3UA - SS7 MTP3 User Adaptation Layer PKI - Public Key Infrastructure RANAP - Radio Access Network Application Part RNSAP - Radio Network Subsystem Application Part SCCP - Signalling Connection Control Part SCTP - Stream Control Transmission Protocol SS7 - ITU-T Signalling System No 7 TLS - Transport Layer Security VPN - Virtual Private Network 2. Conventions Used in this Document Loughney, et. al Expires - December 2002 [Page 4] SCTP Layer for Transporting Signaling Protocols June 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Services Provided by SCTP Handler The following is a list of functions that the SCTP is assumed to provide: * SCTP Association Usage * Stream ID management & Usage * Upper Layer Protocol Identifier Management * Client-Server Considerations * Support for connection-oriented and connection-less signaling 4. Features of SCTP Handler 4.1 Usage of SCTP Associations Matching of SCTP associations / SCTP endpoints to signaling application endpoints is somewhat of an issue. This is related to how entities are addressed in an SS7 environment. The SCTP handler should take this into consideration. 4.2 Usage of SCTP Streams Existing applications may not be able to use SCTP streams [add reference]. SCTP streams are uni-directional, however many application protocols may assume a bi-directional flow of traffic. The SCTP handler should manage the SCTP streams for the user (the upper layer signaling protocol). 4.3 Data Transfer TBD 4.4 Identifiers SS7 protocols have a different addressing model than IP. Some layers are hop-by-hop and do not assume global addressing. It may be reasonable to assume that SS7 addressing will not disappear; however overlaying non-global addressing on top of IP is not a reasonable long-term assumption. In practice, it may be useful to consider SS7 addresses as labels, rather than point codes when signaling in an IP network. Loughney, et. al Expires - December 2002 [Page 5] SCTP Layer for Transporting Signaling Protocols June 2002 4.5 Client-Server Behavior Many signaling protocols are client-server in nature; while SCTP is peer-to-peer. SCTP handler should provide any specific client-server behavior. 5. Security Considerations Traditionally telephony networks have been considered closed and/or trusted networks. By integrating them into the Internet, there are security concerns. It is assumed that the signaling protocols will need encryption. Currently, the recommended ways are using TLS with SCTP or IPsec and SCTP. SCTP and IKE are seen as a good solution for creating virtual private networks (VPNs) on an intra-domain signaling case. However, for interdomain signaling, there is an issue with use of IKE without a global PKI. TLS handles cert exchanges quite well and may be preferable than IPsec in this circumstance. 6. IANA Considerations It may be necessary to apply for an SCTP Payload identifier. 7. References [2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2719] RFC 2719, "Framework Architecture for Signaling Transport" [2960] R. Steward, et. al, "Stream Control Transmission Protocol", RFC 2960. 8. Acknowledgments The authors would like to thank Markus Ahokangas, Ivan Arias- Rodriguez, Jouko Kapanen, Sami Kekki, Fabio Longoni, Janne Marin, Tuomas Niemela, Gabriel Ramos-Escano, Haluk Tekbulut, Janne Tervonen, Shaoji Ni and Seppo Vesterinen. 9. Author's Addresses Loughney, et. al Expires - December 2002 [Page 6] SCTP Layer for Transporting Signaling Protocols June 2002 John Loughney Nokia Research Center It„lahdenkatu 11-13 00180 Helsinki Finland Phone: +358 50 483 6242 Email: john.Loughney@nokia.com Raquel Sanchez C/. Severo Ochoa, s/n Edif. de Inst. Universitarios, Pl. 3 Parque Tecnolgico de Andaluca Campanillas Mßlaga, 29590 Spain Phone: +34952028519 Email: raquel.sanchez@nokia.com Loughney, et. al Expires - December 2002 [Page 7]