RFC 3286

An Introduction to the Stream Control Transmission Protocol (SCTP) 🎀

okay bestie, let's get into it 💖 this is RFC 3286, titled An Introduction to the Stream Control Transmission Protocol (SCTP). It's an Informational doc from the Network Working Group in May 2002, written by L. Ong (Ciena Corporation) and J. Yoakum (Nortel Networks). It doesn't list anything it obsoletes or updates, so it's just a friendly intro, no drama 🦋

Status of this Memo

This memo gives information to the Internet community 🌸 It doesn't specify an Internet standard of any kind, and distribution of this memo is unlimited 💅

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved. 📜

Abstract

This doc is a high level intro to what the Stream Control Transmission Protocol (SCTP) can do ✨ It's meant as a guide for anyone who's thinking about using SCTP as a general purpose transport protocol 🧚

1. Introduction 💜

okay so SCTP is a brand new IP transport protocol 🔥 It sits at the same level as UDP (User Datagram Protocol) and TCP (Transmission Control Protocol), which means it provides transport layer functions for lots of Internet apps. The IETF approved it as a Proposed Standard [1], and the error check algorithm has since been modified [2]. Any future changes and updates will show up in the IETF RFC index, so keep an eye on that 👀

Like TCP, SCTP is giving reliability 🫶 It makes sure data gets transported across the network without errors and in sequence. Like TCP, it's also session-oriented, which means the two endpoints of an SCTP association create a relationship before any data gets sent. That relationship stays up until all the data transmission is successfully finished. Very committed energy 💅

Now the unlike-TCP part is where it gets iconic ✨ SCTP has a bunch of features that are critical for telephony signaling transport, and it can also seriously benefit other apps that need extra performance and reliability. The original framework for SCTP is described in [3] 🌈

2. Basic SCTP Features 🍓

SCTP is a unicast protocol, so it supports data exchange between exactly 2 endpoints. Those endpoints can each be represented by multiple IP addresses though, which is a whole vibe 🦋

It also provides reliable transmission. It detects when data gets discarded, reordered, duplicated or corrupted, and it retransmits damaged data as necessary 🔁 SCTP transmission is full duplex, so data can flow both ways at once 💖

SCTP is message oriented, so it supports framing of individual message boundaries 💌 TCP, on the other hand, is byte oriented, and it doesn't preserve any implicit structure in a byte stream unless you add enhancements. Not me being shady about TCP, just facts 🙈

Lastly, SCTP is rate adaptive, kind of like TCP. It scales back data transfer to match the load conditions in the network ⭐ It's also designed to play nicely with TCP sessions that are trying to use the same bandwidth. Cooperative queen behavior 👑

3. SCTP Multi-Streaming Feature 🌊

The name Stream Control Transmission Protocol actually comes from SCTP's multi-streaming function 🎀 This feature lets data get split into multiple streams that each have independently sequenced delivery. So if a message gets lost in one stream, it only initially affects delivery within that stream, and the other streams are unbothered ✨

TCP is different. It assumes a single stream of data and makes sure delivery happens with byte sequence preservation. That's great for delivering a file or a record, but it causes extra delay when message loss or a sequence error happens inside the network. When that happens, TCP has to hold off on delivering data until the correct sequencing is restored, either by receiving an out-of-sequence message or by retransmitting a lost message 😭

For plenty of apps, strict sequence preservation isn't truly necessary 🙌 In telephony signaling, you only need to keep messages in sequence if they affect the same resource (like the same call or the same channel). Other messages are only loosely correlated and can be delivered without keeping overall sequence integrity. Efficient, no cap 💅

Multi-streaming is also useful for something like a web page delivered over a single session 🌐 Multimedia documents are made of objects of different sizes and types, so multi-streaming lets those components be partially ordered instead of strictly ordered. That can lead to a better user experience when the content transports 💖

At the same time, all of the transport happens within a single SCTP association. That means every stream gets subjected to one common flow and congestion control mechanism, which cuts down on the overhead needed at the transport level. Shared resources, shared vibes 🫶

