tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4960

 
 
 

Stream Control Transmission Protocol

Part 2 of 7, p. 15 to 40
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
3.  SCTP Packet Format

   An SCTP packet is composed of a common header and chunks.  A chunk
   contains either control information or user data.

   The SCTP packet format is shown below:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Common Header                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Chunk #1                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           ...                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Chunk #n                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Multiple chunks can be bundled into one SCTP packet up to the MTU
   size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks.
   These chunks MUST NOT be bundled with any other chunk in a packet.
   See Section 6.10 for more details on chunk bundling.

   If a user data message doesn't fit into one SCTP packet it can be
   fragmented into multiple chunks using the procedure defined in
   Section 6.9.

   All integer fields in an SCTP packet MUST be transmitted in network
   byte order, unless otherwise stated.

Top      Up      ToC       Page 16 
3.1.  SCTP Common Header Field Descriptions

                       SCTP Common Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Source Port Number        |     Destination Port Number   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Verification Tag                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Checksum                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Source Port Number: 16 bits (unsigned integer)

      This is the SCTP sender's port number.  It can be used by the
      receiver in combination with the source IP address, the SCTP
      destination port, and possibly the destination IP address to
      identify the association to which this packet belongs.  The port
      number 0 MUST NOT be used.

   Destination Port Number: 16 bits (unsigned integer)

      This is the SCTP port number to which this packet is destined.
      The receiving host will use this port number to de-multiplex the
      SCTP packet to the correct receiving endpoint/application.  The
      port number 0 MUST NOT be used.

   Verification Tag: 32 bits (unsigned integer)

      The receiver of this packet uses the Verification Tag to validate
      the sender of this SCTP packet.  On transmit, the value of this
      Verification Tag MUST be set to the value of the Initiate Tag
      received from the peer endpoint during the association
      initialization, with the following exceptions:

      -  A packet containing an INIT chunk MUST have a zero Verification
            Tag.

      -  A packet containing a SHUTDOWN COMPLETE chunk with the T bit
         set MUST have the Verification Tag copied from the packet with
         the SHUTDOWN ACK chunk.

      -  A packet containing an ABORT chunk may have the verification
         tag copied from the packet that caused the ABORT to be sent.
         For details see Section 8.4 and Section 8.5.

Top      Up      ToC       Page 17 
   An INIT chunk MUST be the only chunk in the SCTP packet carrying it.

   Checksum: 32 bits (unsigned integer)

      This field contains the checksum of this SCTP packet.  Its
      calculation is discussed in Section 6.8.  SCTP uses the CRC32c
      algorithm as described in Appendix B for calculating the checksum.

3.2.  Chunk Field Descriptions

   The figure below illustrates the field format for the chunks to be
   transmitted in the SCTP packet.  Each chunk is formatted with a Chunk
   Type field, a chunk-specific Flag field, a Chunk Length field, and a
   Value field.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Chunk Type  | Chunk  Flags  |        Chunk Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                          Chunk Value                          /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Chunk Type: 8 bits (unsigned integer)

      This field identifies the type of information contained in the
      Chunk Value field.  It takes a value from 0 to 254.  The value of
      255 is reserved for future use as an extension field.

      The values of Chunk Types are defined as follows:

   ID Value    Chunk Type
   -----       ----------
   0          - Payload Data (DATA)
   1          - Initiation (INIT)
   2          - Initiation Acknowledgement (INIT ACK)
   3          - Selective Acknowledgement (SACK)
   4          - Heartbeat Request (HEARTBEAT)
   5          - Heartbeat Acknowledgement (HEARTBEAT ACK)
   6          - Abort (ABORT)
   7          - Shutdown (SHUTDOWN)
   8          - Shutdown Acknowledgement (SHUTDOWN ACK)
   9          - Operation Error (ERROR)
   10         - State Cookie (COOKIE ECHO)
   11         - Cookie Acknowledgement (COOKIE ACK)

Top      Up      ToC       Page 18 
   12         - Reserved for Explicit Congestion Notification Echo
                (ECNE)
   13         - Reserved for Congestion Window Reduced (CWR)
   14         - Shutdown Complete (SHUTDOWN COMPLETE)
   15 to 62   - available
   63         - reserved for IETF-defined Chunk Extensions
   64 to 126  - available
   127        - reserved for IETF-defined Chunk Extensions
   128 to 190 - available
   191        - reserved for IETF-defined Chunk Extensions
   192 to 254 - available
   255        - reserved for IETF-defined Chunk Extensions

      Chunk Types are encoded such that the highest-order 2 bits specify
      the action that must be taken if the processing endpoint does not
      recognize the Chunk Type.

      00 -  Stop processing this SCTP packet and discard it, do not
            process any further chunks within it.

      01 -  Stop processing this SCTP packet and discard it, do not
            process any further chunks within it, and report the
            unrecognized chunk in an 'Unrecognized Chunk Type'.

      10 -  Skip this chunk and continue processing.

      11 -  Skip this chunk and continue processing, but report in an
            ERROR chunk using the 'Unrecognized Chunk Type' cause of
            error.

      Note: The ECNE and CWR chunk types are reserved for future use of
      Explicit Congestion Notification (ECN); see Appendix A.

   Chunk Flags: 8 bits

      The usage of these bits depends on the Chunk type as given by the
      Chunk Type field.  Unless otherwise specified, they are set to 0
      on transmit and are ignored on receipt.

   Chunk Length: 16 bits (unsigned integer)

      This value represents the size of the chunk in bytes, including
      the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
      Therefore, if the Chunk Value field is zero-length, the Length
      field will be set to 4.  The Chunk Length field does not count any
      chunk padding.

