SCTP packet structure

The Stream Control Transmission Protocol (SCTP) 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 (Chunk N) is highlighted in red. There are several types, including payload data as well as different control messages.

Bits	Bits 0 - 7	8 - 15	16 - 23
+0	Source port		Destination port
32	Verification tag
64	Checksum
96	Chunk 1 type	Chunk 1 flags	Chunk 1 length
128	Chunk 1 data
…	…
…	Chunk N type	Chunk N flags	Chunk N length
…	Chunk N data

Common header

All SCTP packets require the common header section (shown with a blue background).

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.[1][2]

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 (excludes any padding) 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.

Optional/variable-length parameter definition

+	Bits 0 - 15																16 - 31
0	Parameter type																Parameter length
32	Parameter value

Additionally, each chunk type may define a set of parameters which it includes inside the chunk value field (and, consequently, their length in the chunk length).

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 & 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 (reserved)
13	CWR	Congestion window reduced (reserved)
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[3]
130	RE-CONFIG	Stream reconfiguration
131	N/A	Unassigned[3]
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

DATA chunk

+	Bits 0 - 7	8 - 11	12	13	14	15	16 - 31
0	Chunk type=0	Reserved	I	U	B	E	Chunk length
32	TSN
64	Stream identifier						Stream sequence number
96	Payload protocol identifier
128	Data

Chunk type

always 0 for payload data (DATA).

Chunk flags

There are currently only 4 flags used

I — SACK chunk should be sent back without delay.
U — If set, this indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered chunk is fragmented then each fragment has this flag set.
B — If set, this marks the beginning fragment. An unfragmented chunk has this flag set.
E — If set, this marks the end fragment. An unfragmented chunk has this flag set.

Chunk length: The chunk length has a minimum value of 17 as data of size less than one byte is not allowed.

Fixed parameters:

Transmission sequence number (TSN): The sequence number for the entire DATA stream (used in fragmentation for reassembly).
Stream identifier: Identifier of the stream that this data chunk belongs to
Stream sequence number: Identifier of the sequence number for the message in this stream. If a message is fragmented then this value is maintained for all fragments.
Payload protocol identifier: Application-specific protocol identifier.[4] SCTP makes no use of this or modification of it. However, devices along the path or the endpoints may use it. A value of 0 indicates that no payload protocol is specified.
Data: Application-specific data.

Optional parameters: none.

INIT chunk

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 1	Chunk flags	Chunk length
32	Initiate tag
64	Advertised receiver window credit
96	# of outbound streams		# of inbound streams
128	Initial TSN
160	Parameter type = 5		Parameter length = 8
192	IPv4 address of sending endpoint
224	Parameter type = 6		Parameter length = 20
256	IPv6 address of sending endpoint
288
320
352
384	Parameter type = 9		Parameter length = 8
416	Suggested cookie life-span increment (milliseconds)
448	Parameter type = 11		Parameter length
480	Null-terminated host name
512	Parameter type = 12		Parameter length
544	Address type #1		Address type #2
576	Address type #3		...
608	Parameter type = 32768		Parameter length
640	Explicit congestion notification (reserved)

Chunk type: always 1 for initiation (INIT).
Chunk flags: There are currently no flags used.
Chunk length: This is the chunk length which has a minimum value of 20 when chunk value is empty and no optional parameters are used

Fixed parameters have identical meaning as INIT ACK:

Initiate tag: Unsigned 32-bit number that is used in every SCTP packet in the verification tag within the common header.
Advertised receiver window credit (a_rwnd): Amount of dedicated buffer space for this association that should never be reduced.
# of outbound streams: Number of outbound streams (from the sender of the INIT) it wishes to use for this association. Zero is an invalid value and the receiver should ABORT the association upon receiving a zero.
# of inbound streams: Identical to # of outbound streams but number of inbound streams. No negotiation takes place on the established number but the minimum of requested and offered should be used.
Initial TSN: Initial transmission sequence number to be used and may be any value.

Optional parameters appear with alternating background colors of green and blue:

Parameter type = 5: This parameter lists all the IPv4 addresses used at the sending endpoint. If it is a multihomed connection then the IP address of each may be included.
Parameter type = 6: This parameter lists all the IPv6 addresses used at the sending endpoint. If it is a multihomed connection then the IP address of each may be included.
Parameter type = 9: This parameter provides a suggested life-span increment the receiver should add to its default cookie life-span (in milliseconds).
Parameter type = 11: This parameter is a hostname as defined in RFC 1123, section 2.1. Actual resolution of this name is outside the scope of SCTP. Additionally, a null terminating character must be included and must be included in the parameter length.
Parameter type = 12: This parameter lists the address types the sender supports (e.g., IPv4 = 5, IPv6 = 6, hostname = 11).
Parameter type = 32768: This parameter is reserved for explicit congestion notification support.

