Stream Control Transmission Protocol

Last updated
Stream Control Transmission Protocol
Protocol stack
AbbreviationSCTP
Introduction2000
OSI layer Transport layer (4)
RFC(s) RFC   9260

The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.

Contents

SCTP is standardized by the Internet Engineering Task Force (IETF) in RFC   9260. The SCTP reference implementation was released as part of FreeBSD version 7, and has since been widely ported to other platforms.

Formal oversight

The IETF Signaling Transport (SIGTRAN) working group defined the protocol (number 132 [1] ) in October 2000, [2] and the IETF Transport Area (TSVWG) working group maintains it. RFC   9260 defines the protocol. RFC   3286 provides an introduction.

Message-based multi-streaming

SCTP applications submit data for transmission in messages (groups of bytes) to the SCTP transport layer. SCTP places messages and control information into separate chunks (data chunks and control chunks), each identified by a chunk header. The protocol can fragment a message into multiple data chunks, but each data chunk contains data from only one user message. SCTP bundles the chunks into SCTP packets. The SCTP packet, which is submitted to the Internet Protocol, consists of a packet header, SCTP control chunks (when necessary), followed by SCTP data chunks (when available).

SCTP may be characterized as message-oriented, meaning it transports a sequence of messages (each being a group of bytes), rather than transporting an unbroken stream of bytes as in TCP. As in UDP, in SCTP a sender sends a message in one operation, and that exact message is passed to the receiving application process in one operation. In contrast, TCP is a stream-oriented protocol, transporting streams of bytes reliably and in order. However TCP does not allow the receiver to know how many times the sender application called on the TCP transport passing it groups of bytes to be sent out. At the sender, TCP simply appends more bytes to a queue of bytes waiting to go out over the network, rather than having to keep a queue of individual separate outbound messages which must be preserved as such.

The term multi-streaming refers to the capability of SCTP to transmit several independent streams of chunks in parallel, for example transmitting web page images simultaneously with the web page text. In essence, it involves bundling several connections into a single SCTP association, operating on messages (or chunks) rather than bytes.

TCP preserves byte order in the stream by including a byte sequence number with each segment. SCTP, on the other hand, assigns a sequence number or a message-id [note 1] to each message sent in a stream. This allows independent ordering of messages in different streams. However, message ordering is optional in SCTP; a receiving application may choose to process messages in the order of receipt instead of in the order of sending.

Features

Features of SCTP include:

The designers of SCTP originally intended it for the transport of telephony (i.e. Signaling System 7) over Internet Protocol, with the goal of duplicating some of the reliability attributes of the SS7 signaling network in IP. This IETF effort is known as SIGTRAN. In the meantime, other uses have been proposed, for example, the Diameter protocol [3] and Reliable Server Pooling (RSerPool). [4]

Motivation and adoption

TCP has provided the primary means to transfer data reliably across the Internet. However, TCP has imposed limitations on several applications. From RFC   4960:

Adoption has been slowed by lack of awareness, lack of implementations (particularly in Microsoft Windows), lack of application support and lack of network support. [6]

SCTP has seen adoption in the mobile telephony space as the transport protocol for several core network interfaces. [7]

Multihoming

SCTP-Multihoming.png
SCTP multihoming
SCTP-LocalMultihoming-RemoteSinglehoming.png
Asymmetric multihoming: local multihoming to remote single homing
SCTP-LocalSinglehoming-RemoteMultihoming.png
Asymmetric multihoming: local single homing to remote multihoming

SCTP provides redundant paths to increase reliability.

Each SCTP end point needs to check reachability of the primary and redundant addresses of the remote end point using a heartbeat. Each SCTP end point needs to acknowledge the heartbeats it receives from the remote end point.

When SCTP sends a message to a remote address, the source interface will only be decided by the routing table of the host (and not by SCTP).

In asymmetric multihoming, one of the two endpoints does not support multihoming.

In local multihoming and remote single homing, if the remote primary address is not reachable, the SCTP association fails even if an alternate path is possible.

Packet structure