Top      Up      ToC       Page 19 
      Chunks (including Type, Length, and Value fields) are padded out
      by the sender with all zero bytes to be a multiple of 4 bytes
      long.  This padding MUST NOT be more than 3 bytes in total.  The
      Chunk Length value does not include terminating padding of the
      chunk.  However, it does include padding of any variable-length
      parameter except the last parameter in the chunk.  The receiver
      MUST ignore the padding.

      Note: A robust implementation should accept the chunk whether or
      not the final padding has been included in the Chunk Length.

   Chunk Value: variable length

      The Chunk Value field contains the actual information to be
      transferred in the chunk.  The usage and format of this field is
      dependent on the Chunk Type.

   The total length of a chunk (including Type, Length, and Value
   fields) MUST be a multiple of 4 bytes.  If the length of the chunk is
   not a multiple of 4 bytes, the sender MUST pad the chunk with all
   zero bytes, and this padding is not included in the Chunk Length
   field.  The sender MUST NOT pad with more than 3 bytes.  The receiver
   MUST ignore the padding bytes.

   SCTP-defined chunks are described in detail in Section 3.3.  The
   guidelines for IETF-defined chunk extensions can be found in Section
   14.1 of this document.

3.2.1.  Optional/Variable-Length Parameter Format

   Chunk values of SCTP control chunks consist of a chunk-type-specific
   header of required fields, followed by zero or more parameters.  The
   optional and variable-length parameters contained in a chunk are
   defined in a Type-Length-Value format as shown below.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Parameter Type       |       Parameter Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                       Parameter Value                         /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 20 
   Chunk Parameter Type: 16 bits (unsigned integer)

      The Type field is a 16-bit identifier of the type of parameter.
      It takes a value of 0 to 65534.

      The value of 65535 is reserved for IETF-defined extensions.
      Values other than those defined in specific SCTP chunk
      descriptions are reserved for use by IETF.

   Chunk Parameter Length: 16 bits (unsigned integer)

      The Parameter Length field contains the size of the parameter in
      bytes, including the Parameter Type, Parameter Length, and
      Parameter Value fields.  Thus, a parameter with a zero-length
      Parameter Value field would have a Length field of 4.  The
      Parameter Length does not include any padding bytes.

   Chunk Parameter Value: variable length

      The Parameter Value field contains the actual information to be
      transferred in the parameter.

      The total length of a parameter (including Type, Parameter Length,
      and Value fields) MUST be a multiple of 4 bytes.  If the length of
      the parameter is not a multiple of 4 bytes, the sender pads the
      parameter at the end (i.e., after the Parameter Value field) with
      all zero bytes.  The length of the padding is not included in the
      Parameter Length field.  A sender MUST NOT pad with more than 3
      bytes.  The receiver MUST ignore the padding bytes.

      The Parameter Types are encoded such that the highest-order 2 bits
      specify the action that must be taken if the processing endpoint
      does not recognize the Parameter Type.

      00 -  Stop processing this parameter; do not process any further
            parameters within this chunk.

      01 -  Stop processing this parameter, do not process any further
            parameters within this chunk, and report the unrecognized
            parameter in an 'Unrecognized Parameter', as described in
            Section 3.2.2.

      10 -  Skip this parameter and continue processing.

      11 -  Skip this parameter and continue processing but report the
            unrecognized parameter in an 'Unrecognized Parameter', as
            described in Section 3.2.2.

Top      Up      ToC       Page 21 
   Please note that in all four cases, an INIT ACK or COOKIE ECHO chunk
   is sent.  In the 00 or 01 case, the processing of the parameters
   after the unknown parameter is canceled, but no processing already
   done is rolled back.

   The actual SCTP parameters are defined in the specific SCTP chunk
   sections.  The rules for IETF-defined parameter extensions are
   defined in Section 14.2.  Note that a parameter type MUST be unique
   across all chunks.  For example, the parameter type '5' is used to
   represent an IPv4 address (see Section 3.3.2.1).  The value '5' then
   is reserved across all chunks to represent an IPv4 address and MUST
   NOT be reused with a different meaning in any other chunk.

