SCTP (Stream Control Trans­mis­sion Protocol) – the reliable, message-oriented transport protocol

The internet protocol family forms the basis so that systems can com­mu­ni­cate in networks like the internet. There are more than 500 different members who take on mostly different roles, but there are also protocols that have more or less the same function. For example, both TCP (Trans­mis­sion Control Protocol) and UDP (User Datagram Protocol) define how data is exchanged between network par­tic­i­pants. However, while TCP requires an existing con­nec­tion for this, UDP enables the con­nec­tion­less transfer of files. With SCTP (Stream Control Trans­mis­sion Protocol), the IETF (Internet En­gi­neer­ing Task Force) published another protocol in 2000 that combines the prop­er­ties of TCP and UDP.

The Stream Control Trans­mis­sion Protocol, SCTP for short, is a reliable network protocol of the internet protocol family, which was designed by the IETF working group Signaling Transport (SIGTRAN). A first version of the protocol is defined in the RFC 2960 published in 2000 – seven years later the IETF published a revised version in RFC 4960. SCTP is primarily described in these standards as a protocol used to map telephony in­fra­struc­ture in IP networks. In addition, it is also used in other areas, like reliable server pooling (ad­min­is­tra­tion of server pools for load balancing).

SCTP typically uses IP as a base, but can also be based on any other con­nec­tion­less packet service. The transport of packets is char­ac­ter­ized by the following features:

• Confirmed trans­mis­sion of user data (error-free and without du­pli­cates)
• Data frag­men­ta­tion to maintain the maximum packet size of each network path
• Sequenced delivery of user messages within multiple data streams (multi-streaming) – including the option to specify the order of these messages
• Bundling (optional) of several users’ messages in a single SCTP package (chunk bundling)
• Fault tolerance at network level thanks to multi-homing (host with several valid network addresses) of one of both com­mu­ni­ca­tion partner(s)

The Stream Control Trans­mis­sion Protocol therefore focuses on secure and reliable data trans­mis­sion. A strict reg­u­la­tion of the sequence of sent data streams is not necessary, but is possible in principle at any time. In this way, a fixed sequence for the trans­mis­sion of packets with SCTP only has to be adhered to when required by the accessing ap­pli­ca­tion. The sent data, which can be divided into several streams, is not captured byte-by-byte but by packet – which is par­tic­u­lar­ly useful for message-oriented services.

A four-way handshake (mutual au­then­ti­ca­tion including con­nec­tion setup) between sender and receiver ensures the security addressed, without which data transfer via SCTP is not possible. In addition, the header contains a ver­i­fi­ca­tion tag and an op­tion­al­ly unstable checksum field.

To clarify the func­tion­al­i­ty of the data transport through the Stream Control Trans­mis­sion Protocol, we will take a closer look at the most important functions of SCTP – from the four-way handshake, to frag­men­ta­tion, to the trans­mis­sion of the packets.

Es­tab­lished SCTP con­nec­tions can either be closed by the ap­pli­ca­tion or the user as soon as the transfer has ended, or they are pre­ma­ture­ly in­ter­rupt­ed as a result of an error. In addition, it is also possible to terminate the con­nec­tion at any time by request. In any case, the data transfer is com­plete­ly stopped as soon as a par­tic­i­pant dis­con­nects.

The term stream in the SCTP standard refers to a sequence of user data exchanged between server and client. A single SCTP con­nec­tion allows any number of streams, whereby the user can specify the exact number when es­tab­lish­ing the con­nec­tion. While the order of data within a data stream is strictly adhered to, there are no fixed hi­er­ar­chies and no de­pen­den­cies when de­liv­er­ing the different streams. So, if there are problems with the trans­mis­sion of a data stream, this has no effect on the transfer of the other streams. In addition, there is a mechanism by which to bypass the sequences trans­mis­sion and send pri­or­i­tized message packets.

