Why is SCTP needed given TCP and UDP are widely available?MEMBER BRIEFING 17 < Main Index |
10 September 2007 | By Randall Stewart, Paul D. Amer | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DefinitionStream Control Transmission Protocol (SCTP) [RFC2960] is an end-to-end transport protocol that provides services heretofore unavailable from either of the workhorse transport protocols that have supported the Internet for more than twenty years: reliable, connection-oriented TCP [RFC793], or unreliable, connectionless UDP [RFC768]. Why is SCTP needed given TCP and UDP are widely available?In 1998 an IETF working group (SIGTRAN) was formed to design a mechanism for reliably transporting call control signaling over the Internet. SIGTRAN's goal was to create an IP complement to the telephone switching's SS7 network. During SIGTRAN's work, two key problems surfaced in the use of TCP:
SCTP vs TCP vs UDP
Considering these problems, SIGTRAN began work on a new transport protocol to carry its call control signaling over IP. Simultaneously, the IETF transport Area Directors (Scott Bradner and Vern Paxson) recognized the value of solving these problems for a wider audience. They expanded the scope of the work from a small, dedicated protocol for a specific task (SIGTRAN) to a general-purpose transport protocol that other applications could use as well. Within this larger scope, SCTP was born. SCTP also includes the following enhancements: Multistreaming - SCTP supports multiple, independent logical streams of messages within an SCTP association1. Each message sent over an SCTP association is assigned to a particular stream. All data within a stream is delivered in order with respect to other data in that stream. Data in different streams have no order constraints. SCTP's resulting parallel ordered streams provide a specific instance of 'partial ordered' delivery. It is SCTP's multistreaming service that circumvents the head-of-line blocking problem discussed above. Multistreaming has been found to facilitate FTP'ing multiple files, say for system backups or mirror site downloads. Multistreaming also is appropriate for applications that wish to multiplex related, yet independent data streams (e.g., voice, text, video) over a single end-to-end association rather than open multiple TCP connections, one for each stream.
DeploymentSCTP became an RFC in October 2000. As with any new Internet technology, ease of deployment becomes the barrier to widespread use. Currently, all major operating systems have an SCTP implementation. For some, such as BSD Unix, Linux, and Solaris, SCTP comes as part of the OS, or has a patch (or package) that can be added. For other platforms, such as Windows, a third party package must be purchased to add SCTP's advanced feature set. A comprehensive list of SCTP implementations can be found at www.sctp.org. Six workshops since June 2000 have been organized to test interoperability of these implementations. The authors predict increased demand and use of SCTP as more applications find benefits from SCTP's richer set of services. Eventually all OS vendors will respond to customer demands, and supply SCTP out of the box. Until such time, many applications may hesitate to move to SCTP. SummarySCTP offers several advantages. Most important at the application level are SCTP's multistreaming of boundary-preserved messages, and multihoming's added fault tolerance. For example, SCTP is a natural candidate to support telephone signaling over the Internet as well as other message-oriented applications. Applications that require high degrees of fault tolerance, such as online banking and stock market transaction exchanges, will benefit from SCTP's multihoming. A subtle advantage of SCTP's multihoming is that, if widely used by applications where redundancy is critical, multihoming can reduce the widespread routing table growth discussed in ISOC brief #3. Organizations that move their mission critical applications to SCTP can take advantage of multihoming, and not cross-advertise routes (i.e., effectively creating hosts routes in IP routing tables). Using SCTP would thereby yield significant reduction to current Internet routing table sizes. Multihoming within an SCTP association has another interesting side effect in that an association simultaneously spans both IPv6 and IPv4 addresses. Thus SCTP facilitates the transition of the Internet from IPv4 to IPv6. The wider implications of SCTP's "dual stack" nature are undetermined. By its design, SCTP provides for extensibility, which when used judiciously, will provide SCTP with years of usefulness to the Internet community. Enhancements will be easier to introduce while still maintaining inter-operability amongst prior implementations. The authors expect SCTP's many new features will attract current and as yet undiscovered applications as wider scale deployment occurs. Any hesitancy to use SCTP will be overcome by market pressure and the profitable engineering practice of choosing the right transport layer tool for the job. [1] SCTP uses the term association to refer to a connection between two endpoints. A new term was introduced because an SCTP association is broader in scope than a TCP connection. An SCTP association may bind multiple IP addresses at each endpoint whereas TCP binds precisely one address for each endpoint. |
This article is also available in PDF and ASCII Expanded Coverage from ISOCIn-depth articles, papers, links and other resources on a variety of topics are available from the ISOC site at: www.isoc.org/internet/issues Relevant IETF RFCsRFC 3257
SCTP Applicability Statement For More InformationS. Ladha, P. Amer. "Improving multiple file transfers using SCTP multistreaming," Proceedings IPCCC 2004, 4/04 (to appear) A. Caro, J. Iyengar, P. Amer, G. Heinz, S. Ladha, K. Shah. "SCTP: A standard for robust Internet data transport," IEEE Computer, 36(11), 11/03, 56-63 A. Caro, P. Amer, R. Stewart. "Retransmission policies with transport layer multihoming," Proceedings ICON 2003, Sydney, 9/03, 255-260 Related Organizationswww.ietf.org About the AuthorsPaul D. Amer received the BS degree summa cum laude in Mathematics from SUNY Albany in 1974, and the MS and PhD degrees in CIS in 1976 and 1979, respectively, from The Ohio State University. Since 1979, Prof. Amer has been at the University of Delaware's CIS Department. As Director of UD's Protocol Engineering Laboratory (PEL), Prof. Amer and his students currently focus on (1) innovative transport layer services and protocols to improve Internet performance, and (2) data compression in multimedia. Randall Stewart joined Cisco's Internet Technologies Division (ITD) in July of 2000. He is involved in various product solution architectures and core IOS technology. Currently focusing on:
Previous to Cisco, Mr. Stewart worked at Motorola, NYNEX S&T, Nortel and AT&T Communication focusing on fault tolerance and call control signaling protocols, with special focus on integrating SS7 and IP. AcknowledgmentsThe ISOC Member Briefing series is made possible through the generous assistance of ISOC's Platinum Program Sponsors: Afilias, APNIC, ARIN, Microsoft, and the RIPE NCC, Sida. More information on the Platinum Sponsorship Program... About the Background Paper SeriesPublished by: 4, rue des Falaises Email: info@isoc.org Series Editor: Martin Kupres Copyright C Internet Society 2005. |