Here's the actual magic 🪄 SCTP does multi-streaming by making data transmission and data delivery independent of each other. Each payload DATA "chunk" in the protocol uses two sets of sequence numbers. The first is the Transmission Sequence Number, which governs how messages get transmitted and how message loss is detected. The second is the Stream ID/Stream Sequence Number pair, which decides the order that received data gets delivered in ✨

Because these two mechanisms are independent, the receiver can immediately tell when a gap shows up in the transmission sequence (say, from message loss). It can also tell whether messages that arrive after the gap belong to an affected stream. If a message arrives in the affected stream, there will be a matching gap in the Stream Sequence Number. Messages from other streams won't show a gap at all 👀 So the receiver can keep delivering messages to the unaffected streams while it buffers messages in the affected stream until retransmission happens. Multitasking queen 👑

4. SCTP Multi-Homing Feature 🏠

Another core feature of SCTP is multi-homing, which is when a single SCTP endpoint supports multiple IP addresses 🗝️ The big benefit is that the session can potentially survive network failures much better. In a conventional single-homed session, a failure in the local LAN access can cut off the end system completely. Failures inside the core network can make transport temporarily unavailable until the IP routing protocols reconverge around the point of failure 😩

With multi-homed SCTP, you can use redundant LANs to reinforce the local access 💪 Meanwhile, there are various options in the core network for reducing how much different addresses depend on the same failures. Using addresses with different prefixes can force routing to go through different carriers. Route-pinning techniques, or even redundant core networks, can also be used if there's control over the network architecture and protocols. Strategic planning, bestie 🧠

Now, SCTP currently does not do load sharing 🚫 Multi-homing is used for redundancy purposes only. One address gets chosen as the "primary" address, and it's the destination for all DATA chunks during normal transmission. Retransmitted DATA chunks use the alternate address(es) to improve the odds of reaching the remote endpoint. If continued failure to send to the primary address happens, the endpoint decides to send all DATA chunks to the alternate instead, until heartbeats can re-establish the reachability of the primary 🔄

To support multi-homing, SCTP endpoints exchange lists of addresses during initiation of the association 📇 Each endpoint must be able to receive messages from any of the addresses associated with the remote endpoint. In practice, some operating systems may use available source addresses in round robin fashion, so getting messages from different source addresses will be the normal case 🎠 A single port number gets used across the entire address list at an endpoint for a specific session. One port, many addresses, very efficient 💅

Security is a whole thing here 🔒 In order to reduce the potential for security issues, some response messages are required to be sent specifically to the source address in the message that caused the response. For example, when the server gets an INIT chunk from a client to start an SCTP association, the server always sends the response INIT ACK chunk to the source address that was in the IP header of the INIT. Locked in and secure 🫡

5. Features of the SCTP Initiation Procedure 🤝

The SCTP Initiation Procedure relies on a 4-message sequence 🔢 DATA can be included on the 3rd and 4th messages of the sequence, since those messages get sent after the association has already been validated. A "cookie" mechanism was added to the sequence to guard against some types of denial of service attacks 🛡️

5.1 Cookie Mechanism 🍪

The "cookie" mechanism specifically guards against a blind attacker. That's someone generating INIT chunks to try to overload an SCTP server, making it burn through memory and resources handling new INIT requests. Instead of allocating memory for a Transmission Control Block (TCB), the server creates a Cookie parameter. The Cookie holds the TCB information, a valid lifetime, and a signature for authentication. The server then sends this back in the INIT ACK 🎁

Since the INIT ACK always goes back to the source address of the INIT, the blind attacker never gets the Cookie. A valid SCTP client does get the Cookie, and it returns it in the COOKIE ECHO chunk. Then the SCTP server can validate the Cookie and use it to rebuild the TCB 🔐 Since the server creates the Cookie, only the server needs to know its format and secret key, so none of that gets exchanged with the client. Secrets stay secret 🤫

Otherwise, the SCTP Initiation Procedure follows a lot of TCP conventions 🤓 The endpoints exchange receiver windows, initial sequence numbers, and so on. On top of that, the endpoints may exchange address lists (as discussed above), and they also mutually confirm the number of streams to be opened on each side 🌈

