rfc2960.txt

<VC++网络游戏建摸与实现>源代码

      identify the association to which this packet belongs.

   Destination Port Number: 16 bits (unsigned integer)

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

   Verification Tag: 32 bits (unsigned integer)

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

      -  A packet containing an INIT chunk MUST have a zero Verification
         Tag.
      -  A packet containing a SHUTDOWN-COMPLETE chunk with the T-bit
         set MUST have the Verification Tag copied from the packet with
         the SHUTDOWN-ACK chunk.
      -  A packet containing an ABORT chunk may have the verification
         tag copied from the packet which caused the ABORT to be sent.
         For details see Section 8.4 and 8.5.

   An INIT chunk MUST be the only chunk in the SCTP packet carrying it.






Stewart, et al.             Standards Track                    [Page 17]

RFC 2960          Stream Control Transmission Protocol      October 2000


   Checksum: 32 bits (unsigned integer)

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

3.2  Chunk Field Descriptions

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

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

   Chunk Type: 8 bits (unsigned integer)

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

   The values of Chunk Types are defined as follows:

   ID Value    Chunk Type
   -----       ----------
   0          - Payload Data (DATA)
   1          - Initiation (INIT)
   2          - Initiation Acknowledgement (INIT ACK)
   3          - Selective Acknowledgement (SACK)
   4          - Heartbeat Request (HEARTBEAT)
   5          - Heartbeat Acknowledgement (HEARTBEAT ACK)
   6          - Abort (ABORT)
   7          - Shutdown (SHUTDOWN)
   8          - Shutdown Acknowledgement (SHUTDOWN ACK)
   9          - Operation Error (ERROR)
   10         - State Cookie (COOKIE ECHO)
   11         - Cookie Acknowledgement (COOKIE ACK)
   12         - Reserved for Explicit Congestion Notification Echo (ECNE)
   13         - Reserved for Congestion Window Reduced (CWR)



Stewart, et al.             Standards Track                    [Page 18]

RFC 2960          Stream Control Transmission Protocol      October 2000


   14         - Shutdown Complete (SHUTDOWN COMPLETE)
   15 to 62   - reserved by IETF
   63         - IETF-defined Chunk Extensions
   64 to 126  - reserved by IETF
   127        - IETF-defined Chunk Extensions
   128 to 190 - reserved by IETF
   191        - IETF-defined Chunk Extensions
   192 to 254 - reserved by IETF
   255        - IETF-defined Chunk Extensions

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

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

   01 - Stop processing this SCTP packet and discard it, do not process
        any further chunks within it, and report the unrecognized
        parameter in an 'Unrecognized Parameter Type' (in either an
        ERROR or in the INIT ACK).

   10 - Skip this chunk and continue processing.

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

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

   Chunk Flags: 8 bits

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

   Chunk Length: 16 bits (unsigned integer)

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








Stewart, et al.             Standards Track                    [Page 19]

RFC 2960          Stream Control Transmission Protocol      October 2000


   Chunk Value: variable length

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

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

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

3.2.1  Optional/Variable-length Parameter Format

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

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

   Chunk Parameter Type:  16 bits (unsigned integer)

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

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









Stewart, et al.             Standards Track                    [Page 20]

RFC 2960          Stream Control Transmission Protocol      October 2000


   Chunk Parameter Length:  16 bits (unsigned integer)

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

   Chunk Parameter Value: variable-length.

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

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

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

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

   01 - Stop processing this SCTP packet and discard it, do not process
        any further chunks within it, and report the unrecognized
        parameter in an 'Unrecognized Parameter Type' (in either an
        ERROR or in the INIT ACK).

   10 - Skip this parameter and continue processing.

   11 - Skip this parameter and continue processing but report the
        unrecognized parameter in an 'Unrecognized Parameter Type' (in
        either an ERROR or in the INIT ACK).

   The actual SCTP parameters are defined in the specific SCTP chunk
   sections.  The rules for IETF-defined parameter extensions are
   defined in Section 13.2.

3.3 SCTP Chunk Definitions

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





Stewart, et al.             Standards Track                    [Page 21]

RFC 2960          Stream Control Transmission Protocol      October 2000


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 re-assembly (if necessary), unordered DATA chunks MUST be
      dispatched to the upper layer by the receiver without any attempt
      to re-order.

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

   B bit: 1 bit

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

   E bit:  1 bit

      The (E)nding fragment bit, if set, indicates the last fragment of