3.2.2.  Reporting of Unrecognized Parameters

   If the receiver of an INIT chunk detects unrecognized parameters and
   has to report them according to Section 3.2.1, it MUST put the
   'Unrecognized Parameter' parameter(s) in the INIT ACK chunk sent in
   response to the INIT chunk.  Note that if the receiver of the INIT
   chunk is NOT going to establish an association (e.g., due to lack of
   resources), an 'Unrecognized Parameter' would NOT be included with
   any ABORT being sent to the sender of the INIT.

   If the receiver of an INIT ACK chunk detects unrecognized parameters
   and has to report them according to Section 3.2.1, it SHOULD bundle
   the ERROR chunk containing the 'Unrecognized Parameters' error cause
   with the COOKIE ECHO chunk sent in response to the INIT ACK chunk.
   If the receiver of the INIT ACK cannot bundle the COOKIE ECHO chunk
   with the ERROR chunk, the ERROR chunk MAY be sent separately but not
   before the COOKIE ACK has been received.

   Note: Any time a COOKIE ECHO is sent in a packet, it MUST be the
   first chunk.

3.3.  SCTP Chunk Definitions

   This section defines the format of the different SCTP chunk types.

Top      Up      ToC       Page 22 
3.3.1.  Payload Data (DATA) (0)

   The following format MUST be used for the DATA chunk:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0    | Reserved|U|B|E|    Length                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              TSN                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Stream Identifier S      |   Stream Sequence Number n    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Payload Protocol Identifier                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                 User Data (seq n of Stream S)                 /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved: 5 bits

      Should be set to all '0's and ignored by the receiver.

   U bit: 1 bit

      The (U)nordered bit, if set to '1', indicates that this is an
      unordered DATA chunk, and there is no Stream Sequence Number
      assigned to this DATA chunk.  Therefore, the receiver MUST ignore
      the Stream Sequence Number field.

      After reassembly (if necessary), unordered DATA chunks MUST be
      dispatched to the upper layer by the receiver without any attempt
      to reorder.

      If an unordered user message is fragmented, each fragment of the
      message MUST have its U bit set to '1'.

   B bit: 1 bit

      The (B)eginning fragment bit, if set, indicates the first fragment
      of a user message.

   E bit: 1 bit

      The (E)nding fragment bit, if set, indicates the last fragment of
      a user message.

Top      Up      ToC       Page 23 
   An unfragmented user message shall have both the B and E bits set to
   '1'.  Setting both B and E bits to '0' indicates a middle fragment of
   a multi-fragment user message, as summarized in the following table:

               B E                  Description
            ============================================================
            |  1 0 | First piece of a fragmented user message          |
            +----------------------------------------------------------+
            |  0 0 | Middle piece of a fragmented user message         |
            +----------------------------------------------------------+
            |  0 1 | Last piece of a fragmented user message           |
            +----------------------------------------------------------+
            |  1 1 | Unfragmented message                              |
            ============================================================
            |             Table 1: Fragment Description Flags          |
            ============================================================

   When a user message is fragmented into multiple chunks, the TSNs are
   used by the receiver to reassemble the message.  This means that the
   TSNs for each fragment of a fragmented user message MUST be strictly
   sequential.

   Length: 16 bits (unsigned integer)

      This field indicates the length of the DATA chunk in bytes from
      the beginning of the type field to the end of the User Data field
      excluding any padding.  A DATA chunk with one byte of user data
      will have Length set to 17 (indicating 17 bytes).

      A DATA chunk with a User Data field of length L will have the
      Length field set to (16 + L) (indicating 16+L bytes) where L MUST
      be greater than 0.

   TSN: 32 bits (unsigned integer)

      This value represents the TSN for this DATA chunk.  The valid
      range of TSN is from 0 to 4294967295 (2**32 - 1).  TSN wraps back
      to 0 after reaching 4294967295.

   Stream Identifier S: 16 bits (unsigned integer)

      Identifies the stream to which the following user data belongs.

   Stream Sequence Number n: 16 bits (unsigned integer)

      This value represents the Stream Sequence Number of the following
      user data within the stream S.  Valid range is 0 to 65535.

Top      Up      ToC       Page 24 
      When a user message is fragmented by SCTP for transport, the same
      Stream Sequence Number MUST be carried in each of the fragments of
      the message.

   Payload Protocol Identifier: 32 bits (unsigned integer)

      This value represents an application (or upper layer) specified
      protocol identifier.  This value is passed to SCTP by its upper
      layer and sent to its peer.  This identifier is not used by SCTP
      but can be used by certain network entities, as well as by the
      peer application, to identify the type of information being
      carried in this DATA chunk.  This field must be sent even in
      fragmented DATA chunks (to make sure it is available for agents in
      the middle of the network).  Note that this field is NOT touched
      by an SCTP implementation; therefore, its byte order is NOT
      necessarily big endian.  The upper layer is responsible for any
      byte order conversions to this field.

      The value 0 indicates that no application identifier is specified
      by the upper layer for this payload data.

   User Data: variable length

      This is the payload user data.  The implementation MUST pad the
      end of the data to a 4-byte boundary with all-zero bytes.  Any
      padding MUST NOT be included in the Length field.  A sender MUST
      never add more than 3 bytes of padding.

