tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4960

 
 
 

Stream Control Transmission Protocol

Part 3 of 7, p. 41 to 65
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 41 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part