SCTP Introduction

When we talked about the Diameter protocol in Diameter Overview, we mentioned that it relies on transport level protocols – TCP or SCTP.

SIP and Diameter stacks

I guess most of people are familiar with TCP. But not everyone is familiar with SCTP protocol yet. And that’s a pity because the Stream Control Transmission Protocol (SCTP) was designed especially for telcos as TCP is burdened with some limitations. Let’s explore SCTP’s basic featurers today. Btw. we should remind that SCTP is a must also in legacy networks, because SCTP is a part of Sigtran stack (SS7 over IP).

SIP and Diameter in Wireshark

And last but not least SCTP can also transport the SIP protocol (RFC 4168). It is not that common, but there are some operators benefiting from this option e.g. in case of  NNI.

 

What is SCTP?

SCTP is defined in RFC 4960. Moreover there is RFC 3286, which is not a typical spec, but An Introduction to the SCTP.

We said that SCTP is a transport level protocol. Like TCP, it provides a reliable transport service. It makes sure that data is transported across the network without error and in sequence. SCTP is rate-adaptive and provides congestion control, too. Unlike TCP, which is byte oriented and does not preserve any implicit structure within a transmitted byte stream, SCTP is message oriented (as UPD) and supports framing of individual message boundaries.

The protocol is full-duplex and session-oriented. A relationship between exactly two endpoints of an association is established before data is transmitted. This relationship is maintained until all data transmission has been successfully completed.

SCTP Session

Besides SCTP provides plenty of functions which are critical for signaling transport, and its need of additional performance and reliability. The most important features are SCTP Multi-Streaming and SCTP Multi-homing.

SCTP packets have a very simple structure. Each consists of two basic sections – the common header, and the data chunks.

SCTP Header – simplified

The important values from the SCTP flow point of view are the chunk types:

Value	Abbreviation	Description
0	DATA	Payload data
1	INIT	Initiation
2	INIT ACK	Initiation acknowledgement
3	SACK	Selective acknowledgement
4	HEARTBEAT	Heartbeat request
5	HEARTBEAT ACK	Heartbeat acknowledgement
6	ABORT	Abort
7	SHUTDOWN	Shutdown
8	SHUTDOWN ACK	Shutdown acknowledgement
9	ERROR	Operation error
10	COOKIE ECHO	State cookie
11	COOKIE ACK	Cookie acknowledgement
12	ECNE	Explicit congestion notification echo (reserved)
13	CWR	Congestion window reduced (reserved)
14	SHUTDOWN COMPLETE	Shutdown complete
15-62	N/A	Reserved by IETF
63		IETF-defined chunk extensions
64-126		Reserved by IETF
127		IETF-defined chunk extensions
128-190		Reserved by IETF
191		IETF-defined chunk extensions
192-254		Reserved by IETF
255		IETF-defined chunk extensions

SCTP Session

Initialization

In order to establish an SCTP session we have to perform a 4-way handshake. We use so-called “cookie” mechanism in order to guard the session against some types of denial of service attacks (as SYN flood in case of TCP). How does it work?

SCTP 4-way handshake

In the first INIT message the SCTP endpoint A sends a random number in Initiate Tag field.

The other SCTP endpoint Z immediately responds with an INIT ACK chunk. In the response, besides other parameters, the Verification Tag field is set to A’s Initiate Tag value. The endpoint Z sends in return its own tag in the Initiate Tag field. The response also contains a State Cookie. Inside this State Cookie, the SCTP endpoint Z transmits a Transmission Control Block (TCB).

TCB is an internal data structure created for each of existing SCTP associations to other peers. TCB contains all the status and operational information for the endpoint to maintain and manage the association. The RFC 4960 defines what parameters are necessary and recommended for TCB. For simplicity the cookie contains all information important for creation of the session on the Z endpoint, along with a Message Authentication Code (MAC, see RFC2104), a timestamp, and the lifespan of the State Cookie.

Trace – INIT ACK

The important thing is that the endpoint Z doesn’t create any context – TCB for this association yet. It doesn’t allocate any resources, keep state or start any timers. Instead TCB is sent as a cookie to the endpoint A. Thanks to this mechanism the SCTP protocol is less vulnerable to DOS type of attacks.

When the endpoint A receives an INIT ACK chunk with a State Cookie parameter, it immediately sends back a COOKIE ECHO to Z. The message contains the received State Cookie as the value of the COOKIE ECHO chunk.

Once the endpoint Z receives the COOKIE ECHO, it verifies the content and uses the TCB data to create the session. As the confirmation the COOKIE ACK is sent back to the originating peer A.

Each session is identified by an Association Index. From the practical point of view it is good to know that wireshark supports SCTP streams and provides some handy features (Analyze/SCTP).

SCTP in Wireshark

Data

Once the session is established, an endpoint can exchange data. DATA chunk exchange in SCTP is similar to TCP’s Selective ACK procedure. Receipt of DATA chunks is acknowledged by sending SACK chunks. In TCP we acknowledge the number of received bytes. In SCTP we use Transmission Sequence Number (TSN) to acknowledge the number of received chunks. We can have a cumulative TSN indicating the range of chunks received, or also a non-cumulative TSNs, implying gaps in the received TSN sequence.

