rfc2960.txt

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

      a user message.




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


   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 no user data field will
      have Length set to 16 (indicating 16 bytes).

   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.

      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.




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


   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 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).

      The value 0 indicates 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 a SCTP association between two
   endpoints.  The format of the INIT 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 = 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.





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


         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.

   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.

   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.





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


      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.

   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.




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


   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.

   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 bit (unsigned integer)

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

      Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC2373]
      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 lifetime 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.





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


      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 s