5.2 INIT Collision Resolution 💥

Multi-homing adds to the chance that messages get received out of sequence or with different address pairs 🌀 This is a particular concern during initiation of the association. Without procedures for resolving colliding messages, you could easily end up with multiple parallel associations between the same endpoints, which is chaotic 😵‍💫 So SCTP includes a number of procedures to resolve parallel initiation attempts into a single association. One association, no drama 💖

6. SCTP DATA Exchange Features ✨

okay so DATA chunk exchange in SCTP is giving TCP's Selective ACK vibes 🦋 Receiving DATA chunks gets acknowledged by sending SACK chunks. Those SACKs tell you not just the cumulative Transmission Sequence Number (TSN) range that arrived, but also any non-cumulative TSNs, which means there are gaps in the TSN sequence 🫶 Following TCP procedures, SACKs go out using the "delayed ack" method, normally one SACK per every other received packet. There's an upper limit on the delay between SACKs, though, and it bumps up to once per received packet when gaps are detected 💅

Flow and Congestion Control follow TCP algorithms, bestie 🌸 The advertised receive window shows buffer occupancy at the receiver, while a per-path congestion window keeps track of the packets in flight. Slow start, Congestion avoidance, Fast recovery and Fast retransmit are all baked in as described in RFC 2581, with one twist: endpoints must manage the conversion between bytes sent and received and TSNs sent and received, since TSN is per chunk rather than per byte 🧚

The application can set a lifetime for its data 💀 So if the lifetime has expired and the data hasn't been transmitted yet, it can be discarded (think time-sensitive signaling messages). If the data has already been transmitted, it must continue to be delivered so you don't create a hole in the TSN sequence. not me making holes 😭

---

7. SCTP Shutdown Features

SCTP Shutdown uses a 3-message procedure to allow graceful shutdown 🌈 Each endpoint gets confirmation of the DATA chunks the remote endpoint received before the shutdown is complete, which is so iconic. There's also an Abort procedure for error cases where an immediate shutdown has to happen 🔥

Note that SCTP does not support the function of a "half-open" connection the way TCP can, where one side says it has no more data to send but the other side can keep sending data forever 🙈 SCTP assumes that once the shutdown procedure begins, both sides will stop sending new data across the association, and they only need to clear up acknowledgements of data sent earlier. clean exit era 👑

---

8. SCTP Message Format

The SCTP Message includes a common header plus one or more chunks, and those chunks can be control or data 🎀 The common header has source and destination port numbers so different SCTP associations at the same address can be multiplexed. It also has a 32-bit verification tag that guards against insertion of an out-of-date or false message into the SCTP association, plus a 32-bit checksum for error detection (this has been modified to use the CRC-32c polynomial [2]) 🔐

Each chunk includes a chunk type, a flag field, a length and a value 🍓 Control chunks bring different flags and parameters depending on the chunk type. DATA chunks are the main characters here, since they bring flags for controlling segmentation and reassembly, plus parameters for the TSN, Stream ID and Stream Sequence Number, and a Payload Protocol Identifier ✨

The Payload Protocol ID was included for future flexibility 🦋 The idea is that protocol identification and port number multiplexing won't be as tightly linked in the future as they are in current usage. Payload Protocol ID will let the protocol being carried by SCTP be identified independently of the port numbers being used. it's giving separation of concerns 💅

The SCTP message format naturally supports bundling multiple DATA and control chunks in a single message, which boosts transport efficiency 🚀 Bundling is controllable by the application, so bundling of initial transmission can be prohibited. Bundling will naturally happen on retransmission of DATA chunks too, which further reduces any chance of congestion 🫶

---

9. Error Handling

9.1 Retransmission

Retransmission of DATA chunks happens from either (a) a timeout of the retransmission timer, or (b) receipt of SACKs indicating the DATA chunk hasn't been received 😭 To reduce the potential for congestion, the rate of retransmission of DATA chunks is limited. The retransmission timeout (RTO) is adjusted based on estimates of the round trip delay, and it backs off exponentially as message loss increases 📉