An SCTP packet consists of two basic sections:

  1. The common header, which occupies the first 12 bytes and is highlighted in blue.
  2. The data chunks, which occupy the remaining portion of the packet. The first chunk is highlighted in green, and the last of N chunks (Chunk N) is highlighted in red.
Bits0–78–1516–2324–31
+0Source portDestination port
32Verification tag
64Checksum
96Chunk 1 typeChunk 1 flagsChunk 1 length
128Chunk 1 data
Chunk N typeChunk N flagsChunk N length
Chunk N data

Each chunk starts with a one-byte type identifier, with 15 chunk types defined by RFC   9260, and at least 5 more defined by additional RFCs. [note 2] Eight flag bits, a two-byte length field, and the data compose the remainder of the chunk. If the chunk does not form a multiple of 4 bytes (i.e., the length is not a multiple of 4), then it is padded with zeros, which are not included in the chunk length. The two-byte length field limits each chunk to a 65,535-byte length (including the type, flags and length fields).

Security

Although encryption was not part of the original SCTP design, SCTP was designed with features for improved security, such as 4-way handshake (compared to TCP 3-way handshake) to protect against SYN flooding attacks, and large "cookies" for association verification and authenticity.

Reliability was also a key part of the security design of SCTP. Multihoming enables an association to stay open even when some routes and interfaces are down. This is of particular importance for SIGTRAN as it carries SS7 over an IP network using SCTP, and requires strong resilience during link outages to maintain telecommunication service even when enduring network anomalies.

SCTP is sometimes a good fingerprinting candidate. Some operating systems ship with SCTP support enabled, and, as it is not as well known as TCP or UDP, it is sometimes overlooked in firewall and intrusion detection configurations, thus often permitting probing traffic.

Implementations

The SCTP reference implementation runs on FreeBSD, Mac OS X, Microsoft Windows, and Linux. [8]

The following operating systems implement SCTP:

Third-party drivers:

Userspace library:

The following applications implement SCTP:

Tunneling over UDP

In the absence of native SCTP support in operating systems, it is possible to tunnel SCTP over UDP, [22] as well as to map TCP API calls to SCTP calls so existing applications can use SCTP without modification. [23]

RFCs

See also

Notes

  1. The DATA chunk uses a sequence number for ordered messages, the I-DATA chunk, which solves some problems with the original DATA chunk, uses a message-id for all messages
  2. See SCTP packet structure for more details.

Related Research Articles

The Internet protocol suite, commonly known as TCP/IP, is a framework for organizing the set of communication protocols used in the Internet and similar computer networks according to functional criteria. The foundational protocols in the suite are the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP). Early versions of this networking model were known as the Department of Defense (DoD) model because the research and development were funded by the United States Department of Defense through DARPA.

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

In computer networking, the User Datagram Protocol (UDP) is one of the core communication protocols of the Internet protocol suite used to send messages to other hosts on an Internet Protocol (IP) network. Within an IP network, UDP does not require prior communication to set up communication channels or data paths.

<span class="mw-page-title-main">Transport layer</span> Layer in the OSI and TCP/IP models providing host-to-host communication services for applications

In computer networking, the transport layer is a conceptual division of methods in the layered architecture of protocols in the network stack in the Internet protocol suite and the OSI model. The protocols of this layer provide end-to-end communication services for applications. It provides services such as connection-oriented communication, reliability, flow control, and multiplexing.

In computer networking, Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private networks (VPNs) or as part of the delivery of services by ISPs. It uses encryption ('hiding') only for its own control messages, and does not provide any encryption or confidentiality of content by itself. Rather, it provides a tunnel for Layer 2, and the tunnel itself may be passed over a Layer 3 encryption protocol such as IPsec.

In computer networking, the Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. DCCP implements reliable connection setup, teardown, Explicit Congestion Notification (ECN), congestion control, and feature negotiation. The IETF published DCCP as RFC 4340, a proposed standard, in March 2006. RFC 4336 provides an introduction.

