SCTP packet structure

Last updated

BitsBits 0–78–1516–2324–31
+0Source portDestination port
32Verification tag
64Checksum
96Chunk 1 typeChunk 1 flagsChunk 1 length
128Chunk 1 data
......
...Chunk N typeChunk N flagsChunk N length
...Chunk N data

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

Contents

  1. The common header, which occupies the first 12 bytes. In the adjacent diagram, this header is highlighted in blue.
  2. 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 and different control messages.

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–1516–31
0Parameter typeParameter length
32Parameter 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:

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:

ValueAbbreviationDescription
0DATAPayload data
1INITInitiation
2INIT ACKInitiation acknowledgement
3SACKSelective acknowledgement
4HEARTBEATHeartbeat request
5HEARTBEAT ACKHeartbeat acknowledgement
6ABORTAbort
7SHUTDOWNShutdown
8SHUTDOWN ACKShutdown acknowledgement
9ERROROperation error
10COOKIE ECHOState cookie
11COOKIE ACKCookie acknowledgement
12ECNEExplicit congestion notification echo (reserved)
13CWRCongestion window reduced (reserved)
14SHUTDOWN COMPLETEShutdown complete
15AUTHAuthentication chunk
16–62N/AReserved by IETF
63IETF-defined chunk extensions
64I-DATAPayload data supporting packet interleaving
65–126N/AReserved by IETF
127IETF-defined chunk extensions
128ASCONF-ACKAddress configuration change acknowledgement
129N/AUnassigned [3]
130RE-CONFIGStream reconfiguration
131N/AUnassigned [3]
132PADPacket padding
133–190N/AReserved by IETF
191IETF-defined chunk extensions
192FORWARD-TSNIncrement expected TSN
193ASCONFAddress configuration change
194I-FORWARD-TSNIncrement expected TSN, supporting packet interleaving
195–254N/AReserved by IETF
255IETF-defined chunk extensions

DATA chunk