3.3.2.  Initiation (INIT) (1)

   This chunk is used to initiate an SCTP association between two
   endpoints.  The format of the INIT chunk is shown below:

Top      Up      ToC       Page 25 
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 1    |  Chunk Flags  |      Chunk Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Initiate Tag                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Advertised Receiver Window Credit (a_rwnd)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Number of Outbound Streams   |  Number of Inbound Streams    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Initial TSN                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /              Optional/Variable-Length Parameters              /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The INIT chunk contains the following parameters.  Unless otherwise
   noted, each parameter MUST only be included once in the INIT chunk.

            Fixed Parameters                     Status
            ----------------------------------------------
            Initiate Tag                        Mandatory
            Advertised Receiver Window Credit   Mandatory
            Number of Outbound Streams          Mandatory
            Number of Inbound Streams           Mandatory
            Initial TSN                         Mandatory

          Variable Parameters                  Status     Type Value
          -------------------------------------------------------------
          IPv4 Address (Note 1)               Optional    5 IPv6 Address
          (Note 1)               Optional    6 Cookie Preservative
          Optional    9 Reserved for ECN Capable (Note 2)   Optional
          32768 (0x8000) Host Name Address (Note 3)          Optional
          11 Supported Address Types (Note 4)    Optional    12

   Note 1: The INIT chunks can contain multiple addresses that can be
   IPv4 and/or IPv6 in any combination.

   Note 2: The ECN Capable field is reserved for future use of Explicit
   Congestion Notification.

   Note 3: An INIT chunk MUST NOT contain more than one Host Name
   Address parameter.  Moreover, the sender of the INIT MUST NOT combine
   any other address types with the Host Name Address in the INIT.  The
   receiver of INIT MUST ignore any other address types if the Host Name
   Address parameter is present in the received INIT chunk.

Top      Up      ToC       Page 26 
   Note 4: This parameter, when present, specifies all the address types
   the sending endpoint can support.  The absence of this parameter
   indicates that the sending endpoint can support any address type.

   IMPLEMENTATION NOTE: If an INIT chunk is received with known
   parameters that are not optional parameters of the INIT chunk, then
   the receiver SHOULD process the INIT chunk and send back an INIT ACK.
   The receiver of the INIT chunk MAY bundle an ERROR chunk with the
   COOKIE ACK chunk later.  However, restrictive implementations MAY
   send back an ABORT chunk in response to the INIT chunk.

   The Chunk Flags field in INIT is reserved, and all bits in it should
   be set to 0 by the sender and ignored by the receiver.  The sequence
   of parameters within an INIT can be processed in any order.

   Initiate Tag: 32 bits (unsigned integer)

      The receiver of the INIT (the responding end) records the value of
      the Initiate Tag parameter.  This value MUST be placed into the
      Verification Tag field of every SCTP packet that the receiver of
      the INIT transmits within this association.

      The Initiate Tag is allowed to have any value except 0.  See
      Section 5.3.1 for more on the selection of the tag value.

      If the value of the Initiate Tag in a received INIT chunk is found
      to be 0, the receiver MUST treat it as an error and close the
      association by transmitting an ABORT.

   Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
   integer)

      This value represents the dedicated buffer space, in number of
      bytes, the sender of the INIT has reserved in association with
      this window.  During the life of the association, this buffer
      space SHOULD NOT be lessened (i.e., dedicated buffers taken away
      from this association); however, an endpoint MAY change the value
      of a_rwnd it sends in SACK chunks.

   Number of Outbound Streams (OS): 16 bits (unsigned integer)

      Defines the number of outbound streams the sender of this INIT
      chunk wishes to create in this association.  The value of 0 MUST
      NOT be used.

      Note: A receiver of an INIT with the OS value set to 0 SHOULD
      abort the association.

Top      Up      ToC       Page 27 
   Number of Inbound Streams (MIS): 16 bits (unsigned integer)

      Defines the maximum number of streams the sender of this INIT
      chunk allows the peer end to create in this association.  The
      value 0 MUST NOT be used.

      Note: There is no negotiation of the actual number of streams but
      instead the two endpoints will use the min(requested, offered).
      See Section 5.1.1 for details.

      Note: A receiver of an INIT with the MIS value of 0 SHOULD abort
      the association.

   Initial TSN (I-TSN): 32 bits (unsigned integer)

      Defines the initial TSN that the sender will use.  The valid range
      is from 0 to 4294967295.  This field MAY be set to the value of
      the Initiate Tag field.

