SCTP packet structure

The Stream Control Transmission Protocol has a simpler basic packet structure than TCP. Each consists of two basic sections:

The common header, which occupies the first 12 bytes. In the adjacent diagram, this header is highlighted in blue.
The data chunks, which form the remaining portion of the packet. In the diagram, the first chunk is highlighted in green and the last of N chunks is highlighted in red. There are several types, including payload data and different control messages.

Common header

All SCTP packets require the common header section.
; Source port : This field identifies the sending port.
; Destination port : This field identifies the receiving port that hosts use to route the packet to the appropriate endpoint/application.
; Verification tag : A 32-bit random value created during initialization to distinguish stale packets from a previous connection.
; Checksum : SCTP's original design catered for Adler-32; but RFC 3309 changed the protocol to use the CRC32c algorithm.

Chunks

Each SCTP packet consists, in addition to the common header, of chunks.
Each chunk has a common format, but the contents can vary.
The green bytes in the diagram above signify one chunk.
; Chunk type : An 8-bit value predefined by the IETF to identify the contents of the chunk value field.
; Chunk flags : Eight flag-bits whose definition varies with the chunk type. The default value is zero.
; Chunk length : A 16-bit unsigned value specifying the total length of the chunk in bytes that includes chunk type, flags, length, and value fields.
; Chunk data : General-purpose data field whose definition varies with the chunk type.
If the chunk length does not equate to a multiple of 4 bytes, then the protocol implicitly pads the chunk with trailing zeros.
Additionally, each chunk type may define a set of parameters which it includes inside the chunk value field.
Two types of parameter exist:

fixed parameters — they must appear and in the order specified,
variable-length or optional parameters — they appear after the fixed parameters and may appear in any order and in any number.

For optional/variable-length parameters, the parameter type, parameter length, and parameter value fields all behave just like their chunk counterparts.
The minimum size of parameter is 4 bytes, and this occurs when the parameter value field is empty and the parameter consists only of the type and length fields.

List of chunk types

RFC 2960 defines the following list of chunk types. More detailed information about each type is provided in the following subsections.
Following this table each chunk and its parameters are defined. Please note the following color scheme:

gray: chunk fields,
red: fixed parameters,
green/blue: optional/variable-length parameters that alternate colors.

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
13	CWR	Congestion window reduced
14	SHUTDOWN COMPLETE	Shutdown complete
15	AUTH	Authentication chunk
16–62	N/A	Reserved by IETF
63	N/A	IETF-defined chunk extensions
64	I-DATA	Payload data supporting packet interleaving
65–126	N/A	Reserved by IETF
127	N/A	IETF-defined chunk extensions
128	ASCONF-ACK	Address configuration change acknowledgement
129	N/A	Unassigned
130	RE-CONFIG	Stream reconfiguration
131	N/A	Unassigned
132	PAD	Packet padding
133–190	N/A	Reserved by IETF
191	N/A	IETF-defined chunk extensions
192	FORWARD-TSN	Increment expected TSN
193	ASCONF	Address configuration change
194	I-FORWARD-TSN	Increment expected TSN, supporting packet interleaving
195–254	N/A	Reserved by IETF
255	N/A	IETF-defined chunk extensions

INIT ACK chunk

The INIT ACK chunk replicates the INIT chunk except the chunk type is always 2.

COOKIE ECHO chunk

ECNE chunk

Not defined yet.

CWR chunk

Not defined yet.

RE-CONFIG chunk

At most two re-configuration parameters from those mentioned below may appear in this chunk. Not all combinations are valid, see RFC 6525 for details.

Outgoing SSN reset request parameter

This parameter is used by a sender to inform the receiver that it wishes to reset the sequence numbers for its outgoing streams.

Incoming SSN reset request parameter

This parameter is used by a sender to request that the receiver resets the sequence numbers for its outgoing streams.

SSN/TSN reset request parameter

This parameter is used by a sender to inform the receiver that it wishes to reset all TSNs and all SSNs/MIDs for all streams.

Re-configuration response parameter

This parameter is used as a response to a re-configuration request, except possibly for an incoming SSN reset request, which elicits an outgoing SSN reset request parameter if granted.

Add outgoing streams request parameter

This parameter is used by a sender to request that additional outgoing streams be added to the association.

Add incoming streams request parameter

This parameter is used by a sender to request that additional incoming streams be added to the association.

PAD chunk

The PAD chunk was introduced to facilitate path MTU discovery, by enabling a sender to arbitrarily increase the size of an SCTP packet.

I-DATA chunk

The I-DATA chunk was introduced to avoid a large message in one stream blocking messages in all other streams from being transmitted: SCTP primarily uses the TSN to achieve reliability. In some cases, the TSN is also needed to distinguish different DATA chunks.
When a message is fragmented, the DATA TSN additionally doubles as a fragment sequence number. This means that all fragments in a message must be sent using consecutive TSNs, effectively blocking all other data. The I-DATA chunk disentangles the different uses of the TSN in DATA chunks.
As DATA and I-DATA chunks are not compatible, they may not both be used in the same association.

FORWARD-TSN chunk

The FORWARD-TSN chunk was introduced to support selective unreliability: it allows the sender to tell the receiver that it will not retransmit some number of chunks, and requests that the receiver consider all these chunks as received.

I-FORWARD-TSN chunk

The I-FORWARD-TSN chunk was introduced to be used instead of FORWARD-TSN when I-DATA is used instead of DATA.