Diameter is an authentication, authorization, and accounting protocol for computer networks. It evolved from the earlier RADIUS protocol. It belongs to the application layer protocols in the Internet protocol suite.

<span class="mw-page-title-main">NetFlow</span> Communications protocol

NetFlow is a feature that was introduced on Cisco routers around 1996 that provides the ability to collect IP network traffic as it enters or exits an interface. By analyzing the data provided by NetFlow, a network administrator can determine things such as the source and destination of traffic, class of service, and the causes of congestion. A typical flow monitoring setup consists of three main components:

Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications by allowing them to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport—the application does not suffer from the delays associated with stream protocols, but because it uses UDP or SCTP, the application has to deal with packet reordering, loss of datagram and data larger than the size of a datagram network packet. Because DTLS uses UDP or SCTP rather than TCP, it avoids the "TCP meltdown problem", when being used to create a VPN tunnel.

SIGTRAN is the name, derived from signaling transport, of the former Internet Task Force (I) working group that produced specifications for a family of protocols that provide reliable datagram service and user layer adaptations for Signaling System and ISDN communications protocols. The SIGTRAN protocols are an extension of the SS7 protocol family, and they support the same application and call management paradigms as SS7. However, the SIGTRAN protocols use an Internet Protocol (IP) transport called Stream Control Transmission Protocol (SCTP), instead of TCP or UDP. Indeed, the most significant protocol defined by the SIGTRAN group is SCTP, which is used to carry PSTN signaling over IP.

Anything In Anything (AYIYA) is a computer networking protocol for managing IP tunneling protocols in use between separated Internet Protocol networks. It is most often used to provide IPv6 transit over an IPv4 network link when network address translation masquerades a private network with a single IP address that may change frequently because of DHCP provisioning by Internet service providers.

A network socket is a software structure within a network node of a computer network that serves as an endpoint for sending and receiving data across the network. The structure and properties of a socket are defined by an application programming interface (API) for the networking architecture. Sockets are created only during the lifetime of a process of an application running in the node.

iWARP is a computer networking protocol that implements remote direct memory access (RDMA) for efficient data transfer over Internet Protocol networks. Contrary to some accounts, iWARP is not an acronym.

Multipurpose Transaction Protocol (MTP) software is a proprietary transport protocol developed and marketed by Data Expedition, Inc. (DEI). DEI claims that MTP offers superior performance and reliability when compared to the Transmission Control Protocol (TCP) transport protocol.

The Stream Control Transmission Protocol (SCTP) has a simpler basic packet structure than TCP. Each consists of two basic sections:

  1. The common header, which occupies the first 12 bytes. In the adjacent diagram, this header is highlighted in blue.
  2. The data chunks, which form the remaining portion of the packet. In the diagram, the first chunk is highlighted in green and the last of N chunks (Chunk N) is highlighted in red. There are several types, including payload data and different control messages.

RDMA over Converged Ethernet (RoCE) or InfiniBand over Ethernet (IBoE) is a network protocol which allows remote direct memory access (RDMA) over an Ethernet network. It does this by encapsulating an InfiniBand (IB) transport packet over Ethernet. There are multiple RoCE versions. RoCE v1 is an Ethernet link layer protocol and hence allows communication between any two hosts in the same Ethernet broadcast domain. RoCE v2 is an internet layer protocol which means that RoCE v2 packets can be routed. Although the RoCE protocol benefits from the characteristics of a converged Ethernet network, the protocol can also be used on a traditional or non-converged Ethernet network.

QUIC is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google, implemented, and deployed in 2012, announced publicly in 2013 as experimentation broadened, and described at an IETF meeting. QUIC is used by more than half of all connections from the Chrome web browser to Google's servers. Microsoft Edge, Firefox, and Safari support it.

NACK-Oriented Reliable Multicast (NORM) is a transport layer Internet protocol designed to provide reliable transport in multicast groups in data networks. It is formally defined by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 5740, which was published in November 2009.

Secure Reliable Transport (SRT) is an open source video transport protocol that utilises the UDP transport protocol. The SRT Protocol specification is available as an Internet Draft from the IETF.