3.3.2.1.  Optional/Variable-Length Parameters in INIT

   The following parameters follow the Type-Length-Value format as
   defined in Section 3.2.1.  Any Type-Length-Value fields MUST come
   after the fixed-length fields defined in the previous section.

   IPv4 Address Parameter (5)

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type = 5               |      Length = 8               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        IPv4 Address                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Address: 32 bits (unsigned integer)

      Contains an IPv4 address of the sending endpoint.  It is binary
      encoded.

Top      Up      ToC       Page 28 
   IPv6 Address Parameter (6)

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Type = 6           |          Length = 20          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         IPv6 Address                          |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Address: 128 bits (unsigned integer)

      Contains an IPv6 [RFC2460] address of the sending endpoint.  It is
      binary encoded.

      Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291],
      but should instead use an IPv4 Address parameter for an IPv4
      address.

      Combined with the Source Port Number in the SCTP common header,
      the value passed in an IPv4 or IPv6 Address parameter indicates a
      transport address the sender of the INIT will support for the
      association being initiated.  That is, during the life time of
      this association, this IP address can appear in the source address
      field of an IP datagram sent from the sender of the INIT, and can
      be used as a destination address of an IP datagram sent from the
      receiver of the INIT.

      More than one IP Address parameter can be included in an INIT
      chunk when the INIT sender is multi-homed.  Moreover, a multi-
      homed endpoint may have access to different types of network;
      thus, more than one address type can be present in one INIT chunk,
      i.e., IPv4 and IPv6 addresses are allowed in the same INIT chunk.

      If the INIT contains at least one IP Address parameter, then the
      source address of the IP datagram containing the INIT chunk and
      any additional address(es) provided within the INIT can be used as
      destinations by the endpoint receiving the INIT.  If the INIT does
      not contain any IP Address parameters, the endpoint receiving the
      INIT MUST use the source address associated with the received IP
      datagram as its sole destination address for the association.

      Note that not using any IP Address parameters in the INIT and INIT
      ACK is an alternative to make an association more likely to work
      across a NAT box.

Top      Up      ToC       Page 29 
   Cookie Preservative (9)

   The sender of the INIT shall use this parameter to suggest to the
   receiver of the INIT for a longer life-span of the State Cookie.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Type = 9             |          Length = 8           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Suggested Cookie Life-Span Increment (msec.)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Suggested Cookie Life-Span Increment: 32 bits (unsigned integer)

      This parameter indicates to the receiver how much increment in
      milliseconds the sender wishes the receiver to add to its default
      cookie life-span.

      This optional parameter should be added to the INIT chunk by the
      sender when it reattempts establishing an association with a peer
      to which its previous attempt of establishing the association
      failed due to a stale cookie operation error.  The receiver MAY
      choose to ignore the suggested cookie life-span increase for its
      own security reasons.

   Host Name Address (11)

   The sender of INIT uses this parameter to pass its Host Name (in
   place of its IP addresses) to its peer.  The peer is responsible for
   resolving the name.  Using this parameter might make it more likely
   for the association to work across a NAT box.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Type = 11            |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                          Host Name                            /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Host Name: variable length

      This field contains a host name in "host name syntax" per RFC 1123
      Section 2.1 [RFC1123].  The method for resolving the host name is
      out of scope of SCTP.

Top      Up      ToC       Page 30 
      Note: At least one null terminator is included in the Host Name
      string and must be included in the length.

   Supported Address Types (12)

   The sender of INIT uses this parameter to list all the address types
   it can support.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Type = 12            |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Address Type #1        |        Address Type #2        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            ......                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+

   Address Type: 16 bits (unsigned integer)

      This is filled with the type value of the corresponding address
      TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11).

3.3.3.  Initiation Acknowledgement (INIT ACK) (2)

   The INIT ACK chunk is used to acknowledge the initiation of an SCTP
   association.

   The parameter part of INIT ACK is formatted similarly to the INIT
   chunk.  It uses two extra variable parameters: The State Cookie and
   the Unrecognized Parameter:

Top      Up      ToC       Page 31 
   The format of the INIT ACK chunk is shown below:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 2    |  Chunk Flags  |      Chunk Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Initiate Tag                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Advertised Receiver Window Credit                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Number of Outbound Streams   |  Number of Inbound Streams    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Initial TSN                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /              Optional/Variable-Length Parameters              /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Initiate Tag: 32 bits (unsigned integer)

      The receiver of the INIT ACK records the value of the Initiate Tag
      parameter.  This value MUST be placed into the Verification Tag
      field of every SCTP packet that the INIT ACK receiver transmits
      within this association.

      The Initiate Tag MUST NOT take the value 0.  See Section 5.3.1 for
      more on the selection of the Initiate Tag value.

      If the value of the Initiate Tag in a received INIT ACK chunk is
      found to be 0, the receiver MUST destroy the association
      discarding its TCB.  The receiver MAY send an ABORT for debugging
      purpose.

   Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
   integer)

      This value represents the dedicated buffer space, in number of
      bytes, the sender of the INIT ACK has reserved in association with
      this window.  During the life of the association, this buffer
      space SHOULD NOT be lessened (i.e., dedicated buffers taken away
      from this association).

   Number of Outbound Streams (OS): 16 bits (unsigned integer)

      Defines the number of outbound streams the sender of this INIT ACK
      chunk wishes to create in this association.  The value of 0 MUST