+Bits 0–78–111213141516–31
0Chunk type = 0ReservedIUBEChunk length
32TSN
64Stream identifierStream sequence number
96Payload 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 that 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–78–1516–31
0Chunk type = 1Chunk flagsChunk length
32Initiate tag
64Advertised receiver window credit
96# of outbound streams# of inbound streams
128Initial TSN
160Parameter type = 5Parameter length = 8
192 IPv4 address of sending endpoint
224Parameter type = 6Parameter length = 20
256 IPv6 address of sending endpoint
288
320
352
384Parameter type = 9Parameter length = 8
416Suggested cookie life-span increment (milliseconds)
448Parameter type = 11Parameter length
480Null-terminated host name
512Parameter type = 12Parameter length
544Address type #1Address type #2
576Address type #3...
608Parameter type = 32768Parameter length
640Explicit 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–78–1516–31
0Chunk type = 3Chunk flagsChunk length
32Cumulative TSN ACK
64Advertised receiver window credit
96Number of gap ACK blocks = NNumber of duplicate TSNs = X
128Gap ACK block #1 startGap ACK block #1 end
.........
96 + N × 32Gap ACK block #N startGap ACK block #N end
128 + N × 32Duplicate TSN #1
......
96 + N × 32 + X × 32Duplicate 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–78–1516–31
0Chunk type = 4Chunk flagsChunk length
32Parameter type = 1Parameter 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–78–1516–31
0Chunk type = 5Chunk flagsChunk length
32Parameter type = 1Parameter 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–78–141516–31
0Chunk type = 6ReservedTChunk length
32Zero 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–78–1516–31
0Chunk type = 7Chunk flagsChunk length
32Cumulative 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–78–1516–31
0Chunk type = 8Chunk flagsChunk 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–78–1516–31
0Chunk type = 9Chunk flagsChunk length
32Parameter type = 1Parameter length = 8
64Stream identifierZeros (reserved)
96Parameter type = 2Parameter length
128Number of missing parameters = N
160Missing parameter type #1Missing parameter type #2
192...Missing parameter type #N
224Parameter type = 3Parameter length = 8
256Measure of staleness (microseconds)
288Parameter type = 4Parameter length = 4
320Parameter type = 5Parameter length
352Unresolvable address
384Parameter type = 6Parameter length
416Unrecognized chunk
448Parameter type = 7Parameter length = 4
480Parameter type = 8Parameter length
512Unrecognized parameters
544Parameter type = 9Parameter length = 8
576TSN value
608Parameter type = 10Parameter 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.
+Bits 0–78–1516–31
0Chunk type = 10Chunk flagsChunk 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.
+Bits 0–78–1516–31
0Chunk type = 11Chunk flagsChunk 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–78–141516–31
0Chunk type = 14ReservedTChunk 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–78–1516–31
0Chunk type = 15Flags = 0Chunk length
32Shared key identifierHMAC identifier
64 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–78–1516–31
0Chunk type = 128Chunk flagsChunk length
32Sequence number
64ASCONF 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–78–1516–31
0Chunk type = 130Chunk flagsChunk length
32Re-configuration parameter 1
...
...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–1516–31
0Parameter type = 13Parameter length
32Re-configuration request sequence number
64Re-configuration response sequence number
96Senders last assigned TSN
128Stream number 1Stream number 2
......
96 + 16NStream number N  1Stream number N
Parameter type
always 13 for the outgoing SSN reset request parameter.
Parameter length
16 + 2N.
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–1516–31
0Parameter type = 14Parameter length
32Re-configuration request sequence number
64Stream number 1Stream number 2
......
32 + 16NStream number N  1Stream number N
Parameter type
always 14 for the incoming SSN reset request parameter.
Parameter length
8 + 2N.
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–1516–31
0Parameter type = 15Parameter length = 8
32Re-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–1516–31
0Parameter type = 16Parameter length
32Re-configuration response sequence number
64Result
96Sender's next TSN
128Receiver'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
DescriptionResult
code
Description
0Success – Nothing to do4Error – Request already in progress
1Success – Performed5Error – Bad sequence number
2Denied6In progress
3Error – 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–1516–31
0Parameter type = 17Parameter length = 12
32Re-configuration request sequence number
64Number of new streamsReserved
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–1516–31
0Parameter type = 18Parameter length = 12
32Re-configuration request sequence number
64Number of new streamsReserved
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–78–1516–31
0Chunk type = 132Chunk flagsChunk length
32Padding 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–78–111213141516–31
0Chunk type = 64ReservedIUBEChunk length
32TSN
64Stream identifierReserved
96Message identifier
128Payload 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–78–1516–31
0Chunk type = 192Chunk flagsChunk length
32New cumulative TSN
64Stream identifier 1Stream sequence number 1
.........
32 + N × 32Stream identifier NStream 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–78–1516–31
0Chunk type = 193Chunk flagsChunk length
32Sequence number
64Parameter type = 5 or 6Parameter length = 8 or 20
96IPv4 or IPv6 address (4 or 16 bytes)
128 or 224ASCONF 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–78–1516–3031
0Chunk type = 194Chunk flagsChunk length
32New cumulative TSN
64Stream identifier 1ReservedU
96Message identifier 1
.........
...
32 + N × 64Stream identifier NReservedU
64 + N × 64Message 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

  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
  2. Koopman, P. (June 2002). "32-bit cyclic redundancy codes for Internet applications". Proceedings International Conference on Dependable Systems and Networks. pp. 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
  3. 1 2 See https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml; possibly used in an internet draft.
  4. 1 2 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.
  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.

Related Research Articles

The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address, for example, an error is indicated when a requested service is not available or that a host or router could not be reached. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.

The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport Layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

In computer networking, the User Datagram Protocol (UDP) is one of the core communication protocols of the Internet protocol suite used to send messages to other hosts on an Internet Protocol (IP) network. Within an IP network, UDP does not require prior communication to set up communication channels or data paths.