INIT ACK chunk

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

Mandatory parameters, only in INIT ACK:

Parameter type = 7 (State Cookie): The state cookie holds the minimal information to recreate the Transmission Control Block, and is signed with the sender's private key. The format of the cookie is not specified.

SACK chunk

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 3	Chunk flags	Chunk length
32	Cumulative TSN ACK
64	Advertised receiver window credit
96	Number of gap ACK blocks = N		Number of duplicate TSNs = X
128	Gap ACK block #1 start		Gap ACK block #1 end
...	...		...
96+N*32	Gap ACK block #N start		Gap ACK block #N end
128+N*32	Duplicate TSN #1
...	...
96+N32+X32	Duplicate TSN #X

Chunk type: Always 3 for selective acknowledgment (SACK).
Chunk flags: There are currently no flags used.
Chunk length: This is the chunk length which has a minimum value of 16 when no gaps or duplicates are sent.

Fixed parameters:

Cumulative TSN ACK: Acknowledges all sequence numbers up to and including this number. Chunks with TSNs above this number have not been received yet – except those included in the optional gap ACK blocks (see below).
Advertised receiver window credit: Amount of dedicated buffer space for this association that should never be reduced.
Number of gap ACK blocks: Indicates the number of gap ACK blocks (i.e. pairs of start and end TSNs) included in this chunk.
Number of duplicate TSNs: Indicates the number of duplicate TSNs reported in this chunk.

Optional parameters appear with alternating background colors of green and blue:

Gap ACK block #n start: Indicates a positive offset (with reference to the cumulative TSN ACK value) to the first TSN of an additional block of TSNs that are acknowledged.
Gap ACK block #n end: Indicates a positive offset (with reference to the cumulative TSN ACK value) to the last TSN of an additional block of TSNs that are acknowledged.
Duplicate TSN #x: A TSN that was received more than once. A TSN will appear in this list for each time it is received after the first time.

HEARTBEAT chunk

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 4	Chunk flags	Chunk length
32	Parameter type = 1		Parameter length
64+	Heartbeat info

Chunk type: For heartbeat (HEARTBEAT), this value is always 4.
Chunk flags: There are currently no flags used.
Chunk length: This is the chunk length which has a minimum value of 8 with no parameter value added.

Fixed parameters: None

Optional parameters are shown with alternating background colors of green and blue:

Parameter type = 1: This parameter contains the sender-specific heartbeat info

HEARTBEAT ACK chunk

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 5	Chunk flags	Chunk length
32	Parameter type = 1		Parameter length
64+	Heartbeat info

Chunk type: For heartbeat acknowledgement (HEARTBEAT ACK), this value is always 5.
Chunk flags: There are currently no flags used.
Chunk length: This is the chunk length which has a minimum value of 8 with no parameter value added.

Fixed parameters: None

Optional parameters are shown with alternating background colors of green and blue:

Parameter type = 1: This parameter contains the sender-specific heartbeat info received in the request.

ABORT chunk

+	Bits 0 - 7								8 - 14							15	16 - 31
0	Chunk type = 6								Reserved							T	Chunk length
32	Zero or more error causes

Chunk type

always 6 for abort (ABORT).

Chunk flags

There is currently only one flag used:

T: Set if the sender sent its own Verification Tag (that receiver should check); not set if the sender sent peer's Verification Tag (which should be checked anyway).

Chunk length

This is the chunk length which has a minimum value of 4 with no error causes given.

Optional parameters (the error causes) are defined in the ERROR chunk.

SHUTDOWN chunk

+	Bits 0 - 7								8 - 15								16 - 31
0	Chunk type = 7								Chunk flags								Chunk length
32	Cumulative TSN ACK

Chunk type: For shutdown (SHUTDOWN), this value is always 7.
Chunk flags: There are currently no flags used.
Chunk length: This is the chunk length which has a fixed length of 8.

Fixed parameters:

Cumulative TSN ACK: Contains the last TSN received in sequence by the sender.

SHUTDOWN ACK chunk