Top      Up      ToC       Page 32 
      NOT be used, and the value MUST NOT be greater than the MIS value
      sent in the INIT chunk.

      Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
      destroy the association discarding its TCB.

   Number of Inbound Streams (MIS): 16 bits (unsigned integer)

      Defines the maximum number of streams the sender of this INIT ACK
      chunk allows the peer end to create in this association.  The
      value 0 MUST NOT be used.

      Note: There is no negotiation of the actual number of streams but
      instead the two endpoints will use the min(requested, offered).
      See Section 5.1.1 for details.

      Note: A receiver of an INIT ACK with the MIS value set to 0 SHOULD
      destroy the association discarding its TCB.

   Initial TSN (I-TSN): 32 bits (unsigned integer)

      Defines the initial TSN that the INIT ACK sender will use.  The
      valid range is from 0 to 4294967295.  This field MAY be set to the
      value of the Initiate Tag field.

         Fixed Parameters                     Status
         ----------------------------------------------
         Initiate Tag                        Mandatory
         Advertised Receiver Window Credit   Mandatory
         Number of Outbound Streams          Mandatory
         Number of Inbound Streams           Mandatory
         Initial TSN                         Mandatory

         Variable Parameters                  Status     Type Value
         -------------------------------------------------------------
         State Cookie                        Mandatory   7
         IPv4 Address (Note 1)               Optional    5
         IPv6 Address (Note 1)               Optional    6
         Unrecognized Parameter              Optional    8
         Reserved for ECN Capable (Note 2)   Optional    32768 (0x8000)
         Host Name Address (Note 3)          Optional    11

   Note 1: The INIT ACK chunks can contain any number of IP address
   parameters that can be IPv4 and/or IPv6 in any combination.

   Note 2: The ECN Capable field is reserved for future use of Explicit
   Congestion Notification.

Top      Up      ToC       Page 33 
   Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name
   Address parameter.  Moreover, the sender of the INIT ACK MUST NOT
   combine any other address types with the Host Name Address in the
   INIT ACK.  The receiver of the INIT ACK MUST ignore any other address
   types if the Host Name Address parameter is present.

   IMPLEMENTATION NOTE: An implementation MUST be prepared to receive an
   INIT ACK that is quite large (more than 1500 bytes) due to the
   variable size of the State Cookie AND the variable address list.  For
   example if a responder to the INIT has 1000 IPv4 addresses it wishes
   to send, it would need at least 8,000 bytes to encode this in the
   INIT ACK.

   IMPLEMENTATION NOTE: If an INIT ACK chunk is received with known
   parameters that are not optional parameters of the INIT ACK chunk,
   then the receiver SHOULD process the INIT ACK chunk and send back a
   COOKIE ECHO.  The receiver of the INIT ACK chunk MAY bundle an ERROR
   chunk with the COOKIE ECHO chunk.  However, restrictive
   implementations MAY send back an ABORT chunk in response to the INIT
   ACK chunk.

   In combination with the Source Port carried in the SCTP common
   header, each IP Address parameter in the INIT ACK indicates to the
   receiver of the INIT ACK a valid transport address supported by the
   sender of the INIT ACK for the life time of the association being
   initiated.

   If the INIT ACK contains at least one IP Address parameter, then the
   source address of the IP datagram containing the INIT ACK and any
   additional address(es) provided within the INIT ACK may be used as
   destinations by the receiver of the INIT ACK.  If the INIT ACK does
   not contain any IP Address parameters, the receiver of the INIT ACK
   MUST use the source address associated with the received IP datagram
   as its sole destination address for the association.

   The State Cookie and Unrecognized Parameters use the Type-Length-
   Value format as defined in Section 3.2.1 and are described below.
   The other fields are defined the same as their counterparts in the
   INIT chunk.

3.3.3.1.  Optional or Variable-Length Parameters

   State Cookie

   Parameter Type Value: 7

      Parameter Length: Variable size, depending on size of Cookie.