In computing, a handshake is a signal between two devices or programs, used to, e.g., authenticate, coordinate. An example is the handshaking between a hypervisor and an application in a guest virtual machine.

A virtual circuit (VC) is a means of transporting data over a data network, based on packet switching and in which a connection is first established across the network between two endpoints. The network, rather than having a fixed data rate reservation per connection as in circuit switching, takes advantage of the statistical multiplexing on its transmission links, an intrinsic feature of packet switching.

Trivial File Transfer Protocol (TFTP) is a simple lockstep File Transfer Protocol which allows a client to get a file from or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a local area network. TFTP has been used for this application because it is very simple to implement.

High-Level Data Link Control (HDLC) is a bit-oriented code-transparent synchronous data link layer protocol developed by the International Organization for Standardization (ISO). The standard for HDLC is ISO/IEC 13239:2002.

<span class="mw-page-title-main">Transport layer</span> Layer in the OSI and TCP/IP models providing host-to-host communication services for applications

In computer networking, the transport layer is a conceptual division of methods in the layered architecture of protocols in the network stack in the Internet protocol suite and the OSI model. The protocols of this layer provide end-to-end communication services for applications. It provides services such as connection-oriented communication, reliability, flow control, and multiplexing.

Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol and is defined in RFC 3168 (2001). ECN allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that may be used between two ECN-enabled endpoints when the underlying network infrastructure also supports it.

The Resource Reservation Protocol (RSVP) is a transport layer protocol designed to reserve resources across a network using the integrated services model. RSVP operates over an IPv4 or IPv6 and provides receiver-initiated setup of resource reservations for multicast or unicast data flows. It does not transport application data but is similar to a control protocol, like Internet Control Message Protocol (ICMP) or Internet Group Management Protocol (IGMP). RSVP is described in RFC 2205.

In computer networking, the Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. DCCP implements reliable connection setup, teardown, Explicit Congestion Notification (ECN), congestion control, and feature negotiation. The IETF published DCCP as RFC 4340, a proposed standard, in March 2006. RFC 4336 provides an introduction.

Selective Repeat ARQ/Selective Reject ARQ is a specific instance of the automatic repeat request (ARQ) protocol used to manage sequence numbers and retransmissions in reliable communications.

Internet Protocol Flow Information Export (IPFIX) is an IETF protocol, as well as the name of the IETF working group defining the protocol. It was created based on the need for a common, universal standard of export for Internet Protocol flow information from routers, probes and other devices that are used by mediation systems, accounting/billing systems and network management systems to facilitate services such as measurement, accounting and billing. The IPFIX standard defines how IP flow information is to be formatted and transferred from an exporter to a collector. Previously many data network operators were relying on Cisco Systems' proprietary NetFlow technology for traffic flow information export.

Chunked transfer encoding is a streaming data transfer mechanism available in Hypertext Transfer Protocol (HTTP) version 1.1, defined in RFC 9112 §7.1. In chunked transfer encoding, the data stream is divided into a series of non-overlapping "chunks". The chunks are sent out and received independently of one another. No knowledge of the data stream outside the currently-being-processed chunk is necessary for both the sender and the receiver at any given time.

A sliding window protocol is a feature of packet-based data transmission protocols. Sliding window protocols are used where reliable in-order delivery of packets is required, such as in the data link layer as well as in the Transmission Control Protocol (TCP). They are also used to improve efficiency when the channel may include high latency.

An IPv6 packet is the smallest message entity exchanged using Internet Protocol version 6 (IPv6). Packets consist of control information for addressing and routing and a payload of user data. The control information in IPv6 packets is subdivided into a mandatory fixed header and optional extension headers. The payload of an IPv6 packet is typically a datagram or segment of the higher-level transport layer protocol, but may be data for an internet layer or link layer instead.

The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.

NACK-Oriented Reliable Multicast (NORM) is a transport layer Internet protocol designed to provide reliable transport in multicast groups in data networks. It is formally defined by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 5740, which was published in November 2009.

References