SCTP data flow

If the SCTP originating endpoint doesn’t receive the ACK with the right TSN, it performs a retransmission. However, it is also possible that the endpoint states that this data is not valid anymore and we can simply skip it (e.g. some multimedia data).

SCTP DATA/SACK – TSN

Heartbeats

By default, an SCTP endpoint monitors the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). The peers respond with HEARTBEAT ACK.

SCTP Heartbeats

Shutdown and Abort

The session can be closed by SCTP Shutdown, which uses a 3-message procedure SHUTDOWN, SHUTDOWN ACK, SHUTDOWN COMPLETE to allow a graceful shutdown. In contrast to TCP, SCTP does not support the function of a “half-open” connection. In TCP when one endpoint indicates that it has no more data to send, the other can still continue to send data (indefinitely). In the SCTP we assume that once the shutdown procedure begins, both parties will stop sending any new data. They just have to clear up acknowledgements of previously sent data messages.

SCTP SHUTDOWN

For an immediate shutdown in case of an error an Abort procedure is available.

SCTP ABORT

SCTP Multi-Streaming

TCP does use only a single stream of data. Within this stream the TCP makes sure that delivery of data takes place with byte sequence preservation. In case of data loss or sequence order error, TCP must delay delivery of data until the correct sequencing is restored. It is done either by receipt of an out-of-sequence message, or by retransmission of the lost message.

TCP stream

The key feature of SCTP is multi-streaming. Hence we have the protocol name – Stream Control Transmission Protocol. Multi-streaming allows data to be partitioned into multiple streams. Each stream is independent on any other, so that a message loss in any of them doesn’t affect delivery delivery in other streams.

SCTP multi-streaming

This is achieved by creating independence between data transmission and data delivery. More specifically, each payload DATA chunk in the protocol uses two sets of sequence numbers, the Transmission Sequence Number (TSN) and a Stream ID/Stream Sequence Number (SN) pair. TSN governs the transmission of messages and the detection of message loss. The Stream ID + SN determine the sequence of delivery of received data.

SCTP multi-streaming – ACKs

SCTP allows the receiver to determine immediately when a gap in the transmission sequence occurs (e.g., due to message loss), and also whether or not messages received following the gap are within an affected stream.

If a message is received within the affected stream, there will be a corresponding gap in the SN, while messages from other streams will not show a gap. The receiver can therefore continue to deliver messages to the unaffected streams while buffering messages in the affected stream until retransmission occurs.

The number of Outbound Streams (OSs) and Maximum Inbound Streams (MISs) is negotiated during the Initialization process. The value of OSs has to respect MISs of the other party, or an error is reported and association is aborted.

SCTP Multi-homing

If we want to have redundant physical connectivity between two nodes, we can either have redundancy on link layer (bonded interfaces, vNICs,..), or we need to have more parallel TCP/UDP sessions. SCTP offers us to have a redundancy on the network layer as a single SCTP endpoint can create an association on multiple IP addresses. This can be beneficial especially when an application does make use of more nodes (blades, VMs).

SCTP Multihoming

SCTP does not do loadsharing, that means we use multihoming for redundancy only. One IP address is configured as primary and it serves as the destination address for all DATA chunks for normal transmission. For retransmittion of DATA chunks the secondary IP addresses are used. A continued failure to send to the primary IP ultimately results in the decision to transmit all DATA chunks to the secondary until heartbeats can reestablish the reachability of the primary destination.

SCTP endpoints are exchanged as lists of addresses during the initiation of the association. Note, that a single SCTP port number is used across the entire address list at an endpoint for a specific session.

SCTP, TCP, UDP Comparison

We can’t say that any of transport level protocols is better than the others. There are good use-cases for SCTP as well for TCP or UDP. Although SCTP is a proffered option for Diameter communication (e.g. Cx, Sh interfaces), TCP can do a good job here too. What protocol is the best depends very much on the network design and also on what people are familiar with.

Services/Features	SCTP	TCP	UDP
Connection-oriented	yes	yes	no
Full duplex	yes	yes	yes
Reliable data transfer	yes	yes	no
Partial-reliable data transfer	optional	no	no
Ordered data delivery	yes	yes	no
Unordered data delivery	yes	no	yes
Flow control	yes	yes	no
Congestion control	yes	yes	no
ECN capable	yes	yes	no
Selective ACKs	yes	optional	no
Preservation of message boundaries	yes	no	yes
Path MTU discovery	yes	yes	no
Application PDU fragmentation	yes	yes	no
Application PDU bundling	yes	yes	no
Multistreaming	yes	no	no
Multihoming	yes	no	no
Protection against SYN flooding attacks	yes	no	n/a
Allows half-closed connections	no	yes	n/a
Reachability check	yes	yes	no
Psuedo-header for checksum	no (uses vtags)	yes	yes
Time wait state	for vtags	for 4-tuple	n/a

 source: isoc

See also:

• Diameter Overview
• VoWifi Overview
• IMS from 10.000 feet
• XCAP Protocol