Top      Up      ToC       Page 34 
   Parameter Value:

      This parameter value MUST contain all the necessary state and
      parameter information required for the sender of this INIT ACK to
      create the association, along with a Message Authentication Code
      (MAC).  See Section 5.1.3 for details on State Cookie definition.

   Unrecognized Parameter:

      Parameter Type Value: 8

   Parameter Length: Variable size.

   Parameter Value:

      This parameter is returned to the originator of the INIT chunk
      when the INIT contains an unrecognized parameter that has a value
      that indicates it should be reported to the sender.  This
      parameter value field will contain unrecognized parameters copied
      from the INIT chunk complete with Parameter Type, Length, and
      Value fields.

3.3.4.  Selective Acknowledgement (SACK) (3)

   This chunk is sent to the peer endpoint to acknowledge received DATA
   chunks and to inform the peer endpoint of gaps in the received
   subsequences of DATA chunks as represented by their TSNs.

   The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver
   Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of
   Duplicate TSNs fields.

   By definition, the value of the Cumulative TSN Ack parameter is the
   last TSN received before a break in the sequence of received TSNs
   occurs; the next TSN value following this one has not yet been
   received at the endpoint sending the SACK.  This parameter therefore
   acknowledges receipt of all TSNs less than or equal to its value.

   The handling of a_rwnd by the receiver of the SACK is discussed in
   detail in Section 6.2.1.

   The SACK also contains zero or more Gap Ack Blocks.  Each Gap Ack
   Block acknowledges a subsequence of TSNs received following a break
   in the sequence of received TSNs.  By definition, all TSNs
   acknowledged by Gap Ack Blocks are greater than the value of the
   Cumulative TSN Ack.

Top      Up      ToC       Page 35 
        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 = 3    |Chunk  Flags   |      Chunk Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Cumulative TSN Ack                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Advertised Receiver Window Credit (a_rwnd)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Number of Gap Ack Blocks = N  |  Number of Duplicate TSNs = X |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Gap Ack Block #1 Start       |   Gap Ack Block #1 End        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                                                               /
       \                              ...                              \
       /                                                               /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Gap Ack Block #N Start      |  Gap Ack Block #N End         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Duplicate TSN 1                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                                                               /
       \                              ...                              \
       /                                                               /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Duplicate TSN X                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Chunk Flags: 8 bits

      Set to all '0's on transmit and ignored on receipt.

   Cumulative TSN Ack: 32 bits (unsigned integer)

      This parameter contains the TSN of the last DATA chunk received in
      sequence before a gap.  In the case where no DATA chunk has been
      received, this value is set to the peer's Initial TSN minus one.

   Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
   integer)

      This field indicates the updated receive buffer space in bytes of
      the sender of this SACK; see Section 6.2.1 for details.

   Number of Gap Ack Blocks: 16 bits (unsigned integer)

      Indicates the number of Gap Ack Blocks included in this SACK.

Top      Up      ToC       Page 36 
   Number of Duplicate TSNs: 16 bit

      This field contains the number of duplicate TSNs the endpoint has
      received.  Each duplicate TSN is listed following the Gap Ack
      Block list.

   Gap Ack Blocks:

      These fields contain the Gap Ack Blocks.  They are repeated for
      each Gap Ack Block up to the number of Gap Ack Blocks defined in
      the Number of Gap Ack Blocks field.  All DATA chunks with TSNs
      greater than or equal to (Cumulative TSN Ack + Gap Ack Block
      Start) and less than or equal to (Cumulative TSN Ack + Gap Ack
      Block End) of each Gap Ack Block are assumed to have been received
      correctly.

   Gap Ack Block Start: 16 bits (unsigned integer)

      Indicates the Start offset TSN for this Gap Ack Block.  To
      calculate the actual TSN number the Cumulative TSN Ack is added to
      this offset number.  This calculated TSN identifies the first TSN
      in this Gap Ack Block that has been received.

   Gap Ack Block End: 16 bits (unsigned integer)

      Indicates the End offset TSN for this Gap Ack Block.  To calculate
      the actual TSN number, the Cumulative TSN Ack is added to this
      offset number.  This calculated TSN identifies the TSN of the last
      DATA chunk received in this Gap Ack Block.

Top      Up      ToC       Page 37 
   For example, assume that the receiver has the following DATA chunks
   newly arrived at the time when it decides to send a Selective ACK,

                           ----------
                           | TSN=17 |
                           ----------
                           |        | <- still missing
                           ----------
                           | TSN=15 |
                           ----------
                           | TSN=14 |
                           ----------
                           |        | <- still missing
                           ----------
                           | TSN=12 |
                           ----------
                           | TSN=11 |
                           ----------
                           | TSN=10 |
                           ----------

   then the parameter part of the SACK MUST be constructed as follows
   (assuming the new a_rwnd is set to 4660 by the sender):

                     +--------------------------------+
                     |   Cumulative TSN Ack = 12      |
                     +--------------------------------+
                     |        a_rwnd = 4660           |
                     +----------------+---------------+
                     | num of block=2 | num of dup=0  |
                     +----------------+---------------+
                     |block #1 strt=2 |block #1 end=3 |
                     +----------------+---------------+
                     |block #2 strt=5 |block #2 end=5 |
                     +----------------+---------------+

   Duplicate TSN: 32 bits (unsigned integer)

      Indicates the number of times a TSN was received in duplicate
      since the last SACK was sent.  Every time a receiver gets a
      duplicate TSN (before sending the SACK), it adds it to the list of
      duplicates.  The duplicate count is reinitialized to zero after
      sending each SACK.

   For example, if a receiver were to get the TSN 19 three times it
   would list 19 twice in the outbound SACK.  After sending the SACK, if
   it received yet one more TSN 19 it would list 19 as a duplicate once
   in the next outgoing SACK.