+	Bits 0 - 7								8 - 15								16 - 31
0	Chunk type = 8								Chunk flags								Chunk length = 4

Chunk type: For shutdown acknowledgement (SHUTDOWN ACK), this value is always 8.
Chunk flags: There are currently no flags used.
Chunk length: This is the chunk length which has a fixed length of 4.

ERROR chunk

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 9	Chunk flags	Chunk length
32	Parameter type = 1		Parameter length = 8
64	Stream identifier		Zeros (reserved)
96	Parameter type = 2		Parameter length
128	Number of missing parameters = N
160	Missing parameter type #1		Missing parameter type #2
192	...		Missing parameter type #N
224	Parameter type = 3		Parameter length = 8
256	Measure of staleness (microseconds)
288	Parameter type = 4		Parameter length = 4
320	Parameter type = 5		Parameter length
352	Unresolvable address
384	Parameter type = 6		Parameter length
416	Unrecognized chunk
448	Parameter type = 7		Parameter length = 4
480	Parameter type = 8		Parameter length
512	Unrecognized parameters
544	Parameter type = 9		Parameter length = 8
576	TSN value
608	Parameter type = 10		Parameter length = 4

Chunk type: For error (ERROR), this value is always 9.
Chunk flags: There are currently no flags used.
Chunk length: This is the chunk length which has a minimum value of 8 when only one error is sent with no parameter value. The size is 4 bytes plus the size of all error causes.

Fixed parameters: None.

Optional parameters are shown with alternating background colors of green and blue:

Parameter type = 1: This parameter identifies that the sender received an invalid stream-identifier.
Parameter type = 2: This parameter indicates that the sender received an INIT or INIT ACK chunk with missing mandatory parameters.
Parameter type = 3: This parameter indicates receipt of a valid state cookie but it was stale by a given number of microseconds.
Parameter type = 4: This parameter indicates the sender is out of resources; this usually accompanies an ABORT chunk.
Parameter type = 5: This parameter identifies an address that the sender could not resolve (possibly because it does not support the address type); this usually accompanies an ABORT chunk.
Parameter type = 6: This parameter identifies an unrecognized chunk when the chunk type's most-significant bits are 01 or 11.
Parameter type = 7: This parameter identifies a mandatory parameter in an INIT or INIT ACK chunk has an invalid value.
Parameter type = 8: This parameter is directed to the originator of an INIT ACK chunk that contained an unrecognized parameter.
Parameter type = 9: This parameter indicates a DATA chunk contained no user data; this usually accompanies an ABORT chunk.
Parameter type = 10: This parameter indicates the sender received a COOKIE ECHO while the endpoint was in a SHUTDOWN-ACK-SENT state.

COOKIE ECHO chunk

+	Bits 0 - 7								8 - 15								16 - 31
0	Chunk type = 10								Chunk flags								Chunk length
32+	Cookie

Chunk type: always 10 for cookie echo (COOKIE ECHO).
Chunk flags: There are currently no flags used.
Chunk length: This is the chunk length.
Chunk value: Contains the cookie data.

COOKIE ACK chunk

+	Bits 0 - 7								8 - 15								16 - 31
0	Chunk type = 11								Chunk flags								Chunk length = 4

Chunk type: For cookie acknowledgement (COOKIE ACK), this value is always 11.
Chunk flags: There are currently no flags used.
Chunk length: This is the chunk length and is always 4.

ECNE chunk

Not defined yet.

CWR chunk

Not defined yet.

SHUTDOWN COMPLETE chunk

+	Bits 0 - 7								8 - 14							15	16 - 31
0	Chunk type = 14								Reserved							T	Chunk length = 4

Chunk type

For shutdown complete (SHUTDOWN COMPLETE), this value is always 14.

Chunk flags

There is currently only one flag defined

T: Set if the sender didn't have a TCB; not set if the sender had one (that it destroyed).

Chunk length

This is the chunk length which has a fixed length of 4.

AUTH chunk

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 15	Flags = 0	Chunk length
32	Shared key identifier		HMAC identifier
64	HMAC
...	HMAC

Chunk type: For the authentication chunk (AUTH), this value is always 15.
Chunk flags: There are currently no flags used.
Chunk length: Length of the HMAC + 8.

Fixed parameters:

Shared key identifier: identifies the shared key that was used.
HMAC identifier: identifies the type of HMAC used.[5]
HMAC: HMAC value. Might not be a multiple of 4 bytes. The SCTP protocol takes care of padding to a 4-byte boundary.[6]

