Network Working Group R. Stewart
Request for Comments: 2960 Q. Xie
Category: Standards Track Motorola
K. Morneault
C. Sharp
Cisco
H. Schwarzbauer
Siemens
T. Taylor
Nortel Networks
I. Rytina
EriCsson
M. Kalla
Telcordia
L. Zhang
UCLA
V. Paxson
ACIRI
October 2000
Stream Control Transmission Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes the Stream Control Transmission Protocol
(SCTP). SCTP is designed to transport PSTN signaling messages over
IP networks, but is capable of broader applications.
SCTP is a reliable transport protocol operating on top of a
connectionless packet network such as IP. It offers the following
services to its users:
-- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams,
with an option for order-of-arrival delivery of individual user
messages,
-- optional bundling of multiple user messages into a single SCTP
packet, and
-- network-level fault tolerance through supporting of multi-
homing at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks.
Table of Contents
1. Introduction.................................................. 5
1.1 Motivation.................................................. 6
1.2 Architectural View of SCTP.................................. 6
1.3 Functional View of SCTP..................................... 7
1.3.1 Association Startup and Takedown........................ 8
1.3.2 Sequenced Delivery within Streams....................... 9
1.3.3 User Data Fragmentation................................. 9
1.3.4 Acknowledgement and Congestion Avoidance................ 9
1.3.5 Chunk Bundling ......................................... 10
1.3.6 Packet Validation....................................... 10
1.3.7 Path Management......................................... 11
1.4 Key Terms................................................... 11
1.5 Abbreviations............................................... 15
1.6 Serial Number Arithmetic.................................... 15
2. Conventions.................................................... 16
3. SCTP packet Format............................................ 16
3.1 SCTP Common Header Field Descriptions....................... 17
3.2 Chunk Field Descriptions.................................... 18
3.2.1 Optional/Variable-length Parameter Format............... 20
3.3 SCTP Chunk Definitions...................................... 21
3.3.1 Payload Data (DATA)..................................... 22
3.3.2 Initiation (INIT)....................................... 24
3.3.2.1 Optional or Variable Length Parameters.............. 26
3.3.3 Initiation Acknowledgement (INIT ACK)................... 30
3.3.3.1 Optional or Variable Length Parameters.............. 33
3.3.4 Selective Acknowledgement (SACK)........................ 33
3.3.5 Heartbeat Request (HEARTBEAT)........................... 37
3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 38
3.3.7 Abort Association (ABORT)............................... 39
3.3.8 Shutdown Association (SHUTDOWN)......................... 40
3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 40
3.3.10 Operation Error (ERROR)................................ 41
3.3.10.1 Invalid Stream Identifier.......................... 42
3.3.10.2 Missing Mandatory Parameter........................ 43
3.3.10.3 Stale Cookie Error................................. 43
3.3.10.4 Out of Resource.................................... 44
3.3.10.5 Unresolvable Address............................... 44
3.3.10.6 Unrecognized Chunk Type............................ 44
3.3.10.7 Invalid Mandatory Parameter........................ 45
3.3.10.8 Unrecognized Parameters............................ 45
3.3.10.9 No User Data....................................... 46
3.3.10.10 Cookie Received While Shutting Down............... 46
3.3.11 Cookie Echo (COOKIE ECHO).............................. 46
3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 47
3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 48
4. SCTP Association State Diagram................................. 48
5. Association Initialization..................................... 52
5.1 Normal Establishment of an Association...................... 52
5.1.1 Handle Stream Parameters................................ 54
5.1.2 Handle Address Parameters............................... 54
5.1.3 Generating State Cookie................................. 56
5.1.4 State Cookie Processing................................. 57
5.1.5 State Cookie Authentication............................. 57
5.1.6 An Example of Normal Association Establishment.......... 58
5.2 Handle Duplicate or uneXPected INIT, INIT ACK, COOKIE ECHO,
and COOKIE ACK.............................................. 60
5.2.1 Handle Duplicate INIT in COOKIE-WAIT
or COOKIE-ECHOED States................................. 60
5.2.2 Unexpected INIT in States Other than CLOSED,
COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT........ 61
5.2.3 Unexpected INIT ACK..................................... 61
5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 62
5.2.4.1 An Example of a Association Restart................. 64
5.2.5 Handle Duplicate COOKIE ACK............................. 66
5.2.6 Handle Stale COOKIE Error............................... 66
5.3 Other Initialization Issues................................. 67
5.3.1 Selection of Tag Value.................................. 67
6. User Data Transfer............................................. 67
6.1 Transmission of DATA Chunks................................. 69
6.2 Acknowledgement on Reception of DATA Chunks................. 70
6.2.1 Tracking Peer's Receive Buffer Space.................... 73
6.3 Management Retransmission Timer............................. 75
6.3.1 RTO Calculation......................................... 75
6.3.2 Retransmission Timer Rules.............................. 76
6.3.3 Handle T3-rtx Expiration................................ 77
6.4 Multi-homed SCTP Endpoints.................................. 78
6.4.1 Failover from Inactive Destination Address.............. 79
6.5 Stream Identifier and Stream Sequence Number................ 80
6.6 Ordered and Unordered Delivery.............................. 80
6.7 Report Gaps in Received DATA TSNs........................... 81
6.8 Adler-32 Checksum Calculation............................... 82
6.9 Fragmentation............................................... 83
6.10 Bundling .................................................. 84
7. Congestion Control .......................................... 85
7.1 SCTP Differences from TCP Congestion Control................ 85
7.2 SCTP Slow-Start and Congestion Avoidance.................... 87
7.2.1 Slow-Start.............................................. 87
7.2.2 Congestion Avoidance.................................... 89
7.2.3 Congestion Control...................................... 89
7.2.4 Fast Retransmit on Gap Reports.......................... 90
7.3 Path MTU Discovery.......................................... 91
8. Fault Management.............................................. 92
8.1 Endpoint Failure Detection.................................. 92
8.2 Path Failure Detection...................................... 92
8.3 Path Heartbeat.............................................. 93
8.4 Handle "Out of the blue" Packets............................ 95
8.5 Verification Tag............................................ 96
8.5.1 Exceptions in Verification Tag Rules.................... 97
9. Termination of Association..................................... 98
9.1 Abort of an Association..................................... 98
9.2 Shutdown of an Association.................................. 98
10. Interface with Upper Layer....................................101
10.1 ULP-to-SCTP................................................101
10.2 SCTP-to-ULP................................................111
11. Security Considerations.......................................114
11.1 Security Objectives........................................114
11.2 SCTP Responses To Potential Threats........................115
11.2.1 Countering Insider Attacks.............................115
11.2.2 Protecting against Data Corruption in the Network......115
11.2.3 Protecting Confidentiality.............................115
11.2.4 Protecting against Blind Denial of Service Attacks.....116
11.2.4.1 Flooding...........................................116
11.2.4.2 Blind Masquerade...................................118
11.2.4.3 Improper Monopolization of Services................118
11.3 Protection against Fraud and Repudiation...................119
12. Recommended Transmission Control Block (TCB) Parameters.......120
12.1 Parameters necessary for the SCTP instance.................120
12.2 Parameters necessary per association (i.e. the TCB)........120
12.3 Per Transport Address Data.................................122
12.4 General Parameters Needed..................................123
13. IANA Considerations...........................................123
13.1 IETF-defined Chunk Extension...............................123
13.2 IETF-defined Chunk Parameter Extension.....................124
13.3 IETF-defined Additional Error Causes.......................124
13.4 Payload Protocol Identifiers...............................125
14. Suggested SCTP Protocol Parameter Values......................125
15. Acknowledgements..............................................126
16. Authors' Addresses............................................126
17. References....................................................128
18. Bibliography..................................................129
Appendix A .......................................................131
Appendix B .......................................................132
Full Copyright Statement .........................................134
1. Introduction
This section explains the reasoning behind the development of the
Stream Control Transmission Protocol (SCTP), the services it offers,
and the basic concepts needed to understand the detailed description
of the protocol.
1.1 Motivation
TCP [RFC793] has performed immense service as the primary means of
reliable data transfer in IP networks. However, an increasing number
of recent applications have found TCP too limiting, and have
incorporated their own reliable data transfer protocol on top of UDP
[RFC768]. The limitations which users have wished to bypass include
the following:
-- TCP provides both reliable data transfer and strict order-of-
transmission delivery of data. Some applications need reliable
transfer without sequence maintenance, while others would be
satisfied with partial ordering of the data. In both of these
cases the head-of-line blocking offered by TCP causes unnecessary
delay.
-- The stream-oriented nature of TCP is often an inconvenience.
Applications must add their own record marking to delineate their
messages, and must make explicit use of the push facility to
ensure that a complete message is transferred in a reasonable
time.
-- The limited scope of TCP sockets complicates the task of
providing highly-available data transfer capability using multi-
homed hosts.
-- TCP is relatively vulnerable to denial of service attacks, such
as SYN attacks.
Transport of PSTN signaling across the IP network is an application
for which all of these limitations of TCP are relevant. While this
application directly motivated the development of SCTP, other
applications may find SCTP a good match to their requirements.
1.2 Architectural View of SCTP
SCTP is viewed as a layer between the SCTP user application ("SCTP
user" for short) and a connectionless packet network service such as
IP. The remainder of this document assumes SCTP runs on top of IP.
The basic service offered by SCTP is the reliable transfer of user
messages between peer SCTP users. It performs this service within
the context of an association between two SCTP endpoints. Section 10
of this document sketches the API which should exist at the boundary
between the SCTP and the SCTP user layers.
SCTP is connection-oriented in nature, but the SCTP association is a
broader concept than the TCP connection. SCTP provides the means for
each SCTP endpoint (Section 1.4) to provide the other endpoint
(during association startup) with a list of transport addresses
(i.e., multiple IP addresses in combination with an SCTP port)
through which that endpoint can be reached and from which it will
originate SCTP packets. The association spans transfers over all of
the possible source/destination combinations which may be generated
from each endpoint's lists.
_____________ _____________
SCTP User SCTP User
Application Application
------------- -------------
SCTP SCTP
Transport Transport
Service Service
------------- -------------
One or more ---- One or more
IP Network IP address \/ IP address IP Network
Service appearances /\ appearances Service
_____________ ---- _____________
SCTP Node A <-------- Network transport -------> SCTP Node B
Figure 1: An SCTP Association
1.3 Functional View of SCTP
The SCTP transport service can be decomposed into a number of
functions. These are depicted in Figure 2 and explained in the
remainder of this section.
SCTP User Application
-----------------------------------------------------
_____________ ____________________
Sequenced delivery
Association within streams
____________________
startup
____________________________
and User Data Fragmentation
____________________________
takedown
____________________________
Acknowledgement
and
Congestion Avoidance
____________________________
____________________________
Chunk Bundling
____________________________
________________________________
Packet Validation
________________________________
________________________________
Path Management
_____________ ________________________________
Figure 2: Functional View of the SCTP Transport Service
1.3.1 Association Startup and Takedown
An association is initiated by a request from the SCTP user (see the
description of the ASSOCIATE (or SEND) primitive in Section 10).
A cookie mechanism, similar to one described by Karn and Simpson in
[RFC2522], is employed during the initialization to provide
protection against security attacks. The cookie mechanism uses a
four-way handshake, the last two legs of which are allowed to carry
user data for fast setup. The startup sequence is described in
Section 5 of this document.
SCTP provides for graceful close (i.e., shutdown) of an active
association on request from the SCTP user. See the description of
the SHUTDOWN primitive in Section 10. SCTP also allows ungraceful
close (i.e., abort), either on request from the user (ABORT
primitive) or as a result of an error condition detected within the
SCTP layer. Section 9 describes both the graceful and the ungraceful
close procedures.
SCTP does not support a half-open state (like TCP) wherein one side
may continue sending data while the other end is closed. When either
endpoint performs a shutdown, the association on each peer will stop
accepting new data from its user and only deliver data in queue at
the time of the graceful close (see Section 9).
1.3.2 Sequenced Delivery within Streams
The term "stream" is used in SCTP to refer to a sequence of user
messages that are to be delivered to the upper-layer protocol in
order with respect to other messages within the same stream. This is
in contrast to its usage in TCP, where it refers to a sequence of
bytes (in this document a byte is assumed to be eight bits).
The SCTP user can specify at association startup time the number of
streams to be supported by the association. This number is
negotiated with the remote end (see Section 5.1.1). User messages
are associated with stream numbers (SEND, RECEIVE primitives, Section
10). Internally, SCTP assigns a stream sequence number to each
message passed to it by the SCTP user. On the receiving side, SCTP
ensures that messages are delivered to the SCTP user in sequence
within a given stream. However, while one stream may be blocked
waiting for the next in-sequence user message, delivery from other
streams may proceed.
SCTP provides a mechanism for bypassing the sequenced delivery
service. User messages sent using this mechanism are delivered to
the SCTP user as soon as they are received.
1.3.3 User Data Fragmentation
When needed, SCTP fragments user messages to ensure that the SCTP
packet passed to the lower layer conforms to the path MTU. On
receipt, fragments are reassembled into complete messages before
being passed to the SCTP user.
1.3.4 Acknowledgement and Congestion Avoidance
SCTP assigns a Transmission Sequence Number (TSN) to each user data
fragment or unfragmented message. The TSN is independent of any
stream sequence number assigned at the stream level. The receiving
end acknowledges all TSNs received, even if there are gaps in the
sequence. In this way, reliable delivery is kept functionally
separate from sequenced stream delivery.
The acknowledgement and congestion avoidance function is responsible
for packet retransmission when timely acknowledgement has not been
received. Packet retransmission is conditioned by congestion
avoidance procedures similar to those used for TCP. See Sections 6
and 7 for a detailed description of the protocol procedures
associated with this function.
1.3.5 Chunk Bundling
As described in Section 3, the SCTP packet as delivered to the lower
layer consists of a common header followed by one or more chunks.
Each chunk may contain either user data or SCTP control information.
The SCTP user has the option to request bundling of more than one
user messages into a single SCTP packet. The chunk bundling function
of SCTP is responsible for assembly of the complete SCTP packet and
its disassembly at the receiving end.
During times of congestion an SCTP implementation MAY still perform
bundling even if the user has requested that SCTP not bundle. The
user's disabling of bundling only affects SCTP implementations that
may delay a small period of time before transmission (to attempt to
encourage bundling). When the user layer disables bundling, this
small delay is prohibited but not bundling that is performed during
congestion or retransmission.
1.3.6 Packet Validation
A mandatory Verification Tag field and a 32 bit checksum field (see
Appendix B for a description of the Adler-32 checksum) are included
in the SCTP common header. The Verification Tag value is chosen by
each end of the association during association startup. Packets
received without the expected Verification Tag value are discarded,
as a protection against blind masquerade attacks and against stale
SCTP packets from a previous association. The Adler-32 checksum
should be set by the sender of each SCTP packet to provide additional
protection against data corruption in the network. The receiver of
an SCTP packet with an invalid Adler-32 checksum silently discards
the packet.
1.3.7 Path Management
The sending SCTP user is able to manipulate the set of transport
addresses used as destinations for SCTP packets through the
primitives described in Section 10. The SCTP path management
function chooses the destination transport address for each outgoing
SCTP packet based on the SCTP user's instructions and the currently
perceived reachability status of the eligible destination set. The
path management function monitors reachability through heartbeats
when other packet traffic is inadequate to provide this information
and advises the SCTP user when reachability of any far-end transport
address changes. The path management function is also responsible
for reporting the eligible set of local transport addresses to the
far end during association startup, and for reporting the transport
addresses returned from the far end to the SCTP user.
At association start-up, a primary path is defined for each SCTP
endpoint, and is used for normal sending of SCTP packets.
On the receiving end, the path management is responsible for
verifying the existence of a valid SCTP association to which the
inbound SCTP packet belongs before passing it for further processing.
Note: Path Management and Packet Validation are done at the same
time, so although described separately above, in reality they cannot
be performed as separate items.
1.4 Key Terms
Some of the language used to describe SCTP has been introduced in the
previous sections. This section provides a consolidated list of the
key terms and their definitions.
o Active destination transport address: A transport address on a
peer endpoint which a transmitting endpoint considers available
for receiving user messages.
o Bundling: An optional multiplexing operation, whereby more than
one user message may be carried in the same SCTP packet. Each
user message occupies its own DATA chunk.
o Chunk: A unit of information within an SCTP packet, consisting of
a chunk header and chunk-specific content.
o Congestion Window (cwnd): An SCTP variable that limits the data,
in number of bytes, a sender can send to a particular destination
transport address before receiving an acknowledgement.
o Cumulative TSN Ack Point: The TSN of the last DATA chunk
acknowledged via the Cumulative TSN Ack field of a SACK.
o Idle destination address: An address that has not had user
messages sent to it within some length of time, normally the
HEARTBEAT interval or greater.
o Inactive destination transport address: An address which is
considered inactive due to errors and unavailable to transport
user messages.
o Message = user message: Data submitted to SCTP by the Upper Layer
Protocol (ULP).
o Message Authentication Code (MAC): An integrity check mechanism
based on cryptographic hash functions using a secret key.
Typically, message authentication codes are used between two
parties that share a secret key in order to validate information
transmitted between these parties. In SCTP it is used by an
endpoint to validate the State Cookie information that is returned
from the peer in the COOKIE ECHO chunk. The term "MAC" has
different meanings in different contexts. SCTP uses this term
with the same meaning as in [RFC2104].
o Network Byte Order: Most significant byte first, a.k.a., Big
Endian.
o Ordered Message: A user message that is delivered in order with
respect to all previous user messages sent within the stream the
message was sent on.
o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated
DATA chunk) that has been sent by the endpoint but for which it
has not yet received an acknowledgement.
o Path: The route taken by the SCTP packets sent by one SCTP
endpoint to a specific destination transport address of its peer
SCTP endpoint. Sending to different destination transport
addresses does not necessarily guarantee getting separate paths.
o Primary Path: The primary path is the destination and source
address that will be put into a packet outbound to the peer
endpoint by default. The definition includes the source address
since an implementation MAY wish to specify both destination and
source address to better control the return path taken by reply
chunks and on which interface the packet is transmitted when the
data sender is multi-homed.
o Receiver Window (rwnd): An SCTP variable a data sender uses to
store the most recently calculated receiver window of its peer, in
number of bytes. This gives the sender an indication of the space
available in the receiver's inbound buffer.
o SCTP association: A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information
including Verification Tags and the currently active set of
Transmission Sequence Numbers (TSNs), etc. An association can be
uniquely identified by the transport addresses used by the
endpoints in the association. Two SCTP endpoints MUST NOT have
more than one SCTP association between them at any given time.
o SCTP endpoint: The logical sender/receiver of SCTP packets. On a
multi-homed host, an SCTP endpoint is represented to its peers as
a combination of a set of eligible destination transport addresses
to which SCTP packets can be sent and a set of eligible source
transport addresses from which SCTP packets can be received. All
transport addresses used by an SCTP endpoint must use the same
port number, but can use multiple IP addresses. A transport
address used by an SCTP endpoint must not be used by another SCTP
endpoint. In other Words, a transport address is unique to an
SCTP endpoint.
o SCTP packet (or packet): The unit of data delivery across the
interface between SCTP and the connectionless packet network
(e.g., IP). An SCTP packet includes the common SCTP header,
possible SCTP control chunks, and user data encapsulated within
SCTP DATA chunks.
o SCTP user application (SCTP user): The logical higher-layer
application entity which uses the services of SCTP, also called
the Upper-layer Protocol (ULP).
o Slow Start Threshold (ssthresh): An SCTP variable. This is the
threshold which the endpoint will use to determine whether to
perform slow start or congestion avoidance on a particular
destination transport address. Ssthresh is in number of bytes.
o Stream: A uni-directional logical channel established from one to
another associated SCTP endpoint, within which all user messages
are delivered in sequence except for those submitted to the
unordered delivery service.
Note: The relationship between stream numbers in opposite directions
is strictly a matter of how the applications use them. It is the
responsibility of the SCTP user to create and manage these
correlations if they are so desired.
o Stream Sequence Number: A 16-bit sequence number used internally
by SCTP to assure sequenced delivery of the user messages within a
given stream. One stream sequence number is attached to each user
message.
o Tie-Tags: Verification Tags from a previous association. These
Tags are used within a State Cookie so that the newly restarting
association can be linked to the original association within the
endpoint that did not restart.
o Transmission Control Block (TCB): An internal data structure
created by an SCTP endpoint for each of its existing SCTP
associations to other SCTP endpoints. TCB contains all the status
and operational information for the endpoint to maintain and
manage the corresponding association.
o Transmission Sequence Number (TSN): A 32-bit sequence number used
internally by SCTP. One TSN is attached to each chunk containing
user data to permit the receiving SCTP endpoint to acknowledge its
receipt and detect duplicate deliveries.
o Transport address: A Transport Address is traditionally defined
by Network Layer address, Transport Layer protocol and Transport
Layer port number. In the case of SCTP running over IP, a
transport address is defined by the combination of an IP address
and an SCTP port number (where SCTP is the Transport protocol).
o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the associated
DATA chunk) which has been received by the endpoint but for which
an acknowledgement has not yet been sent. Or in the opposite case,
for a packet that has been sent but no acknowledgement has been
received.
o Unordered Message: Unordered messages are "unordered" with respect
to any other message, this includes both other unordered messages
as well as other ordered messages. Unordered message might be
delivered prior to or later than ordered messages sent on the same
stream.
o User message: The unit of data delivery across the interface
between SCTP and its user.
o Verification Tag: A 32 bit unsigned integer that is randomly
generated. The Verification Tag provides a key that allows a
receiver to verify that the SCTP packet belongs to the current
association and is not an old or stale packet from a previous
association.
1.5. Abbreviations
MAC - Message Authentication Code [RFC2104]
RTO - Retransmission Time-out
RTT - Round-trip Time
RTTVAR - Round-trip Time Variation
SCTP - Stream Control Transmission Protocol
SRTT - Smoothed RTT
TCB - Transmission Control Block
TLV - Type-Length-Value Coding Format
TSN - Transmission Sequence Number
ULP - Upper-layer Protocol
1.6 Serial Number Arithmetic
It is essential to remember that the actual Transmission Sequence
Number space is finite, though very large. This space ranges from 0
to 2**32 - 1. Since the space is finite, all arithmetic dealing with
Transmission Sequence Numbers must be performed modulo 2**32. This
unsigned arithmetic preserves the relationship of sequence numbers as
they cycle from 2**32 - 1 to 0 again. There are some suBTleties to
computer modulo arithmetic, so great care should be taken in
programming the comparison of such values. When referring to TSNs,
the symbol "=<" means "less than or equal"(modulo 2**32).
Comparisons and arithmetic on TSNs in this document SHOULD use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more
than 2**31 - 1 above the beginning TSN of its current send window.
Doing so will cause problems in comparing TSNs.
Transmission Sequence Numbers wrap around when they reach 2**32 - 1.
That is, the next TSN a DATA chunk MUST use after transmitting TSN =
2*32 - 1 is TSN = 0.
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.
All other arithmetic and comparisons in this document uses normal
arithmetic.
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
[RFC2119].
3. SCTP packet Format
An SCTP packet is composed of a common header and chunks. A chunk
contains either control information or user data.
The SCTP packet format is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Common Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk #1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk #n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple chunks can be bundled into one SCTP packet up to the MTU
size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks.
These chunks MUST NOT be bundled with any other chunk in a packet.
See Section 6.10 for more details on chunk bundling.
If a user data message doesn't fit into one SCTP packet it can be
fragmented into multiple chunks using the procedure defined in
Section 6.9.
All integer fields in an SCTP packet MUST be transmitted in network
byte order, unless otherwise stated.
3.1 SCTP Common Header Field Descriptions
SCTP Common Header Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port Number Destination Port Number
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Verification Tag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Checksum
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port Number: 16 bits (unsigned integer)
This is the SCTP sender's port number. It can be used by the
receiver in combination with the source IP address, the SCTP
destination port and possibly the destination IP address to
identify the association to which this packet belongs.
Destination Port Number: 16 bits (unsigned integer)
This is the SCTP port number to which this packet is destined.
The receiving host will use this port number to de-multiplex the
SCTP packet to the correct receiving endpoint/application.
Verification Tag: 32 bits (unsigned integer)
The receiver of this packet uses the Verification Tag to validate
the sender of this SCTP packet. On transmit, the value of this
Verification Tag MUST be set to the value of the Initiate Tag
received from the peer endpoint during the association
initialization, with the following exceptions:
- A packet containing an INIT chunk MUST have a zero Verification
Tag.
- A packet containing a SHUTDOWN-COMPLETE chunk with the T-bit
set MUST have the Verification Tag copied from the packet with
the SHUTDOWN-ACK chunk.
- A packet containing an ABORT chunk may have the verification
tag copied from the packet which caused the ABORT to be sent.
For details see Section 8.4 and 8.5.
An INIT chunk MUST be the only chunk in the SCTP packet carrying it.
Checksum: 32 bits (unsigned integer)
This field contains the checksum of this SCTP packet. Its
calculation is discussed in Section 6.8. SCTP uses the Adler-
32 algorithm as described in Appendix B for calculating the
checksum
3.2 Chunk Field Descriptions
The figure below illustrates the field format for the chunks to be
transmitted in the SCTP packet. Each chunk is formatted with a Chunk
Type field, a chunk-specific Flag field, a Chunk Length field, and a
Value field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type Chunk Flags Chunk Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / Chunk Value /
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type: 8 bits (unsigned integer)
This field identifies the type of information contained in the
Chunk Value field. It takes a value from 0 to 254. The value of
255 is reserved for future use as an extension field.
The values of Chunk Types are defined as follows:
ID Value Chunk Type
----- ----------
0 - Payload Data (DATA)
1 - Initiation (INIT)
2 - Initiation Acknowledgement (INIT ACK)
3 - Selective Acknowledgement (SACK)
4 - Heartbeat Request (HEARTBEAT)
5 - Heartbeat Acknowledgement (HEARTBEAT ACK)
6 - Abort (ABORT)
7 - Shutdown (SHUTDOWN)
8 - Shutdown Acknowledgement (SHUTDOWN ACK)
9 - Operation Error (ERROR)
10 - State Cookie (COOKIE ECHO)
11 - Cookie Acknowledgement (COOKIE ACK)
12 - Reserved for Explicit Congestion Notification Echo (ECNE)
13 - Reserved for Congestion Window Reduced (CWR)
14 - Shutdown Complete (SHUTDOWN COMPLETE)
15 to 62 - reserved by IETF
63 - IETF-defined Chunk Extensions
64 to 126 - reserved by IETF
127 - IETF-defined Chunk Extensions
128 to 190 - reserved by IETF
191 - IETF-defined Chunk Extensions
192 to 254 - reserved by IETF
255 - IETF-defined Chunk Extensions
Chunk Types are encoded such that the highest-order two bits specify
the action that must be taken if the processing endpoint does not
recognize the Chunk Type.
00 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
10 - Skip this chunk and continue processing.
11 - Skip this chunk and continue processing, but report in an ERROR
Chunk using the 'Unrecognized Chunk Type' cause of error.
Note: The ECNE and CWR chunk types are reserved for future use of
Explicit Congestion Notification (ECN).
Chunk Flags: 8 bits
The usage of these bits depends on the chunk type as given by the
Chunk Type. Unless otherwise specified, they are set to zero on
transmit and are ignored on receipt.
Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes including the
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any
padding.
Chunk Value: variable length
The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type.
The total length of a chunk (including Type, Length and Value fields)
MUST be a multiple of 4 bytes. If the length of the chunk is not a
multiple of 4 bytes, the sender MUST pad the chunk with all zero
bytes and this padding is not included in the chunk length field.
The sender should never pad with more than 3 bytes. The receiver
MUST ignore the padding bytes.
SCTP defined chunks are described in detail in Section 3.3. The
guidelines for IETF-defined chunk extensions can be found in Section
13.1 of this document.
3.2.1 Optional/Variable-length Parameter Format
Chunk values of SCTP control chunks consist of a chunk-type-specific
header of required fields, followed by zero or more parameters. The
optional and variable-length parameters contained in a chunk are
defined in a Type-Length-Value format as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type Parameter Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / Parameter Value /
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Parameter Type: 16 bits (unsigned integer)
The Type field is a 16 bit identifier of the type of parameter.
It takes a value of 0 to 65534.
The value of 65535 is reserved for IETF-defined extensions. Values
other than those defined in specific SCTP chunk description are
reserved for use by IETF.
Chunk Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Type, Parameter Length, and
Parameter Value fields. Thus, a parameter with a zero-length
Parameter Value field would have a Length field of 4. The
Parameter Length does not include any padding bytes.
Chunk Parameter Value: variable-length.
The Parameter Value field contains the actual information to be
transferred in the parameter.
The total length of a parameter (including Type, Parameter Length and
Value fields) MUST be a multiple of 4 bytes. If the length of the
parameter is not a multiple of 4 bytes, the sender pads the Parameter
at the end (i.e., after the Parameter Value field) with all zero
bytes. The length of the padding is not included in the parameter
length field. A sender SHOULD NOT pad with more than 3 bytes. The
receiver MUST ignore the padding bytes.
The Parameter Types are encoded such that the highest-order two bits
specify the action that must be taken if the processing endpoint does
not recognize the Parameter Type.
00 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type' (in
either an ERROR or in the INIT ACK).
The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2.
3.3 SCTP Chunk Definitions
This section defines the format of the different SCTP chunk types.
3.3.1 Payload Data (DATA) (0)
The following format MUST be used for the DATA chunk:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 0 ReservedUBE Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TSN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stream Identifier S Stream Sequence Number n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Protocol Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / User Data (seq n of Stream S) /
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 5 bits
Should be set to all '0's and ignored by the receiver.
U bit: 1 bit
The (U)nordered bit, if set to '1', indicates that this is an
unordered DATA chunk, and there is no Stream Sequence Number
assigned to this DATA chunk. Therefore, the receiver MUST ignore
the Stream Sequence Number field.
After re-assembly (if necessary), unordered DATA chunks MUST be
dispatched to the upper layer by the receiver without any attempt
to re-order.
If an unordered user message is fragmented, each fragment of the
message MUST have its U bit set to '1'.
B bit: 1 bit
The (B)eginning fragment bit, if set, indicates the first fragment
of a user message.
E bit: 1 bit
The (E)nding fragment bit, if set, indicates the last fragment of
a user message.
An unfragmented user message shall have both the B and E bits set to
'1'. Setting both B and E bits to '0' indicates a middle fragment of
a multi-fragment user message, as summarized in the following table:
B E Description
============================================================
1 0 First piece of a fragmented user message
+----------------------------------------------------------+
0 0 Middle piece of a fragmented user message
+----------------------------------------------------------+
0 1 Last piece of a fragmented user message
+----------------------------------------------------------+
1 1 Unfragmented Message
============================================================
Table 1: Fragment Description Flags
============================================================
When a user message is fragmented into multiple chunks, the TSNs are
used by the receiver to reassemble the message. This means that the
TSNs for each fragment of a fragmented user message MUST be strictly
sequential.
Length: 16 bits (unsigned integer)
This field indicates the length of the DATA chunk in bytes from
the beginning of the type field to the end of the user data field
excluding any padding. A DATA chunk with no user data field will
have Length set to 16 (indicating 16 bytes).
TSN : 32 bits (unsigned integer)
This value represents the TSN for this DATA chunk. The valid
range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back
to 0 after reaching 4294967295.
Stream Identifier S: 16 bits (unsigned integer)
Identifies the stream to which the following user data belongs.
Stream Sequence Number n: 16 bits (unsigned integer)
This value represents the stream sequence number of the following
user data within the stream S. Valid range is 0 to 65535.
When a user message is fragmented by SCTP for transport, the same
stream sequence number MUST be carried in each of the fragments of
the message.
Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified
protocol identifier. This value is passed to SCTP by its upper
layer and sent to its peer. This identifier is not used by SCTP
but can be used by certain network entities as well as the peer
application to identify the type of information being carried in
this DATA chunk. This field must be sent even in fragmented DATA
chunks (to make sure it is available for agents in the middle of
the network).
The value 0 indicates no application identifier is specified by
the upper layer for this payload data.
User Data: variable length
This is the payload user data. The implementation MUST pad the
end of the data to a 4 byte boundary with all-zero bytes. Any
padding MUST NOT be included in the length field. A sender MUST
never add more than 3 bytes of padding.
3.3.2 Initiation (INIT) (1)
This chunk is used to initiate a SCTP association between two
endpoints. The format of the INIT chunk is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 1 Chunk Flags Chunk Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiate Tag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Advertised Receiver Window Credit (a_rwnd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Outbound Streams Number of Inbound Streams
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initial TSN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / Optional/Variable-Length Parameters /
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The INIT chunk contains the following parameters. Unless otherwise
noted, each parameter MUST only be included once in the INIT chunk.
Fixed Parameters Status
----------------------------------------------
Initiate Tag Mandatory
Advertised Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN Mandatory
Variable Parameters Status Type Value
-------------------------------------------------------------
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Cookie Preservative Optional 9
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
Supported Address Types (Note 4) Optional 12
Note 1: The INIT chunks can contain multiple addresses that can be
IPv4 and/or IPv6 in any combination.
Note 2: The ECN capable field is reserved for future use of Explicit
Congestion Notification.
Note 3: An INIT chunk MUST NOT contain more than one Host Name
address parameter. Moreover, the sender of the INIT MUST NOT combine
any other address types with the Host Name address in the INIT. The
receiver of INIT MUST ignore any other address types if the Host Name
address parameter is present in the received INIT chunk.
Note 4: This parameter, when present, specifies all the address types
the sending endpoint can support. The absence of this parameter
indicates that the sending endpoint can support any address type.
The Chunk Flags field in INIT is reserved and all bits in it should
be set to 0 by the sender and ignored by the receiver. The sequence
of parameters within an INIT can be processed in any order.
Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT (the responding end) records the value of
the Initiate Tag parameter. This value MUST be placed into the
Verification Tag field of every SCTP packet that the receiver of
the INIT transmits within this association.
The Initiate Tag is allowed to have any value except 0. See
Section 5.3.1 for more on the selection of the tag value.
If the value of the Initiate Tag in a received INIT chunk is found
to be 0, the receiver MUST treat it as an error and close the
association by transmitting an ABORT.
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
integer)
This value represents the dedicated buffer space, in number of
bytes, the sender of the INIT has reserved in association with
this window. During the life of the association this buffer space
SHOULD not be lessened (i.e. dedicated buffers taken away from
this association); however, an endpoint MAY change the value of
a_rwnd it sends in SACK chunks.
Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the number of outbound streams the sender of this INIT
chunk wishes to create in this association. The value of 0 MUST
NOT be used.
Note: A receiver of an INIT with the OS value set to 0 SHOULD
abort the association.
Number of Inbound Streams (MIS) : 16 bits (unsigned integer)
Defines the maximum number of streams the sender of this INIT
chunk allows the peer end to create in this association. The
value 0 MUST NOT be used.
Note: There is no negotiation of the actual number of streams but
instead the two endpoints will use the min(requested, offered).
See Section 5.1.1 for details.
Note: A receiver of an INIT with the MIS value of 0 SHOULD abort
the association.
Initial TSN (I-TSN) : 32 bits (unsigned integer)
Defines the initial TSN that the sender will use. The valid range
is from 0 to 4294967295. This field MAY be set to the value of
the Initiate Tag field.
3.3.2.1 Optional/Variable Length Parameters in INIT
The following parameters follow the Type-Length-Value format as
defined in Section 3.2.1. Any Type-Length-Value fields MUST come
after the fixed-length fields defined in the previous section.
IPv4 Address Parameter (5)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 5 Length = 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address: 32 bits (unsigned integer)
Contains an IPv4 address of the sending endpoint. It is binary
encoded.
IPv6 Address Parameter (6)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 6 Length = 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: 128 bit (unsigned integer)
Contains an IPv6 address of the sending endpoint. It is binary
encoded.
Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC2373]
but should instead use an IPv4 Address Parameter for an IPv4
address.
Combined with the Source Port Number in the SCTP common header,
the value passed in an IPv4 or IPv6 Address parameter indicates a
transport address the sender of the INIT will support for the
association being initiated. That is, during the lifetime of this
association, this IP address can appear in the source address
field of an IP datagram sent from the sender of the INIT, and can
be used as a destination address of an IP datagram sent from the
receiver of the INIT.
More than one IP Address parameter can be included in an INIT
chunk when the INIT sender is multi-homed. Moreover, a multi-
homed endpoint may have Access to different types of network, thus
more than one address type can be present in one INIT chunk, i.e.,
IPv4 and IPv6 addresses are allowed in the same INIT chunk.
If the INIT contains at least one IP Address parameter, then the
source address of the IP datagram containing the INIT chunk and
any additional address(es) provided within the INIT can be used as
destinations by the endpoint receiving the INIT. If the INIT does
not contain any IP Address parameters, the endpoint receiving the
INIT MUST use the source address associated with the received IP
datagram as its sole destination address for the association.
Note that not using any IP address parameters in the INIT and
INIT-ACK is an alternative to make an association more likely to
work across a NAT box.
Cookie Preservative (9)
The sender of the INIT shall use this parameter to suggest to the
receiver of the INIT for a longer life-span of the State Cookie.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 9 Length = 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Cookie Life-span Increment (msec.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Cookie Life-span Increment: 32 bits (unsigned integer)
This parameter indicates to the receiver how much increment in
milliseconds the sender wishes the receiver to add to its default
cookie life-span.
This optional parameter should be added to the INIT chunk by the
sender when it re-attempts establishing an association with a peer
to which its previous attempt of establishing the association failed
due to a stale cookie operation error. The receiver MAY choose to
ignore the suggested cookie life-span increase for its own security
reasons.
Host Name Address (11)
The sender of INIT uses this parameter to pass its Host Name (in
place of its IP addresses) to its peer. The peer is responsible
for resolving the name. Using this parameter might make it more
likely for the association to work across a NAT box.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 11 Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Host Name /
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Host Name: variable length
This field contains a host name in "host name syntax" per RFC1123
Section 2.1 [RFC1123]. The method for resolving the host name is
out of scope of SCTP.
Note: At least one null terminator is included in the Host Name
string and must be included in the length.
Supported Address Types (12)
The sender of INIT uses this parameter to list all the address
types it can support.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 12 Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type #1 Address Type #2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type: 16 bits (unsigned integer)
This is filled with the type value of the corresponding address
TLV (e.g., IPv4 = 5, IPv6 = 6, Hostname = 11).
3.3.3 Initiation Acknowledgement (INIT ACK) (2):
The INIT ACK chunk is used to acknowledge the initiation of an SCTP
association.
The parameter part of INIT ACK is formatted similarly to the INIT
chunk. It uses two extra variable parameters: The State Cookie and
the Unrecognized Parameter:
The format of the INIT ACK chunk is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 2 Chunk Flags Chunk Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiate Tag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Advertised Receiver Window Credit
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Outbound Streams Number of Inbound Streams
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initial TSN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / Optional/Variable-Length Parameters /
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT ACK records the value of the Initiate Tag
parameter. This value MUST be placed into the Verification Tag
field of every SCTP packet that the INIT ACK receiver transmits
within this association.
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for
more on the selection of the Initiate Tag value.
If the value of the Initiate Tag in a received INIT ACK chunk is
found to be 0, the receiver MUST treat it as an error and close
the association by transmitting an ABORT.
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
integer)
This value represents the dedicated buffer space, in number of
bytes, the sender of the INIT ACK has reserved in association with
this window. During the life of the association this buffer space
SHOULD not be lessened (i.e. dedicated buffers taken away from
this association).
Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the number of outbound streams the sender of this INIT ACK
chunk wishes to create in this association. The value of 0 MUST
NOT be used.
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
destroy the association discarding its TCB.
Number of Inbound Streams (MIS) : 16 bits (unsigned integer)
Defines the maximum number of streams the sender of this INIT ACK
chunk allows the peer end to create in this association. The
value 0 MUST NOT be used.
Note: There is no negotiation of the actual number of streams but
instead the two endpoints will use the min(requested, offered).
See Section 5.1.1 for details.
Note: A receiver of an INIT ACK with the MIS value set to 0
SHOULD destroy the association discarding its TCB.
Initial TSN (I-TSN) : 32 bits (unsigned integer)
Defines the initial TSN that the INIT-ACK sender will use. The
valid range is from 0 to 4294967295. This field MAY be set to the
value of the Initiate Tag field.
Fixed Parameters Status
----------------------------------------------
Initiate Tag Mandatory
Advertised Receiver Window Credit Mandatory
Numb