SCTP offers the option of frag­ment­ing packets in order to comply at any time with the path maximum trans­mis­sion unit (PMTU), i.e. the maximum packet size that can be trans­mit­ted over the re­spec­tive con­nec­tion path. At the time of receipt, the in­di­vid­ual fragments are re­assem­bled and forwarded to the user as a complete message. Compared to the network-level frag­men­ta­tion performed by the IP protocol, such frag­men­ta­tion at the transport layer has some ad­van­tages: for example, it relieves the burden on the routers re­spon­si­ble for frag­ment­ing the IP packets. It also elim­i­nates the problem of having to resend entire messages due to a single fragment lost in the network.

The Stream Control Trans­mis­sion Protocol iden­ti­fies all data fragments or un­frag­ment­ed messages with a so-called trans­mis­sion sequence number. For each of these sequence numbers, the sender expects an ac­knowl­edge­ment message from the receiver. If this does not happen within a specified period, the cor­re­spond­ing package will be resent. In order to be able to ensure this trans­mis­sion reliably and in­de­pen­dent­ly of the sequenced trans­mis­sion, the receiver ac­knowl­edges receipt of a trans­mis­sion sequence number even if there are gaps in the trans­mis­sion sequence. To ensure that the trans­mis­sion is not only reliable but also as fast as possible, SCTP uses similar con­ges­tion control al­go­rithms as TCP. These regulate the shipping so that it does not come to a con­ges­tion of the packages and thus an overload of the host.

SCTP allows you to bundle multiple messages in a single package. In this way, several bits of control in­for­ma­tion and/or user data, which are also known as chunks in the SCTP standard, can be sent under a common header. The chunk bundling mechanism is re­spon­si­ble for both as­sem­bling and dis­as­sem­bling the complete package on the receiver side.

When es­tab­lish­ing an SCTP con­nec­tion, the two endpoints negotiate a ver­i­fi­ca­tion tag that must be specified in the packet’s headers sent during the entire trans­mis­sion. If one of the com­mu­ni­ca­tion partners receives a packet without this indicator, it discards the cor­re­spond­ing packet im­me­di­ate­ly. In this way, the protocol provides pro­tec­tion against unau­tho­rized access and also prevents packets from previous con­nec­tions from con­tin­u­ing to be received.

To ad­di­tion­al­ly protect the data, the sender has the option of adding a CRC32C checksum to the header. The protocol provides an optional 32-bit field for this purpose.

Since SCTP supports multi-homing, users can specify a complete set of transport addresses that can be used as potential des­ti­na­tions for the packets sent. If multiple addresses are listed, the protocol uses the primary address path by default. If the primary address path cannot be reached, the al­ter­na­tive addresses are selected so that trans­mis­sion can continue without in­ter­rup­tion. To provide this service, the Streaming Control Trans­mis­sion Protocol has im­ple­ment­ed a path man­age­ment function that uses the specified address in­struc­tions. It also monitors the avail­abil­i­ty of all defined address paths by regularly sending so-called heart­beats (control signals) to them.

There are three important sim­i­lar­i­ties between TCP and SCTP: Both protocols require a con­nec­tion between the com­mu­ni­ca­tion partners, offer a mechanism for overload control, and are also reliable – so they both ensure that the packets arrive at the recipient without a loss. UDP does not provide this kind of guarantee due to a lack of con­fir­ma­tion messages. In return, however, UDP saves the user ap­pli­ca­tion from having to set its own data record markers (to mark packet bound­aries), since it is not byte-oriented but message-oriented – an advantage that SCTP also offers.

Apart from this flex­i­bil­i­ty, which makes SCTP the ideal solution for voice trans­mis­sion services like VoIP (Voice over IP), the protocol also scores points with the support of multi-streaming and multi-homing (fault tolerance instead of al­ter­na­tive hosts), which neither UDP nor TCP offer. In addition, the Stream Control Trans­mis­sion Protocol, with the four-way handshake (including au­then­ti­ca­tion cookie), and the mandatory ver­i­fi­ca­tion tag in the header of each packet sent, ensures the highest security con­ve­nience of all three transport protocols.