Optional parameters: none

ASCONF-ACK chunk

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 128	Chunk flags	Chunk length
32	Sequence number
64	ASCONF parameter response 1
...	...
...	ASCONF parameter response N

Chunk type: always 128 for the address reconfiguration acknowledgement chunk (ASCONF-ACK).
Chunk flags: There are currently no flags used.
Chunk length: Depends on the number and length of ASCONF parameter responses included.

Fixed parameters:

Sequence number: The sequence number of the ASCONF packet being acknowledged.

Optional parameters:

ASCONF parameter response 1..N: Address reconfiguration parameter responses (variable length).

RE-CONFIG chunk

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 130	Chunk flags	Chunk length
32	Re-configuration parameter 1
...	Re-configuration parameter 1
...	Re-configuration parameter 2
...	Re-configuration parameter 2

Chunk type: always 130 for the stream reconfiguration chunk (RE-CONFIG).
Chunk flags: There are currently no flags used.
Chunk length: Depends on the number and length of re-configuration parameters.

Fixed parameters:

Re-configuration parameter 1: First stream reconfiguration parameter.

Optional parameters:

Re-configuration parameter 2: Second stream reconfiguration parameter.

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 (or message-ids if I-DATA is used) for its outgoing streams.

+	Bits 0 - 15	16 - 31
0	Parameter type = 13	Parameter length
32	Re-configuration request sequence number
64	Re-configuration response sequence number
96	Senders last assigned TSN
128	Stream number 1	Stream number 2
...	...
96 + 16*N	Stream number N-1	Stream number N

Parameter type: always 13 for the outgoing SSN reset request parameter.
Parameter length: 16 + 2*N.

Fixed parameters:

Re-configuration request sequence number: Sequence number of this re-configuration request.
Re-configuration response sequence number: Sequence number of the last re-configuration request received.
Sender's last assigned TSN: Last TSN assigned by the sender (strictly speaking: one less than the next TSN to be assigned).

Optional parameters:

Stream number 1..N: Stream numbers for which the SSN or MID must be reset. If none specified, all SSNs/MIDs will be reset.

Incoming SSN reset request parameter

This parameter is used by a sender to request that the receiver resets the sequence numbers (or message-ids if I-DATA is used) for its outgoing streams.

+	Bits 0 - 15	16 - 31
0	Parameter type = 14	Parameter length
32	Re-configuration request sequence number
64	Stream number 1	Stream number 2
...	...
32 + 16*N	Stream number N-1	Stream number N

Parameter type: always 14 for the incoming SSN reset request parameter.
Parameter length: 8 + 2*N.

Fixed parameters:

Re-configuration request sequence number: Sequence number of this re-configuration request.

Optional parameters:

Stream number 1..N: Stream numbers for which the SSN or MID must be reset. If none specified, all SSNs/MIDs will be reset.

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.

+	Bits 0 - 15																16 - 31
0	Parameter type = 15																Parameter length = 8
32	Re-configuration request sequence number

Parameter type: always 15 for the SSN/TSN reset request parameter
Parameter length: 8

Fixed parameters:

Re-configuration request sequence number: Sequence number of this re-configuration request.

Optional parameters: none

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.

+	Bits 0 - 15	16 - 31
0	Parameter type = 16	Parameter length
32	Re-configuration response sequence number
64	Result
96	Sender's next TSN
128	Receiver's next TSN

Parameter type: always 16 for the re-configuration response parameter
Parameter length: 12 or 20

Fixed parameters:

Re-configuration response sequence number: Sequence number of the corresponding re-configuration request.
Result: Result code

Result code	Description	Result code	Description
0	Success - Nothing to do	4	Error - Request already in progress
1	Success - Performed	5	Error - Bad Sequence Number
2	Denied	6	In progress
3	Error - Wrong SSN

Optional parameters: (either both or none must be present)

Sender's next TSN: Next TSN that the sender of the response will use. Only in response to SSN/TSN reset request.
Receiver's next TSN: Next TSN that the receiver of the response must use. Only in response to SSN/TSN reset request.

Add outgoing streams request parameter

This parameter is used by a sender to request that additional outgoing streams be added to the association (i.e. incoming streams for the receiver).

+	Bits 0 - 15	16 - 31
0	Parameter type = 17	Parameter length = 12
32	Re-configuration request sequence number
64	Number of new streams	Reserved

