RFC 4960
Stream Control Transmission Protocol
Pages: 152
Obsoletes: 2960 3309
Obsoleted by: 9260
Updated by: 6096 6335 7053 8899
Obsoletes: 2960 3309
Obsoleted by: 9260
Updated by: 6096 6335 7053 8899
Part 3 of 7 – Pages 41 to 65
3.3.8. Shutdown Association (SHUTDOWN) (7)
An endpoint in an association MUST use this chunk to initiate a graceful close of the association with its peer. This chunk has the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Chunk Flags | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Set to 0 on transmit and ignored on receipt. Length: 16 bits (unsigned integer) Indicates the length of the parameter. Set to 8. Cumulative TSN Ack: 32 bits (unsigned integer) This parameter contains the TSN of the last chunk received in sequence before any gaps. Note: Since the SHUTDOWN message does not contain Gap Ack Blocks, it cannot be used to acknowledge TSNs received out of order. In a SACK, lack of Gap Ack Blocks that were previously included indicates that the data receiver reneged on the associated DATA chunks. Since SHUTDOWN does not contain Gap Ack Blocks, the receiver of the SHUTDOWN shouldn't interpret the lack of a Gap Ack Block as a renege. (See Section 6.2 for information on reneging.)3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8)
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process; see Section 9.2 for details. The SHUTDOWN ACK chunk has no parameters.
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 = 8 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
Set to 0 on transmit and ignored on receipt.
3.3.10. Operation Error (ERROR) (9)
An endpoint sends this chunk to its peer endpoint to notify it of
certain error conditions. It contains one or more error causes. An
Operation Error is not considered fatal in and of itself, but may be
used with an ABORT chunk to report a fatal condition. It has the
following parameters:
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 | Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ one or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
Set to 0 on transmit and ignored on receipt.
Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the chunk header
and all the Error Cause fields present.
Error causes are defined as variable-length parameters using the format described in Section 3.2.1, that is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cause-Specific Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cause Code: 16 bits (unsigned integer) Defines the type of error conditions being reported. Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down 11 Restart of an Association with New Addresses 12 User Initiated Abort 13 Protocol Violation Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields. Cause-Specific Information: variable length This field carries the details of the error condition. Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 14.3.
3.3.10.1. Invalid Stream Identifier (1)
Cause of error --------------- Invalid Stream Identifier: Indicates endpoint received a DATA chunk sent to a nonexistent stream. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=1 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream Identifier: 16 bits (unsigned integer) Contains the Stream Identifier of the DATA chunk received in error. Reserved: 16 bits This field is reserved. It is set to all 0's on transmit and ignored on receipt.3.3.10.2. Missing Mandatory Parameter (2)
Cause of error --------------- Missing Mandatory Parameter: Indicates that one or more mandatory TLV parameters are missing in a received INIT or INIT ACK. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=2 | Cause Length=8+N*2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of missing params=N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #1 | Missing Param Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #N-1 | Missing Param Type #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Number of Missing params: 32 bits (unsigned integer) This field contains the number of parameters contained in the Cause-Specific Information field.
Missing Param Type: 16 bits (unsigned integer)
Each field will contain the missing mandatory parameter number.
3.3.10.3. Stale Cookie Error (3)
Cause of error
--------------
Stale Cookie Error: Indicates the receipt of a valid State Cookie
that has expired.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of Staleness (usec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measure of Staleness: 32 bits (unsigned integer)
This field contains the difference, in microseconds, between the
current time and the time the State Cookie expired.
The sender of this error cause MAY choose to report how long past
expiration the State Cookie is by including a non-zero value in
the Measure of Staleness field. If the sender does not wish to
provide this information, it should set the Measure of Staleness
field to the value of zero.
3.3.10.4. Out of Resource (4)
Cause of error
---------------
Out of Resource: Indicates that the sender is out of resource. This
is usually sent in combination with or within an ABORT.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=4 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.5. Unresolvable Address (5)
Cause of error --------------- Unresolvable Address: Indicates that the sender is not able to resolve the specified address parameter (e.g., type of address is not supported by the sender). This is usually sent in combination with or within an ABORT. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=5 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unresolvable Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unresolvable Address: variable length The Unresolvable Address field contains the complete Type, Length, and Value of the address parameter (or Host Name parameter) that contains the unresolvable address or host name.3.3.10.6. Unrecognized Chunk Type (6)
Cause of error --------------- Unrecognized Chunk Type: This error cause is returned to the originator of the chunk if the receiver does not understand the chunk and the upper bits of the 'Chunk Type' are set to 01 or 11. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=6 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Chunk / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unrecognized Chunk: variable length The Unrecognized Chunk field contains the unrecognized chunk from the SCTP packet complete with Chunk Type, Chunk Flags, and Chunk Length.
3.3.10.7. Invalid Mandatory Parameter (7)
Cause of error --------------- Invalid Mandatory Parameter: This error cause is returned to the originator of an INIT or INIT ACK chunk when one of the mandatory parameters is set to an invalid value. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=7 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.3.10.8. Unrecognized Parameters (8)
Cause of error --------------- Unrecognized Parameters: This error cause is returned to the originator of the INIT ACK chunk if the receiver does not recognize one or more Optional TLV parameters in the INIT ACK chunk. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=8 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unrecognized Parameters: variable length The Unrecognized Parameters field contains the unrecognized parameters copied from the INIT ACK chunk complete with TLV. This error cause is normally contained in an ERROR chunk bundled with the COOKIE ECHO chunk when responding to the INIT ACK, when the sender of the COOKIE ECHO chunk wishes to report unrecognized parameters.
3.3.10.9. No User Data (9)
Cause of error --------------- No User Data: This error cause is returned to the originator of a DATA chunk if a received DATA chunk has no user data. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=9 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / TSN value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TSN value: 32 bits (unsigned integer) The TSN value field contains the TSN of the DATA chunk received with no user data field. This cause code is normally returned in an ABORT chunk (see Section 6.2).3.3.10.10. Cookie Received While Shutting Down (10)
Cause of error --------------- Cookie Received While Shutting Down: A COOKIE ECHO was received while the endpoint was in the SHUTDOWN-ACK-SENT state. This error is usually returned in an ERROR chunk bundled with the retransmitted SHUTDOWN ACK. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=10 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.11. Restart of an Association with New Addresses (11)
Cause of error -------------- Restart of an association with new addresses: An INIT was received on an existing association. But the INIT added addresses to the association that were previously NOT part of the association. The new addresses are listed in the error code. This ERROR is normally sent as part of an ABORT refusing the INIT (see Section 5.2). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=11 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / New Address TLVs / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: Each New Address TLV is an exact copy of the TLV that was found in the INIT chunk that was new, including the Parameter Type and the Parameter Length.3.3.10.12. User-Initiated Abort (12)
Cause of error -------------- This error cause MAY be included in ABORT chunks that are sent because of an upper-layer request. The upper layer can specify an Upper Layer Abort Reason that is transported by SCTP transparently and MAY be delivered to the upper-layer protocol at the peer. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=12 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Upper Layer Abort Reason / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.13. Protocol Violation (13)
Cause of error -------------- This error cause MAY be included in ABORT chunks that are sent because an SCTP endpoint detects a protocol violation of the peer that is not covered by the error causes described in Section 3.3.10.1 to Section 3.3.10.12. An implementation MAY provide additional information specifying what kind of protocol violation has been detected. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=13 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Additional Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.3.11. Cookie Echo (COOKIE ECHO) (10)
This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk MUST precede any DATA chunk sent within the association, but MAY be bundled with one or more DATA chunks in the same packet. 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 = 10 |Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cookie / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bit Set to 0 on transmit and ignored on receipt. Length: 16 bits (unsigned integer) Set to the size of the chunk in bytes, including the 4 bytes of the chunk header and the size of the cookie.
Cookie: variable size
This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.
An implementation SHOULD make the cookie as small as possible to
ensure interoperability.
Note: A Cookie Echo does NOT contain a State Cookie parameter;
instead, the data within the State Cookie's Parameter Value
becomes the data within the Cookie Echo's Chunk Value. This
allows an implementation to change only the first 2 bytes of the
State Cookie parameter to become a COOKIE ECHO chunk.
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11)
This chunk is used only during the initialization of an association.
It is used to acknowledge the receipt of a COOKIE ECHO chunk. This
chunk MUST precede any DATA or SACK chunk sent within the
association, but MAY be bundled with one or more DATA chunks or SACK
chunk's in the same SCTP packet.
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 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
Set to 0 on transmit and ignored on receipt.
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14)
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN
ACK chunk at the completion of the shutdown process; see Section 9.2
for details.
The SHUTDOWN COMPLETE chunk has no parameters.
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 = 14 |Reserved |T| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
Reserved: 7 bits
Set to 0 on transmit and ignored on receipt.
T bit: 1 bit
The T bit is set to 0 if the sender filled in the Verification Tag
expected by the peer. If the Verification Tag is reflected, the T
bit MUST be set to 1. Reflecting means that the sent Verification
Tag is the same as the received one.
Note: Special rules apply to this chunk for verification, please see
Section 8.5.1 for details.
4. SCTP Association State Diagram
During the life time of an SCTP association, the SCTP endpoint's
association progresses from one state to another in response to
various events. The events that may potentially advance an
association's state include:
o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT],
o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., control
chunks, or
o Some timeout events.
The state diagram in the figures below illustrates state changes,
together with the causing events and resulting actions. Note that
some of the error conditions are not shown in the state diagram.
Full descriptions of all special cases are found in the text.
Note: Chunk names are given in all capital letters, while parameter
names have the first letter capitalized, e.g., COOKIE ECHO chunk type
vs. State Cookie parameter. If more than one event/message can occur
that causes a state transition, it is labeled (A), (B), etc.
----- -------- (from any state)
/ \ / rcv ABORT [ABORT]
rcv INIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT
generate Cookie \ +---------+ delete TCB
snd INIT ACK ---| CLOSED |
+---------+
/ \ [ASSOCIATE]
/ \ ---------------
| | create TCB
| | snd INIT
| | strt init timer
rcv valid | |
COOKIE ECHO | v
(1) ---------------- | +------------+
create TCB | | COOKIE-WAIT| (2)
snd COOKIE ACK | +------------+
| |
| | rcv INIT ACK
| | -----------------
| | snd COOKIE ECHO
| | stop init timer
| | strt cookie timer
| v
| +--------------+
| | COOKIE-ECHOED| (3)
| +--------------+
| |
| | rcv COOKIE ACK
| | -----------------
| | stop cookie timer
v v
+---------------+
| ESTABLISHED |
+---------------+
(from the ESTABLISHED state only)
|
|
/--------+--------\
[SHUTDOWN] / \
-------------------| |
check outstanding | |
DATA chunks | |
v |
+---------+ |
|SHUTDOWN-| | rcv SHUTDOWN
|PENDING | |------------------
+---------+ | check outstanding
| | DATA chunks
No more outstanding | |
---------------------| |
snd SHUTDOWN | |
strt shutdown timer | |
v v
+---------+ +-----------+
(4) |SHUTDOWN-| | SHUTDOWN- | (5,6)
|SENT | | RECEIVED |
+---------+ +-----------+
| \ |
(A) rcv SHUTDOWN ACK | \ |
----------------------| \ |
stop shutdown timer | \rcv:SHUTDOWN |
send SHUTDOWN COMPLETE| \ (B) |
delete TCB | \ |
| \ | No more outstanding
| \ |-----------------
| \ | send SHUTDOWN ACK
(B)rcv SHUTDOWN | \ | strt shutdown timer
----------------------| \ |
send SHUTDOWN ACK | \ |
start shutdown timer | \ |
move to SHUTDOWN- | \ |
ACK-SENT | | |
| v |
| +-----------+
| | SHUTDOWN- | (7)
| | ACK-SENT |
| +----------+-
| | (C)rcv SHUTDOWN COMPLETE
| |-----------------
| | stop shutdown timer
| | delete TCB
| |
| | (D)rcv SHUTDOWN ACK | |-------------- | | stop shutdown timer | | send SHUTDOWN COMPLETE | | delete TCB | | \ +---------+ / \-->| CLOSED |<--/ +---------+ Figure 3: State Transition Diagram of SCTP Notes: 1) If the State Cookie in the received COOKIE ECHO is invalid (i.e., failed to pass the integrity check), the receiver MUST silently discard the packet. Or, if the received State Cookie is expired (see Section 5.1.5), the receiver MUST send back an ERROR chunk. In either case, the receiver stays in the CLOSED state. 2) If the T1-init timer expires, the endpoint MUST retransmit INIT and restart the T1-init timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the endpoint MUST abort the initialization process and report the error to the SCTP user. 3) If the T1-cookie timer expires, the endpoint MUST retransmit COOKIE ECHO and restart the T1-cookie timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the endpoint MUST abort the initialization process and report the error to the SCTP user. 4) In the SHUTDOWN-SENT state, the endpoint MUST acknowledge any received DATA chunks without delay. 5) In the SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new send requests from its SCTP user. 6) In the SHUTDOWN-RECEIVED state, the endpoint MUST transmit or retransmit data and leave this state when all data in queue is transmitted. 7) In the SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new send requests from its SCTP user. The CLOSED state is used to indicate that an association is not created (i.e., doesn't exist).
5. Association Initialization
Before the first data transmission can take place from one SCTP endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must complete an initialization process in order to set up an SCTP association between them. The SCTP user at an endpoint should use the ASSOCIATE primitive to initialize an SCTP association to another SCTP endpoint. IMPLEMENTATION NOTE: From an SCTP user's point of view, an association may be implicitly opened, without an ASSOCIATE primitive (see Section 10.1 B) being invoked, by the initiating endpoint's sending of the first user data to the destination endpoint. The initiating SCTP will assume default values for all mandatory and optional parameters for the INIT/INIT ACK. Once the association is established, unidirectional streams are open for data transfer on both ends (see Section 5.1.1).5.1. Normal Establishment of an Association
The initialization process consists of the following steps (assuming that SCTP endpoint "A" tries to set up an association with SCTP endpoint "Z" and "Z" accepts the new association): A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must provide its Verification Tag (Tag_A) in the Initiate Tag field. Tag_A SHOULD be a random number in the range of 1 to 4294967295 (see Section 5.3.1 for Tag value selection). After sending the INIT, "A" starts the T1-init timer and enters the COOKIE-WAIT state. B) "Z" shall respond immediately with an INIT ACK chunk. The destination IP address of the INIT ACK MUST be set to the source IP address of the INIT to which this INIT ACK is responding. In the response, besides filling in other parameters, "Z" must set the Verification Tag field to Tag_A, and also provide its own Verification Tag (Tag_Z) in the Initiate Tag field. Moreover, "Z" MUST generate and send along with the INIT ACK a State Cookie. See Section 5.1.3 for State Cookie generation. Note: After sending out INIT ACK with the State Cookie parameter, "Z" MUST NOT allocate any resources or keep any states for the new association. Otherwise, "Z" will be vulnerable to resource attacks.
C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1-
init timer and leave the COOKIE-WAIT state. "A" shall then send
the State Cookie received in the INIT ACK chunk in a COOKIE ECHO
chunk, start the T1-cookie timer, and enter the COOKIE-ECHOED
state.
Note: The COOKIE ECHO chunk can be bundled with any pending
outbound DATA chunks, but it MUST be the first chunk in the packet
and until the COOKIE ACK is returned the sender MUST NOT send any
other packets to the peer.
D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" will reply
with a COOKIE ACK chunk after building a TCB and moving to the
ESTABLISHED state. A COOKIE ACK chunk may be bundled with any
pending DATA chunks (and/or SACK chunks), but the COOKIE ACK chunk
MUST be the first chunk in the packet.
IMPLEMENTATION NOTE: An implementation may choose to send the
Communication Up notification to the SCTP user upon reception of a
valid COOKIE ECHO chunk.
E) Upon reception of the COOKIE ACK, endpoint "A" will move from the
COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-
cookie timer. It may also notify its ULP about the successful
establishment of the association with a Communication Up
notification (see Section 10).
An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk.
They MUST be the only chunks present in the SCTP packets that carry
them.
An endpoint MUST send the INIT ACK to the IP address from which it
received the INIT.
Note: T1-init timer and T1-cookie timer shall follow the same rules
given in Section 6.3.
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
decides not to establish the new association due to missing mandatory
parameters in the received INIT or INIT ACK, invalid parameter
values, or lack of local resources, it SHOULD respond with an ABORT
chunk. It SHOULD also specify the cause of abort, such as the type
of the missing mandatory parameters, etc., by including the error
cause parameters with the ABORT chunk. The Verification Tag field in
the common header of the outbound SCTP packet containing the ABORT
chunk MUST be set to the Initiate Tag value of the peer.
Note that a COOKIE ECHO chunk that does NOT pass the integrity check is NOT considered an 'invalid parameter' and requires special handling; see Section 5.1.5. After the reception of the first DATA chunk in an association the endpoint MUST immediately respond with a SACK to acknowledge the DATA chunk. Subsequent acknowledgements should be done as described in Section 6.2. When the TCB is created, each endpoint MUST set its internal Cumulative TSN Ack Point to the value of its transmitted Initial TSN minus one. IMPLEMENTATION NOTE: The IP addresses and SCTP port are generally used as the key to find the TCB within an SCTP instance.5.1.1. Handle Stream Parameters
In the INIT and INIT ACK chunks, the sender of the chunk MUST indicate the number of outbound streams (OSs) it wishes to have in the association, as well as the maximum inbound streams (MISs) it will accept from the other endpoint. After receiving the stream configuration information from the other side, each endpoint MUST perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST use MIS outbound streams and MAY report any shortage to the upper layer. The upper layer can then choose to abort the association if the resource shortage is unacceptable. After the association is initialized, the valid outbound stream identifier range for either endpoint shall be 0 to min(local OS, remote MIS)-1.5.1.2. Handle Address Parameters
During the association initialization, an endpoint shall use the following rules to discover and collect the destination transport address(es) of its peer. A) If there are no address parameters present in the received INIT or INIT ACK chunk, the endpoint shall take the source IP address from which the chunk arrives and record it, in combination with the SCTP source port number, as the only destination transport address for this peer.
B) If there is a Host Name parameter present in the received INIT or
INIT ACK chunk, the endpoint shall resolve that host name to a
list of IP address(es) and derive the transport address(es) of
this peer by combining the resolved IP address(es) with the SCTP
source port.
The endpoint MUST ignore any other IP Address parameters if they
are also present in the received INIT or INIT ACK chunk.
The time at which the receiver of an INIT resolves the host name
has potential security implications to SCTP. If the receiver of
an INIT resolves the host name upon the reception of the chunk,
and the mechanism the receiver uses to resolve the host name
involves potential long delay (e.g., DNS query), the receiver may
open itself up to resource attacks for the period of time while it
is waiting for the name resolution results before it can build the
State Cookie and release local resources.
Therefore, in cases where the name translation involves potential
long delay, the receiver of the INIT MUST postpone the name
resolution till the reception of the COOKIE ECHO chunk from the
peer. In such a case, the receiver of the INIT SHOULD build the
State Cookie using the received Host Name (instead of destination
transport addresses) and send the INIT ACK to the source IP
address from which the INIT was received.
The receiver of an INIT ACK shall always immediately attempt to
resolve the name upon the reception of the chunk.
The receiver of the INIT or INIT ACK MUST NOT send user data
(piggy-backed or stand-alone) to its peer until the host name is
successfully resolved.
If the name resolution is not successful, the endpoint MUST
immediately send an ABORT with "Unresolvable Address" error cause
to its peer. The ABORT shall be sent to the source IP address
from which the last peer packet was received.
C) If there are only IPv4/IPv6 addresses present in the received INIT
or INIT ACK chunk, the receiver MUST derive and record all the
transport addresses from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport addresses
are derived by the combination of SCTP source port (from the
common header) and the IP Address parameter(s) carried in the INIT
or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to
its peer.
D) An INIT or INIT ACK chunk MUST be treated as belonging to an
already established association (or one in the process of being
established) if the use of any of the valid address parameters
contained within the chunk would identify an existing TCB.
IMPLEMENTATION NOTE: In some cases (e.g., when the implementation
doesn't control the source IP address that is used for transmitting),
an endpoint might need to include in its INIT or INIT ACK all
possible IP addresses from which packets to the peer could be
transmitted.
After all transport addresses are derived from the INIT or INIT ACK
chunk using the above rules, the endpoint shall select one of the
transport addresses as the initial primary path.
Note: The INIT ACK MUST be sent to the source address of the INIT.
The sender of INIT may include a 'Supported Address Types' parameter
in the INIT to indicate what types of address are acceptable. When
this parameter is present, the receiver of INIT (initiate) MUST
either use one of the address types indicated in the Supported
Address Types parameter when responding to the INIT, or abort the
association with an "Unresolvable Address" error cause if it is
unwilling or incapable of using any of the address types indicated by
its peer.
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type, it
can abort the initiation process and then attempt a reinitiation by
using a 'Supported Address Types' parameter in the new INIT to
indicate what types of address it prefers.
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either
IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT ACK
chunk from its peer, it MUST use all the addresses belonging to the
supported address family. The other addresses MAY be ignored. The
endpoint SHOULD NOT respond with any kind of error indication.
IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported
Address Types' parameter either IPv4 or IPv6, but uses the other
family for sending the packet containing the INIT chunk, or if it
also lists addresses of the other family in the INIT chunk, then the
address family that is not listed in the 'Supported Address Types'
parameter SHOULD also be considered as supported by the receiver of
the INIT chunk. The receiver of the INIT chunk SHOULD NOT respond
with any kind of error indication.
5.1.3. Generating State Cookie
When sending an INIT ACK as a response to an INIT chunk, the sender of INIT ACK creates a State Cookie and sends it in the State Cookie parameter of the INIT ACK. Inside this State Cookie, the sender should include a MAC (see [RFC2104] for an example), a timestamp on when the State Cookie is created, and the lifespan of the State Cookie, along with all the information necessary for it to establish the association. The following steps SHOULD be taken to generate the State Cookie: 1) Create an association TCB using information from both the received INIT and the outgoing INIT ACK chunk, 2) In the TCB, set the creation time to the current time of day, and the lifespan to the protocol parameter 'Valid.Cookie.Life' (see Section 15), 3) From the TCB, identify and collect the minimal subset of information needed to re-create the TCB, and generate a MAC using this subset of information and a secret key (see [RFC2104] for an example of generating a MAC), and 4) Generate the State Cookie by combining this subset of information and the resultant MAC. After sending the INIT ACK with the State Cookie parameter, the sender SHOULD delete the TCB and any other local resource related to the new association, so as to prevent resource attacks. The hashing method used to generate the MAC is strictly a private matter for the receiver of the INIT chunk. The use of a MAC is mandatory to prevent denial-of-service attacks. The secret key SHOULD be random ([RFC4086] provides some information on randomness guidelines); it SHOULD be changed reasonably frequently, and the timestamp in the State Cookie MAY be used to determine which key should be used to verify the MAC. An implementation SHOULD make the cookie as small as possible to ensure interoperability.
5.1.4. State Cookie Processing
When an endpoint (in the COOKIE-WAIT state) receives an INIT ACK chunk with a State Cookie parameter, it MUST immediately send a COOKIE ECHO chunk to its peer with the received State Cookie. The sender MAY also add any pending DATA chunks to the packet after the COOKIE ECHO chunk. The endpoint shall also start the T1-cookie timer after sending out the COOKIE ECHO chunk. If the timer expires, the endpoint shall retransmit the COOKIE ECHO chunk and restart the T1-cookie timer. This is repeated until either a COOKIE ACK is received or 'Max.Init.Retransmits' (see Section 15) is reached causing the peer endpoint to be marked unreachable (and thus the association enters the CLOSED state).5.1.5. State Cookie Authentication
When an endpoint receives a COOKIE ECHO chunk from another endpoint with which it has no association, it shall take the following actions: 1) Compute a MAC using the TCB data carried in the State Cookie and the secret key (note the timestamp in the State Cookie MAY be used to determine which secret key to use). [RFC2104] can be used as a guideline for generating the MAC, 2) Authenticate the State Cookie as one that it previously generated by comparing the computed MAC against the one carried in the State Cookie. If this comparison fails, the SCTP packet, including the COOKIE ECHO and any DATA chunks, should be silently discarded, 3) Compare the port numbers and the Verification Tag contained within the COOKIE ECHO chunk to the actual port numbers and the Verification Tag within the SCTP common header of the received packet. If these values do not match, the packet MUST be silently discarded. 4) Compare the creation timestamp in the State Cookie to the current local time. If the elapsed time is longer than the lifespan carried in the State Cookie, then the packet, including the COOKIE ECHO and any attached DATA chunks, SHOULD be discarded, and the endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint.
5) If the State Cookie is valid, create an association to the sender
of the COOKIE ECHO chunk with the information in the TCB data
carried in the COOKIE ECHO and enter the ESTABLISHED state.
6) Send a COOKIE ACK chunk to the peer acknowledging receipt of the
COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA
chunk or SACK chunk; however, the COOKIE ACK MUST be the first
chunk in the SCTP packet.
7) Immediately acknowledge any DATA chunk bundled with the COOKIE
ECHO with a SACK (subsequent DATA chunk acknowledgement should
follow the rules defined in Section 6.2). As mentioned in step
6, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
MUST appear first in the SCTP packet.
If a COOKIE ECHO is received from an endpoint with which the receiver
of the COOKIE ECHO has an existing association, the procedures in
Section 5.2 should be followed.
5.1.6. An Example of Normal Association Establishment
In the following example, "A" initiates the association and then sends a user message to "Z", then "Z" sends two user messages to "A" later (assuming no bundling or fragmentation occurs): Endpoint A Endpoint Z {app sets association with Z} (build TCB) INIT [I-Tag=Tag_A & other info] ------\ (Start T1-init timer) \ (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) /-- INIT ACK [Veri Tag=Tag_A, / I-Tag=Tag_Z, (Cancel T1-init timer) <------/ Cookie_Z, & other info] (destroy temp TCB) COOKIE ECHO [Cookie_Z] ------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED state) /---- COOKIE-ACK / (Cancel T1-init timer, <-----/ Enter ESTABLISHED state) {app sends 1st user data; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=0 & user data]--\ (Start T3-rtx timer) \ \-> /----- SACK [TSN Ack=init / TSN_A,Block=0] (Cancel T3-rtx timer) <------/ ... {app sends 2 messages;strm 0} /---- DATA / [TSN=init TSN_Z <--/ Strm=0,Seq=0 & user data 1] SACK [TSN Ack=init TSN_Z, /---- DATA Block=0] --------\ / [TSN=init TSN_Z +1, \/ Strm=0,Seq=1 & user data 2] <------/\ \ \------> Figure 4: INITIATION Example
If the T1-init timer expires at "A" after the INIT or COOKIE ECHO chunks are sent, the same INIT or COOKIE ECHO chunk with the same Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and the timer restarted. This shall be repeated Max.Init.Retransmits times before "A" considers "Z" unreachable and reports the failure to its upper layer (and thus the association enters the CLOSED state). When retransmitting the INIT, the endpoint MUST follow the rules defined in Section 6.3 to determine the proper timer value.
(page 65 continued on part 4)