Top      Up      ToC       Page 38 
3.3.5.  Heartbeat Request (HEARTBEAT) (4)

   An endpoint should send this chunk to its peer endpoint to probe the
   reachability of a particular destination transport address defined in
   the present association.

   The parameter field contains the Heartbeat Information, which is a
   variable-length opaque data structure understood only by the sender.

        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 = 4    | Chunk  Flags  |      Heartbeat Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /            Heartbeat Information TLV (Variable-Length)        /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Chunk Flags: 8 bits

      Set to 0 on transmit and ignored on receipt.

   Heartbeat Length: 16 bits (unsigned integer)

      Set to the size of the chunk in bytes, including the chunk header
      and the Heartbeat Information field.

   Heartbeat Information: variable length

      Defined as a variable-length parameter using the format described
      in Section 3.2.1, i.e.:

         Variable Parameters                  Status     Type Value
         -------------------------------------------------------------
         Heartbeat Info                       Mandatory   1

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Heartbeat Info Type=1      |         HB Info Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                  Sender-Specific Heartbeat Info               /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Sender-Specific Heartbeat Info field should normally include
      information about the sender's current time when this HEARTBEAT

Top      Up      ToC       Page 39 
      chunk is sent and the destination transport address to which this
      HEARTBEAT is sent (see Section 8.3).  This information is simply
      reflected back by the receiver in the HEARTBEAT ACK message (see
      Section 3.3.6).  Note also that the HEARTBEAT message is both for
      reachability checking and for path verification (see Section 5.4).
      When a HEARTBEAT chunk is being used for path verification
      purposes, it MUST hold a 64-bit random nonce.

3.3.6.  Heartbeat Acknowledgement (HEARTBEAT ACK) (5)

   An endpoint should send this chunk to its peer endpoint as a response
   to a HEARTBEAT chunk (see Section 8.3).  A HEARTBEAT ACK is always
   sent to the source IP address of the IP datagram containing the
   HEARTBEAT chunk to which this ack is responding.

   The parameter field contains a variable-length opaque data structure.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 5    | Chunk  Flags  |    Heartbeat Ack Length       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /            Heartbeat Information TLV (Variable-Length)        /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Chunk Flags: 8 bits

      Set to 0 on transmit and ignored on receipt.

   Heartbeat Ack Length: 16 bits (unsigned integer)

      Set to the size of the chunk in bytes, including the chunk header
      and the Heartbeat Information field.

   Heartbeat Information: variable length

      This field MUST contain the Heartbeat Information parameter of the
      Heartbeat Request to which this Heartbeat Acknowledgement is
      responding.

         Variable Parameters                  Status     Type Value
         -------------------------------------------------------------
         Heartbeat Info                       Mandatory   1

Top      Up      ToC       Page 40 
3.3.7.  Abort Association (ABORT) (6)

   The ABORT chunk is sent to the peer of an association to close the
   association.  The ABORT chunk may contain Cause Parameters to inform
   the receiver about the reason of the abort.  DATA chunks MUST NOT be
   bundled with ABORT.  Control chunks (except for INIT, INIT ACK, and
   SHUTDOWN COMPLETE) MAY be bundled with an ABORT, but they MUST be
   placed before the ABORT in the SCTP packet or they will be ignored by
   the receiver.

   If an endpoint receives an ABORT with a format error or no TCB is
   found, it MUST silently discard it.  Moreover, under any
   circumstances, an endpoint that receives an ABORT MUST NOT respond to
   that ABORT by sending an ABORT of its own.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 6    |Reserved     |T|           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                   zero or more Error Causes                   /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Chunk Flags: 8 bits

      Reserved: 7 bits

      Set to 0 on transmit and ignored on receipt.

      T bit: 1 bit

      The T bit is set to 0 if the sender filled in the Verification Tag
      expected by the peer.  If the Verification Tag is reflected, the T
      bit MUST be set to 1.  Reflecting means that the sent Verification
      Tag is the same as the received one.

      Note: Special rules apply to this chunk for verification; please
      see Section 8.5.1 for details.

   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.

      See Section 3.3.10 for Error Cause definitions.


Next RFC Part