SCTP: overview and message encoding

Association

Like TCP, SCTP is connection-oriented protocol. The logical connection between two peers is called 'association'. Unlike TCP, an SCTP association can be established between multiple IP addresses on both sides. An example is shown on fig. 1. Host A has got three Ethernet interfaces, with three different IP addresses. Host B has got also three interfaces, but only two are used for the association. The interfaces, part of the association, are shown in light blue. The addresses for each peer are announced during association establishment, which will be a topic for another post. An important notice is that the SCTP port number is the same for all IP addresses on a peer. This feature is called multi-homing.

Stream

Each association has logical unidirectional channels. The exact count is agreed during association establishment and it can be different for each direction. E.g. in fig. 1, from host A to host B there are 7 streams, but from host B to host A - only 3. The purpose of the streams is to provide logical channel for in-order transfer of data/messages. This means that if a message in stream X is lost and needs to be retransmitted, it won't delay the message in stream Y, because they are logically independent. However all other messages in stream X (after the lost one) will be sent after the retransmission and will be delayed. This effect is called head-of-line blocking and is one of the major issues of TCP protocol.

Chunk

Chunk is the easiest one. This is a unit of information within an SCTP packet.

Section 1.5 provides functional overview of the protocol. It describes how streams are used, how in-order delivery is achieved within a stream, how data messages are acknowledged and so on.

Common header

A SCTP packet contains common header and one or more chunks. The common header has the same structure for each SCTP packet. It contains:

• source port number (16 bits)

• destination port number (16 bits)

• verification tag (32 bits)

• checksum (32 bits)

The packet sample on fig. 2 is common header, stripped from an INIT message (INIT chunk is collapsed, for better readability). More details at Section 3.1.

Chunks

A SCTP chunk represents a protocol message, which can be used by the protocol itself (e.g. INIT, which is the first step in association establishment), or can contain user data (DATA chunk). It has three fixed-length parameters and a variable length value. Each chunk is 4 byte aligned. This means that the whole chunk size have to be multiple of 4 bytes. If it is not, zero byte padding is added to achieve the multiple-of-4bytes requirement. The padding shouldn't be more than 3 bytes. 4 byte padding doesn't make sense, because the message is already 4 byte aligned. Each chunk has git the following fields:

• chunk type - 8 bits, can be considered as and indetificator of the SCTP message. E.g. INIT, DATA, HEARTBEAT, etc.

• chunk flags - 8 bits, specific for each chunk type.

• chunk length - 16 bits, the length of the chunk in bytes, including all header fields (type, flags, length) plus the length of the value, excluding the padding.

• chunk value - variable length parameter. Contains various chunk parameters, which depend on the chunk type.

Fig. 3 shows SACK message, which contains common packet header and SACK chunk. The chunk's size is 16 bytes, which means that there is no padding. Chunk structure is described in Section 3.2. All chunk definitions can be found in Section 3.3.

Chunk parameters

The value of each chunk has specific format too. It contains two fixed-sized parameters and variable length value. Each parameter in the chunk must be 4 byte aligned, so the chunk parameter itself may also contain padding. The logic is the same as for the chunk value. Here is the structure of each parameter:

• chunk parameter type - 16 bits, the type of the parameter in the chunk.

• chunk parameter length - 16 bits, the length of the parameter, without the padding.

• chunk parameter value - the actual value for the specified parameter type.

An example

Wireshark makes packet decoding easy, but we will 'decode' one chunk manually, just to see how it's done. The packet from fig. 3 contains a SACK chunk and has got 4 parameters. Let's examine the first one - Cumulative TSN ACK:

1. Open sack.pcapng with Wireshark. We are not interested in Ethernet or IP data - we'll examine only the SCTP. Click on the frame (it is only one) and from the protocol list select Stream Control Transmission Protocol. The SCTP data is marked on the HEX editor at the bottom of the window.

2. The common header has fixed length parameters. We have got 0x115c and 0xc668 as source and destination port numbers (4444 and 50792). Then there are 32 bits for verification tag - 0x88e5e376 and checksum 0x883432df. That's all for the common header. Nothing fancy here, thanks to the fixed length parameters.

3. An SCTP chunk follows. Its header is fixed length, so lets read it. 8 bits chunk type (0x03), 8 bits flags (0x00) and 16 bits length (0x0010). Now we can get the payload. 0x0010 is 16, which means that the chunk contains 16 bytes (not bits, the length is in bytes). Let's convert it to bits (16*8 = 128) and subtract the length of the parameters read up to now. 128 - 8 (type) - 8 (flags) - 16 (length) = 96. This means that the following 96 bits are the chunk data. Check again the packet in the HEX view and you'll see that we have got exactly 96 bits left. This means that the chunk parameter value is 8a 70 48 4a 00 01 9f fa 00 00 00 00.

4. Now we know the chnk type - 0x03. A quick look up in Section 3.2 shows that the chunk is Selective Acknowledgement (SACK). We need to find the chunk definition - it is in Section 3.3.4 . It starts with a description of the message. Right now we are not interested in this, we only want to parse the parameters and their values.

5. After the description in Section 3.3.4, there is a 'bit map' of the whole message and details for each parameter. We start parsing them one by one.

6. Chunk type, flags and length are already parsed. We know that the flags value is 0x00 and the description says that the flags for SACK are always 0. No surprises here.

7. The next one is Cumulative TSN Ack: 32 bits. This means that its value is 0x8a70484a, which is 2322614346. The payload that remains unparsed is 00 01 9f fa 00 00 00 00.

8. The next parameter in the list is Advertised Receiver Window Credit (a_rwnd): 32 bits. Its value is 0x00019ffa, which is 106490. The unparsed part of the payload now is 00 00 00 00.

9. Next one - Number of Gap Ack Blocks: 16 bits (unsigned integer). Its value is 0x0000, which means that there are no 'Gap Ack Blocks' parameters in this chunk. Good news - less work for us. Now we have to parse only 00 00.

10. The next parameter is Number of Duplicate TSNs: 16 bit. Its value is 0x0000. This means that there are no 'Duplicate TSNs' parameters.

11. According to the last two parsed parameters, there are no 'Gap Ack Block Start' and 'Gap Ack Block End', so we are done.

The same approach can be applied for decoding any parameter in Section 3.2. Just follow the field list and pay attention for optional parameters.