How SCTP Works: Multi-Streaming and Multi-Homing Transport Protocol

Stream Control Transmission Protocol (SCTP) is a transport-layer protocol that combines the reliability of TCP with the message-oriented design of UDP, while adding capabilities that neither protocol offers: native multi-streaming, multi-homing, and a four-way handshake resistant to SYN flood attacks. Originally designed for carrying telephony signaling over IP networks (SIGTRAN), SCTP has become the transport protocol of choice in telecom infrastructure -- it is the mandatory transport for control-plane signaling in both 4G LTE and 5G NR networks. Standardized in RFC 4960 (2007) and updated by RFC 9260 (2022), SCTP operates at the same layer as TCP and UDP but provides a fundamentally different abstraction: multiple independent, ordered (or unordered) message streams within a single association, with transparent failover across multiple network paths.

While SCTP never displaced TCP for general web traffic -- that role is being filled by QUIC -- it remains indispensable in the telecom core. Every time you make a phone call, send a text, or your device attaches to a cell tower, SCTP associations are carrying the signaling that makes it happen. Understanding SCTP means understanding how the infrastructure beneath mobile networks actually works.

Why SCTP Exists: The Problem with TCP for Signaling

In the late 1990s, the telecom industry needed to migrate its signaling protocols -- SS7 and its siblings -- from dedicated TDM (Time-Division Multiplexing) circuits to IP networks. TCP was the obvious candidate for reliable transport, but it had several properties that made it a poor fit for signaling traffic:

• Head-of-line blocking -- TCP delivers data as a single, ordered byte stream. If a packet carrying signaling message A is lost, TCP blocks delivery of messages B, C, and D (which may be completely unrelated calls) until A is retransmitted. In a signaling system handling thousands of independent call setups per second, this is catastrophic.
• No multi-homing -- TCP binds a connection to a single IP address pair. If the network path fails, the connection dies and must be re-established. Telecom signaling links require carrier-grade availability -- five nines (99.999%) or better, meaning less than 5.26 minutes of downtime per year.
• Byte-stream model -- TCP provides a stream of bytes with no inherent message boundaries. Signaling protocols work with discrete messages, so TCP requires application-level framing to reconstruct message boundaries. This adds complexity and failure modes.
• SYN flood vulnerability -- TCP's three-way handshake requires the server to allocate state on the first SYN. For critical signaling infrastructure, this is an unacceptable attack surface.

SCTP was designed from scratch to solve all four problems. The IETF published it as RFC 2960 in October 2000, with RFC 4960 replacing it in 2007, and RFC 9260 providing the current consolidated specification in 2022.

Associations, Not Connections

SCTP uses the term association rather than connection. This is not a cosmetic difference. A TCP connection is a relationship between two IP-address-and-port pairs. An SCTP association is a relationship between two endpoints, where each endpoint can have multiple IP addresses. The association is identified by a Verification Tag -- a 32-bit random value chosen during setup -- rather than by the IP/port tuple. This design is what enables multi-homing: an SCTP endpoint can be reachable at 10.0.1.5 and 10.0.2.5 simultaneously, and the association continues to function if either address becomes unreachable.

An association also carries multiple streams -- independent sequences of messages flowing in each direction. The number of streams is negotiated during the handshake. Messages within a stream are delivered in order (by default), but messages on different streams are completely independent. Loss on stream 3 does not block delivery on stream 7. This is precisely the multi-streaming that TCP lacks and that QUIC later adopted for web traffic.

The Four-Way Handshake

SCTP establishes associations using a four-way handshake with a cryptographic cookie mechanism that prevents state exhaustion attacks. Unlike TCP's three-way handshake, the SCTP server does not allocate any state until the client proves it can receive traffic at its claimed address.

The handshake proceeds in four steps:

1. INIT -- The client (Endpoint A) sends an INIT chunk containing its Initiate Tag (a random 32-bit value), its advertised receiver window (A-RWND), the number of outbound streams (OS) it wants, the maximum number of inbound streams (MIS) it will accept, and its Initial Transmission Sequence Number (TSN). It may also include its list of IP addresses if multi-homed.
2. INIT-ACK -- The server (Endpoint Z) responds with its own parameters and, critically, a State Cookie. This cookie is an opaque blob that contains all the state the server would need to establish the association -- both endpoints' parameters, a timestamp, and an HMAC signature using a server-secret key. The server does not allocate a Transmission Control Block (TCB) at this point. It computes the cookie, sends the INIT-ACK, and forgets about the exchange. This is the key defense against resource exhaustion attacks.
3. COOKIE-ECHO -- The client echoes the cookie back to the server. This proves the client can receive traffic at the address it claimed in the INIT (since it received the INIT-ACK there). The COOKIE-ECHO chunk may also bundle DATA chunks, allowing the client to send application data in this same packet.
4. COOKIE-ACK -- The server validates the cookie by verifying the HMAC and checking the timestamp (to reject stale cookies). Only now does it allocate the TCB and create the association. It sends COOKIE-ACK to confirm, and the association is established.

The four-way handshake costs two round trips (2-RTT), one more than TCP's three-way handshake. However, because the COOKIE-ECHO can bundle DATA, the effective cost for the first application message is the same 2-RTT as TCP+data. The tradeoff is that the server is completely immune to blind INIT flood attacks -- an attacker sending millions of INIT chunks from spoofed addresses causes the server to compute cookies and send INIT-ACKs, but no state is allocated until a valid COOKIE-ECHO arrives from a real, reachable address.

Chunks: The Building Blocks of SCTP Packets

Where TCP has a single segment format and UDP has a single datagram format, SCTP packets are composed of one or more chunks. An SCTP packet begins with a 12-byte common header (source port, destination port, verification tag, checksum) followed by a variable number of chunks, each with its own type, flags, and length. This design allows SCTP to bundle control and data information in a single packet, reducing overhead.

The most important chunk types are:

• DATA -- Carries user data. Each DATA chunk contains a Transmission Sequence Number (TSN), a Stream Identifier (SID), a Stream Sequence Number (SSN), and a Payload Protocol Identifier (PPID). The TSN is used for reliable delivery across the entire association. The SID and SSN are used for per-stream ordering.
• SACK (Selective Acknowledgment) -- Acknowledges received DATA chunks. Unlike TCP's cumulative-only ACK (extended by TCP SACK option), SCTP's SACK is selective by default. Every SACK reports the cumulative TSN acknowledged plus gap blocks indicating any out-of-order chunks already received. This allows the sender to retransmit only truly lost chunks without ambiguity.
• HEARTBEAT / HEARTBEAT-ACK -- Probes and confirms reachability of alternate paths (used for multi-homing).
• INIT / INIT-ACK / COOKIE-ECHO / COOKIE-ACK -- The handshake chunks described above.
• SHUTDOWN / SHUTDOWN-ACK / SHUTDOWN-COMPLETE -- Graceful association teardown (a three-way shutdown, compared to TCP's four-way FIN exchange).
• ABORT -- Immediate, ungraceful teardown with no waiting state.
• ERROR -- Reports non-fatal error conditions to the peer.
• FORWARD-TSN -- Used by the Partial Reliability extension (PR-SCTP, RFC 3758) to tell the receiver that certain TSNs will never be retransmitted and can be skipped.

Multiple chunks can be bundled in a single SCTP packet. For example, a single packet might contain a SACK chunk (acknowledging previously received data) followed by two DATA chunks (carrying new messages on different streams). This bundling reduces the number of packets on the wire, which is particularly valuable when the bottleneck is per-packet processing overhead rather than bandwidth.

Multi-Streaming: Independent Message Channels

Multi-streaming is SCTP's solution to the head-of-line blocking problem that plagues TCP. When an SCTP association is established, both endpoints agree on the number of streams in each direction (via the OS and MIS parameters in the INIT/INIT-ACK). Each stream is an independent sequence of messages.

Within a single stream, messages are delivered in order by default. If DATA chunk with SSN 5 on stream 3 is lost, subsequent chunks on stream 3 (SSN 6, 7, ...) are buffered until SSN 5 is retransmitted and received. But chunks on streams 0, 1, 2, 4, and all other streams are delivered immediately -- they are completely unaffected by the loss on stream 3.

This is the same conceptual model that QUIC later adopted for HTTP/3. The key difference is that SCTP was designed for message-oriented signaling traffic in 2000, while QUIC was designed for web traffic in the 2010s. SCTP delivers discrete messages with preserved boundaries; QUIC provides byte streams (though with independent ordering per stream).

Ordered vs. Unordered Delivery

SCTP offers a choice that neither TCP nor UDP provides: per-message ordering control. Each DATA chunk has an Unordered (U) flag. When the U flag is set, the chunk is delivered to the application as soon as it is completely received and reassembled, regardless of its SSN or whether earlier chunks on the same stream have been delivered. When the U flag is clear, normal in-order delivery applies within the stream.

This is powerful for signaling applications. Consider a telecom signaling link carrying both call setup messages and network management messages. Call setup messages for the same call must be ordered (you cannot process a call answer before the call setup). But a network management notification is independent and should be delivered immediately, even if an unrelated call setup message was lost. SCTP lets the application choose, per message, whether ordering matters.

Multi-Homing and Path Management

Multi-homing is SCTP's most distinctive feature from a network resilience perspective. An SCTP endpoint can bind to multiple IP addresses, and these addresses are exchanged during the handshake (in the INIT and INIT-ACK chunks). The association then has a primary path (used for normal data transfer) and one or more alternate paths (used for failover).

Heartbeat Mechanism

SCTP keeps alternate paths warm using a heartbeat mechanism. The endpoint periodically sends HEARTBEAT chunks to each remote address that is not currently receiving data traffic. The HEARTBEAT contains an opaque Heartbeat Information field (typically including a timestamp and the destination address) which the peer echoes back in a HEARTBEAT-ACK. This serves multiple purposes:

• Reachability verification -- If a HEARTBEAT-ACK is not received within the retransmission timeout (RTO), the path error counter for that destination is incremented. If the counter exceeds Path.Max.Retrans (default 5), the path is marked as inactive.
• RTT measurement -- The timestamp in the heartbeat allows the sender to measure the round-trip time to the alternate path, which is used to compute the RTO for that path.
• NAT keepalive -- Periodic heartbeats prevent NAT middleboxes from expiring the mapping for the alternate path.

The heartbeat interval is configurable but defaults to 30 seconds plus a random jitter of 0 to RTO.Max (default 60 seconds). This jitter prevents synchronized heartbeats from multiple associations from creating traffic bursts.

Path Failover

When a DATA chunk sent on the primary path is not acknowledged and the retransmission timer expires, SCTP retransmits the chunk on an alternate path. If the primary path continues to fail -- specifically, if the path error counter exceeds Path.Max.Retrans -- SCTP automatically switches all new data transmission to the alternate path. The association remains active throughout; no re-handshake is needed.

The failover is transparent to the application. From the application's perspective, there may be a brief pause in data delivery (while retransmissions are in flight), but the association never drops. This is the fundamental availability guarantee that telecom operators require for signaling transport.

When the primary path recovers (detected via successful heartbeats), the implementation may switch back. RFC 9260 does not mandate automatic failback -- the behavior is implementation-defined. Some implementations failback immediately; others require manual configuration or leave the new primary in place.

Reliability and Congestion Control

SCTP provides reliable delivery by default. Each DATA chunk is assigned a TSN, and the receiver acknowledges received TSNs via SACK chunks. SCTP's selective acknowledgment is built into the base protocol (unlike TCP, where SACK is an optional extension defined in RFC 2018). The sender maintains a retransmission queue and uses a retransmission timer (RTO) computed from smoothed RTT measurements, similar to TCP's algorithm.

SCTP's congestion control is modeled on TCP's algorithms. It uses a congestion window (cwnd) per destination address, slow start, congestion avoidance, and fast retransmit/fast recovery. The per-destination cwnd is important for multi-homing: each path has its own congestion state, so a congested primary path does not constrain throughput on an alternate path used after failover.

Partial Reliability: PR-SCTP (RFC 3758)

The PR-SCTP extension allows an SCTP sender to abandon retransmission of a DATA chunk after a policy-defined threshold. Policies include timed reliability (abandon after N milliseconds), limited retransmission count, and priority-based. When the sender abandons a chunk, it sends a FORWARD-TSN chunk telling the receiver to advance its cumulative TSN acknowledgment point past the abandoned data.

This is useful for real-time applications where stale data is worthless. For example, in a video conferencing scenario, retransmitting a video frame that is already two frames behind is pointless -- the receiver should skip it and process the current frame. PR-SCTP provides reliable delivery by default with the option to relax it per-message, a flexibility that neither TCP (always reliable) nor UDP (never reliable) offers.

SCTP vs TCP vs UDP

The three transport protocols occupy different points in the design space:

A crucial distinction: SCTP uses its own IP protocol number (132), meaning it is not encapsulated in TCP or UDP. This is both a strength (it is a first-class citizen of the IP protocol suite, as fundamental as TCP or UDP at the network layer) and a weakness (many NAT devices, firewalls, and middleboxes on the public internet do not understand protocol 132 and will drop SCTP packets). This middlebox traversal problem is the primary reason SCTP never gained traction for general internet traffic.

SCTP in Telecom: Where It Dominates

Despite its limited adoption on the public internet, SCTP is ubiquitous inside telecom networks. In these controlled environments, middlebox traversal is not a problem -- operators configure their routers and firewalls to pass protocol 132, and NAT is generally not used on internal signaling links.

SIGTRAN: SS7 over IP

SCTP was originally created for SIGTRAN (Signaling Transport), the IETF framework for carrying SS7 signaling over IP networks. The SIGTRAN adaptation layers -- M2UA (RFC 3331), M3UA (RFC 4666), M2PA (RFC 4165), and SUA (RFC 3868) -- all use SCTP as their transport. M3UA, the most widely deployed, carries MTP3-level signaling (ISUP for call setup, MAP for mobility management, CAP for prepaid charging) between Signaling Gateways and Application Servers.

SCTP's multi-homing maps perfectly to the SS7 reliability model. Traditional SS7 signaling links ran over dedicated hardware with automatic switchover. SCTP associations with multi-homed endpoints replicate this availability model over IP infrastructure, providing the carrier-grade reliability that telecom operators demand.

Diameter

Diameter (RFC 6733), the AAA protocol that replaced RADIUS in LTE and 5G networks, specifies SCTP as its mandatory transport (TCP is also permitted). Diameter carries authentication, authorization, and accounting messages between network elements. For example, when your phone attaches to a 4G network, Diameter messages flow between the MME (Mobility Management Entity) and the HSS (Home Subscriber Server) to authenticate your SIM card and authorize network access.

SCTP's multi-streaming is valuable here because Diameter multiplexes many independent sessions (one per subscriber operation) over a single transport connection. With TCP, a lost packet delays all sessions. With SCTP, each session can be mapped to a separate stream, isolating the impact of loss.

S1AP and NGAP: 4G/5G Control Plane

The most critical use of SCTP in modern telecom is for control-plane signaling between base stations and the core network:

• S1AP (S1 Application Protocol) -- In 4G LTE, S1AP runs over SCTP between the eNodeB (base station) and the MME (Mobility Management Entity). It handles procedures like initial attach, handover, paging, and bearer setup. Every SCTP association between an eNodeB and an MME typically uses multiple streams, with each stream carrying signaling for different UE (User Equipment) contexts. If a packet for one UE's handover is lost, other UEs' signaling is unaffected.
• NGAP (Next Generation Application Protocol) -- In 5G NR, NGAP replaces S1AP. It runs over SCTP between the gNB (5G base station) and the AMF (Access and Mobility Management Function). The design philosophy is the same: SCTP provides the multi-streaming and multi-homing that control-plane signaling requires. 3GPP TS 38.412 specifies NGAP over SCTP as mandatory.
• X2AP / Xn AP -- Inter-base-station signaling for handover in 4G (X2AP between eNodeBs) and 5G (XnAP between gNBs) also uses SCTP. When your phone moves between cells, SCTP associations carry the handover request, resource allocation, and context transfer messages.

The multi-homing capability is critical in these deployments. A base station typically has two network paths to the core (via different routers or switches for redundancy). If one path fails -- due to a fiber cut, router failure, or maintenance window -- the SCTP association fails over to the alternate path without dropping any active calls or requiring UEs to re-attach. This is not a theoretical benefit: it is a hard requirement in the 3GPP specifications.

SCTP over UDP (RFC 6951)

The middlebox traversal problem -- NATs and firewalls dropping IP protocol 132 -- limits SCTP's use to controlled network environments. RFC 6951 (2013) defines SCTP over UDP as a solution: encapsulate SCTP packets inside UDP datagrams, using a well-known UDP port (typically 9899). This allows SCTP to traverse NATs and firewalls that pass UDP traffic.

The encapsulation is straightforward: a standard UDP header (source port, destination port, length, checksum) wraps the entire SCTP packet (common header + chunks). The SCTP checksum (CRC32c) is still computed over the SCTP packet, and the UDP checksum may be zero (for IPv4) or must be computed (for IPv6).

SCTP-over-UDP preserves all SCTP features -- multi-streaming, multi-homing, the four-way handshake -- but introduces complications:

• NAT handling -- NAT devices rewrite UDP source ports, so the SCTP stack must handle the fact that the apparent source port changes. Multi-homing behind NAT is particularly tricky, since different paths may be NATted to different source ports or even different source addresses.
• Path MTU -- The UDP header adds 8 bytes of overhead, reducing the effective MTU for SCTP data. The SCTP stack must account for this in its PMTU discovery.
• Performance -- The additional encapsulation and checksum computation add small but measurable overhead.

In practice, SCTP-over-UDP is used primarily by WebRTC's data channels. The WebRTC protocol stack uses SCTP (encapsulated in DTLS over UDP via ICE) to provide reliable, ordered, or unordered data channels between browsers. This is one of the few places where SCTP technology reaches end users, albeit hidden under several layers of encapsulation.

DTLS over SCTP (RFC 6083)

RFC 6083 defines how to use DTLS (Datagram Transport Layer Security) to secure SCTP associations. Unlike TLS, which requires a reliable, ordered transport (TCP), DTLS is designed for datagram protocols and can handle the message-oriented, potentially unordered delivery that SCTP provides.

DTLS over SCTP encrypts and authenticates each SCTP chunk payload, providing confidentiality, integrity, and replay protection. The DTLS record layer runs on top of SCTP, using SCTP's reliable delivery for the DTLS handshake and then protecting DATA chunk payloads.

The primary use case is securing signaling in telecom networks. While many internal signaling links rely on network-level security (IPsec or physical isolation), DTLS over SCTP provides application-layer security when signaling crosses trust boundaries -- for example, between operators in a roaming scenario, or between a network element and a third-party application server. 3GPP specifications reference DTLS over SCTP as a security option for interfaces like S1AP and NGAP.

SCTP and the Broader Protocol Landscape

SCTP occupies a unique position in the transport protocol ecosystem. It is technically superior to TCP for many use cases -- its multi-streaming eliminates head-of-line blocking, its multi-homing provides seamless failover, its message-oriented delivery preserves application message boundaries, and its four-way handshake provides built-in flood protection. Yet it never achieved widespread adoption on the public internet.

The reason is not technical but practical. TCP was already universal when SCTP was standardized in 2000. Every operating system, every firewall, every NAT device, every load balancer, every middlebox understood TCP. SCTP, with its novel IP protocol number 132, required explicit support everywhere. Middleboxes that had never seen protocol 132 simply dropped the packets. Network operators had no incentive to update their equipment to support a protocol that no one was using, and no one would use a protocol that network equipment did not support. This chicken-and-egg problem proved insurmountable for general internet adoption.

QUIC learned from SCTP's deployment failure. Rather than using a new IP protocol number, QUIC runs on top of UDP -- which already traverses every middlebox on the internet. QUIC adopted SCTP's multi-streaming concept (independent streams within a single connection) while adding integrated encryption and connection migration. In a sense, QUIC is what SCTP might have become if it had been designed for the middlebox-laden internet of the 2010s rather than the idealized IP network model of the 1990s.

Within telecom, SCTP remains uncontested. No protocol has emerged to replace it for signaling transport, and the 3GPP specifications for 5G (and likely future 6G) continue to mandate SCTP for control-plane interfaces. The protocol's design choices -- born from the specific requirements of telecom signaling -- remain perfectly suited to that domain. SCTP is a protocol that found its niche and dominates it absolutely.

Explore the Network

SCTP associations carry the signaling that controls how mobile devices attach to base stations, how calls are routed, and how handovers are executed. The paths those signaling messages take -- between cell towers and core network elements -- ultimately traverse the same IP infrastructure that BGP routes. Use the god.ad BGP Looking Glass to examine the networks that major telecom operators use to interconnect their infrastructure.

• AS7018 -- AT&T's network, one of the largest mobile operators in the US
• AS20057 -- AT&T Mobility's dedicated wireless AS
• AS21928 -- T-Mobile's network, built on Sprint's spectrum assets
• AS6167 -- Verizon Business, backbone for Verizon's mobile core
• AS3320 -- Deutsche Telekom, Europe's largest telecom operator