In an active association with fairly constant DATA transmission, SACKs are more likely to cause retransmission than the timeout does 👀 To reduce the chance of an unnecessary retransmission, a 4 SACK rule is used, so retransmission only happens on receipt of the 4th SACK that indicates the chunk is missing. This is meant to avoid retransmits from totally normal stuff like packets arriving out of sequence 🌸

9.2 Path Failure

A count is kept of the number of retransmissions to a particular destination address without a successful acknowledgement 🧮 When this count goes over a configured maximum, the address is declared inactive, the application gets notified, and SCTP starts using an alternate address for sending DATA chunks. rerouting arc unlocked 🦋

Heartbeat chunks are also sent periodically to all idle destinations (aka the alternate addresses) 💓 A counter tracks the number of Heartbeats sent to an inactive destination without receiving a corresponding Heartbeat Ack. When that counter goes over a configured maximum, that destination address is declared inactive too 🙈

Heartbeats keep being sent to inactive destination addresses until an Ack comes back, and at that point the address can be made active again ✨ The rate of sending Heartbeats is tied to the RTO estimation plus an additional delay parameter, so Heartbeat traffic can be tailored to the needs of the user application 🎀

9.3 Endpoint Failure

A count is kept across all destination addresses of the number of retransmits or Heartbeats sent to the remote endpoint without a successful Ack 🧾 When this goes over a configured maximum, the endpoint is declared unreachable and the SCTP association is closed. ngl that's a dramatic exit 💀

---

10. API

The specification includes a model of the primitives exchanged between the application and the SCTP layer 🧚 This is meant as informational material, not a formal API statement, so don't go treating it like one 🫶 A socket-based API is being defined to make it easier to migrate TCP or UDP applications over to SCTP 💅

---

11. Security Considerations

okay this section is serious business, so let's go 🔐 In addition to the verification tag and cookie mechanisms, SCTP specifies the use of IPSec if strong security and integrity protection is required. The SCTP specification does not itself define any new security protocols or procedures. so if you need that level of protection, you reach for IPSec 🛡️

Extensions to IPSec are under discussion to reduce the overhead required to support multi-homing 🌐 Also, work is in progress on the use of Transport Layer Security (TLS) over SCTP [4]. stay tuned, this plot is still developing 👀

---

12. Extensions

The SCTP format allows new chunk types, flags and parameter fields to be defined as extensions to the protocol 🧩 Any extensions must be based on standard agreements within the IETF, because no vendor-specific extensions are supported in the protocol. no going rogue here 🙅‍♀️

Chunk Type values are organized into four ranges, so extensions can be made with a pre-defined procedure for responding when a new Chunk Type isn't recognized at the remote endpoint 🎀 The responses are: whole packet discard; packet discard with reporting; ignoring the chunk; or ignoring with reporting. Similar pre-defined responses are specified for unrecognized Parameter Type values 🌸

Chunk Parameter Type values are, in principle, independent ranges for each Chunk Type 🧠 In practice though, the values defined in the SCTP specification have been coordinated so that a particular parameter type has the same Chunk Parameter Type value across all Chunk Types. Further experience will determine whether this alignment needs to be maintained or formalized 👀

---

13. Informative References

[1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H.,
    Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
    "Stream Control Transmission Protocol", RFC 2960, October 2000.

[2] Stewart, Sharp, et. al., "SCTP Checksum Change", Work in
    Progress.

[3] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
    Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework
    Architecture for Signaling Transport", RFC 2719, October 1999.

[4] Jungmeier, Rescorla and Tuexen, "TLS Over SCTP", Work in
    Progress.

---

14. Authors' Addresses

Lyndon Ong
Ciena Corporation
10480 Ridgeview Drive
Cupertino, CA 95014

EMail: lyong@ciena.com


John Yoakum
Emerging Opportunities
Nortel Networks

EMail: yoakum@nortelnetworks.com

---

15. Full Copyright Statement

Copyright (C) The Internet Society (2002). 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. forever and ever, periodt 💜

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. 🙏

Acknowledgement ✨

Funding for the RFC Editor function is currently provided by the Internet Society 💖