References

  1. "Protocol Numbers". iana.org. IANA . Retrieved 2014-09-09.
  2. Stream Control Transmission Protocol. IETF. October 2000. doi: 10.17487/RFC2960 . RFC 2960.
  3. "Transport". Diameter Base Protocol. IETF. sec. 2.1. doi: 10.17487/RFC3588 . RFC 3588 . Retrieved 2012-05-18.
  4. "Example Scenario Using RSerPool Session Services". An Overview of Reliable Server Pooling Protocols. IETF. p. 10. sec. 4.2. doi: 10.17487/RFC5351 . RFC 5351.
  5. RFC 9260, section 1.5.5
  6. Hogg, Scott. "What About Stream Control Transmission Protocol (SCTP)?". Network World. Archived from the original on August 30, 2014. Retrieved 2017-10-04.
  7. Olsson, Magnus; Mulligan, Catherine; Sultana, Shabnam; Rommer, Stefan; Frid, Lars (2013). EPC and 4G packet networks: driving the mobile broadband revolution (2nd ed.). Amsterdam Boston: Elsevier/AP, Academic Press is an imprint of Elsevier. p. 491. ISBN   978-0-12-394595-2.
  8. "Reference Implementation for SCTP - RFC4960". GitHub . Retrieved 2013-10-14. This is the reference implementation for SCTP. It is portable and runs on FreeBSD/MAC-OS/Windows and in User Space (including linux).
  9. "sys/netinet/sctp.h". BSD Cross Reference. NetBSD. 2017-06-27. Retrieved 2019-01-21.
  10. "man4/sctp.4". BSD Cross Reference. NetBSD. 2018-07-31. Retrieved 2019-01-21.
  11. "DragonFly Removes SCTP". Lists.dragonflybsd.org. Retrieved 2016-04-28.
  12. "About FreeBSD's Technological Advances". The FreeBSD Project. 2008-03-09. Retrieved 2008-09-13. SCTP: FreeBSD 7.0 is the reference implementation for the new IETF Stream Control Transmission Protocol (SCTP) protocol, intended to support VoIP, telecommunications, and other applications with strong reliability and variable quality transmission through features such as multi-path delivery, fail-over, and multi-streaming.
  13. "Stream Control Transmission Protocol (SCTP)". Hewlett-Packard Development Company. Archived from the original on 2013-01-03.
  14. "TCP/IP Networking". QNX Developer Support. QNX Software Systems. Retrieved 2008-09-13. "What's New in this Reference". QNX Library Reference. QNX Software Systems. Retrieved 2012-12-18.
  15. "QNX Software Development Platform 6.4.0".
  16. "Solaris 10 Operating System Networking — Extreme Network Performance". Sun Microsystems . Retrieved 2008-09-13.
  17. "SctpDrv: an SCTP driver for Microsoft Windows". Archived from the original on 2017-10-08. Retrieved 2022-01-04.
  18. "SCTP Network Kernel Extension for Mac OS X". GitHub . 23 September 2021.
  19. "sctplab/usrsctp". Github. Retrieved 21 September 2021.
  20. "SCTP Download Page". 2006-05-29. Retrieved 2011-02-04.
  21. "Windows SCTP library installer" . Retrieved 2011-02-04.
  22. Tuexen, Michael; Stewart, Randall R. (May 2013). UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication. IETF. doi: 10.17487/RFC6951 . RFC 6951.
  23. Bickhart, Ryan; Paul D. Amer; Randall R. Stewart (2007). "Transparent TCP-to-SCTP Translation Shim Layer" (PDF). Retrieved 2008-09-13.
  24. D. Wing; A. Yourtchenko (April 2012). "Happy Eyeballs: Success with Dual-Stack Hosts". tools.ietf.org. IETF.
  25. Khademi, Naeem; Brunstrom, Anna; Hurtig, Per; Grinnemo, Karl-Johan (July 21, 2016). "Happy Eyeballs for Transport Selection". tools.ietf.org. IETF . Retrieved 2017-01-09.