Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 4960

Stream Control Transmission Protocol

Pages: 152
Proposed Standard
Errata
Obsoletes:  29603309
Updated by:  6096633570538899
Part 3 of 7 – Pages 41 to 65
First   Prev   Next

Top   ToC   RFC4960 - Page 41   prevText

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.
Top   ToC   RFC4960 - Page 42
        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.
Top   ToC   RFC4960 - Page 43
   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.
Top   ToC   RFC4960 - Page 44
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.
Top   ToC   RFC4960 - Page 45
   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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC4960 - Page 46
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.
Top   ToC   RFC4960 - Page 47
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.
Top   ToC   RFC4960 - Page 48
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC4960 - Page 49
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 / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC4960 - Page 50
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.
Top   ToC   RFC4960 - Page 51
   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
Top   ToC   RFC4960 - Page 52
      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.
Top   ToC   RFC4960 - Page 53
                      -----          -------- (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  |
                      +---------------+
Top   ToC   RFC4960 - Page 54
                    (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
                         |                   |
Top   ToC   RFC4960 - Page 55
                         |                   | (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).
Top   ToC   RFC4960 - Page 56

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.
Top   ToC   RFC4960 - Page 57
   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.
Top   ToC   RFC4960 - Page 58
   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.
Top   ToC   RFC4960 - Page 59
   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.
Top   ToC   RFC4960 - Page 60
   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.
Top   ToC   RFC4960 - Page 61

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.
Top   ToC   RFC4960 - Page 62

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.
Top   ToC   RFC4960 - Page 63
   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.
Top   ToC   RFC4960 - Page 64

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
Top   ToC   RFC4960 - Page 65
   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)

Next Section