Parameter type: always 17 for the add outgoing streams request parameter
Parameter length: 12

Fixed parameters:

Re-configuration request sequence number: Sequence number of this re-configuration request.
Number of new streams: Number of outgoing streams (sender to receiver) to add to the association.

Optional parameters: none

Add incoming streams request parameter

This parameter is used by a sender to request that additional incoming streams be added to the association (i.e. outgoing streams for the receiver).

+	Bits 0 - 15	16 - 31
0	Parameter type = 18	Parameter length = 12
32	Re-configuration request sequence number
64	Number of new streams	Reserved

Parameter type: always 18 for the add incoming streams request parameter
Parameter length: 12

Fixed parameters:

Re-configuration request sequence number: Sequence number of this re-configuration request.
Number of new streams: Number of incoming streams (receiver to sender) to add to the association.

Optional parameters: none

PAD chunk

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

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 132	Chunk flags	Chunk length
32	Padding data
...	Padding data

Chunk type: always 132 for the padding chunk (PAD).
Chunk flags: There are currently no flags used.
Chunk length: Depends on the size of padding data. The minimum length is 4 bytes.

Fixed parameters: none

Optional parameters:

Padding data: Arbitrary data - will be ignored and unceremoniously discarded by the receiver.

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.[8] 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.

+	Bits 0 - 7	8 - 11	12	13	14	15	16 - 31
0	Chunk type = 64	Reserved	I	U	B	E	Chunk length
32	TSN
64	Stream identifier						Reserved
96	Message identifier
128	Payload protocol identifier / Fragment sequence number
160	Data

Chunk type

always 64 for payload data supporting interleaving (I-DATA).

Chunk flags

There are currently only 4 flags used

I — SACK chunk should be sent back without delay.
U — If set, this indicates this data is an unordered chunk. If an unordered chunk is fragmented then each fragment has this flag set.
B — If set, this marks the beginning fragment. An unfragmented chunk has this flag set.
E — If set, this marks the end fragment. An unfragmented chunk has this flag set.

Chunk length: The chunk length has a minimum value of 21 as data of size less than one byte is not allowed.

Fixed parameters:

Transmission sequence number (TSN): The sequence number for the entire DATA stream (used for acknowledgement and retransmission).
Stream identifier: Identifier of the stream that this data chunk belongs to
Message identifier (MID): Identifier of the message in this stream. If a message is fragmented then the same value is used for all fragments. For ordered messages, the MID also specifies the order in which the messages should be delivered to the upper layer. Ordered and unordered messages in the same stream use independent MID sequences.
Payload protocol identifier: Application-specific protocol identifier,[4] only present if the B flag is set. SCTP makes no use of this or modification of it. However, devices along the path or the endpoints may use it. A value of 0 indicates that no payload protocol is specified.
Fragment sequence number: Fragment number for fragmented packets. Only present if the B flag is not set. If the B flag is set, then the fragment sequence number is implicitly zero, and the payload protocol identifier occupies the same space instead.
Data: Application-specific data.

Optional parameters: none.

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.

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 192	Chunk flags	Chunk length
32	New cumulative TSN
64	Stream identifier 1		Stream sequence number 1
...	...		...
32 + N * 32	Stream identifier N		Stream sequence number N

Chunk type: always 192 for the forward TSN chunk (FORWARD-TSN).
Chunk flags: There are currently no flags used.
Chunk length: Depends on the number of new stream sequence numbers included.

Fixed parameters:

New cumulative transmission sequence number (TSN): The next TSN that the receiver should expect. Any previous TSNs should be considered received.

Optional parameters:

Stream identifier 1..N: Stream identifiers of streams that were skipped by this chunk.
Stream sequence 1..N: New stream sequence numbers associated with the streams that were skipped.

ASCONF chunk

+	Bits 0 - 7	8 - 15	16 - 31
0	Chunk type = 193	Chunk flags	Chunk length
32	Sequence number
64	Parameter type = 5 or 6		Parameter length = 8 or 20
96	IPv4 or IPv6 address (4 or 16 bytes)
128 or 224	ASCONF parameter 1
...	...
...	ASCONF parameter N

Chunk type: always 193 for the address reconfiguration chunk (ASCONF).
Chunk flags: There are currently no flags used.
Chunk length: Depends on the type of IP address and the number and lengths of ASCONF parameters included.

Fixed parameters:

Sequence number: The sequence number of the ASCONF packet.
Address parameter: parameter type : Type of address in the address parameter: 5 for IPv4, 6 for IPv6.
Address parameter: parameter length : Length of the address parameter: 8 for IPv4, 20 for IPv6.
Address parameter: IP address : 4 bytes for IPv4, 16 bytes for IPv6.

Optional parameters:

ASCONF parameter 1..N: Address reconfiguration parameters (variable length).

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.

+	Bits 0 - 7	8 - 15	16 - 30	31
0	Chunk type = 194	Chunk flags	Chunk length
32	New cumulative TSN
64	Stream identifier 1		Reserved	U
96	Message identifier 1
...	...		...
...	...
32+N*64	Stream identifier N		Reserved	U
64+N*64	Message identifier N

Chunk type: always 194 for the forward TSN chunk with support for interleaving (I-FORWARD-TSN).
Chunk flags: There are currently no flags used.
Chunk length: Depends on the number of new stream message identifiers included.

Fixed parameters:

New cumulative transmission sequence number (TSN): The next TSN that the receiver should expect. Any previous TSNs should be considered received.

Optional parameters:

Stream identifier 1..N: Stream identifiers of streams that were skipped by this chunk.
U: 0 if the new message identifier is associated with the ordered messages, 1 if it is associated with the unordered messages in the stream.
Message identifier 1..N: New message identifiers associated with the streams that were skipped.

Notes

Castagnoli, G.; S. Brauer; M. Herrmann (June 1993). "Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits". IEEE Transactions on Communications. 41 (6): 883. doi:10.1109/26.231911.. Castagnoli's et al. work on algorithmic selection of CRC polynomials
Koopman, P. (June 2002). "32-Bit Cyclic Redundancy Codes for Internet Applications". The International Conference on Dependable Systems and Networks: 459–468. doi:10.1109/DSN.2002.1028931. ISBN 0-7695-1597-5. S2CID 14775606.. Verification of Castagnoli's results by exhaustive search and some new good polynomials
See https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml; possibly used in an internet draft.
See https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-25 for a list of assigned PPIDs
See https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-26 for a list of assigned HMAC identifiers
Although RFC 4895 mentions padding, strictly speaking, the padding is not part of the AUTH chunk: it is not included in the chunk length, and its presence is already ensured by the SCTP protocol itself, mandated by RFC 4960 (section 3.2).
RFC 4821 - Packetization Layer Path MTU Discovery
The order of two ordered chunks may depend on the combination of TSN and SSN, and two otherwise identical unordered chunks are only distinguishable by their TSNs.

References

RFC 8260 Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol
RFC 7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol
RFC 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
RFC 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
RFC 4960 Stream Control Transmission Protocol (Obsoletes: 2960, 3309)
RFC 4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
RFC 4821 Packetization Layer Path MTU Discovery
RFC 4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)
RFC 4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues
RFC 3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)
RFC 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
RFC 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
RFC 3436 Transport Layer Security over Stream Control Transmission Protocol
RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change
RFC 3286 An Introduction to the Stream Control Transmission Protocol
RFC 3257 Stream Control Transmission Protocol Applicability Statement
RFC 2960 Stream Control Transmission Protocol

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.

[cast93-1] Castagnoli, G.; S. Brauer; M. Herrmann (June 1993). "Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits". IEEE Transactions on Communications. 41 (6): 883. doi:10.1109/26.231911.. Castagnoli's et al. work on algorithmic selection of CRC polynomials

[koop02-2] Koopman, P. (June 2002). "32-Bit Cyclic Redundancy Codes for Internet Applications". The International Conference on Dependable Systems and Networks: 459–468. doi:10.1109/DSN.2002.1028931. ISBN 0-7695-1597-5. S2CID 14775606.. Verification of Castagnoli's results by exhaustive search and some new good polynomials

[chunk-unassigned-3] See https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml; possibly used in an internet draft.

[iana-ppids-4] See https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-25 for a list of assigned PPIDs

[5] See https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-26 for a list of assigned HMAC identifiers

[sctp-padding-6] Although RFC 4895 mentions padding, strictly speaking, the padding is not part of the AUTH chunk: it is not included in the chunk length, and its presence is already ensured by the SCTP protocol itself, mandated by RFC 4960 (section 3.2).

[7] RFC 4821 - Packetization Layer Path MTU Discovery

[8] The order of two ordered chunks may depend on the combination of TSN and SSN, and two otherwise identical unordered chunks are only distinguishable by their TSNs.