rfc1561.txt

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

                        +---+---+---+
                        | F | M | E |
                        | P | F | R |
                        +---+---+---+

   The Fragmentation Permitted (FP) flag, when set to a value of one
   (1), is semantically equivalent to the "may fragment" value of the
   Don't Fragment field of IP; similarly, when set to zero (0), the
   Fragmentation Permitted flag is semantically equivalent to the "Don't
   Fragment" value of the Don't Fragment Flag of IP.

   [Note: If the Fragmentation Permitted field is set to the value 0,
   then the Data Unit Identifier, Fragment Offset, and Total Length
   fields are not present. This denotes a single fragment datagram. In
   such datagrams, the Fragment Length field contains the total length
   of the datagram.]

   The More Fragments flag of CLNP is semantically and syntactically the
   same as the More Fragments flag of IP; a value of one (1) indicates
   that more segments/fragments are forthcoming; a value of zero (0)
   indicates that the last octet of the original packet is present in
   this segment.

   The Error Report (ER) flag is used to suppress the generation of an
   error message by a host/router that detects an error during the
   processing of a CLNP datagram; a value of one (1) indicates that the
   host that originated this datagram thinks error reports are useful,
   and would dearly love to receive one if a host/router finds it
   necessary to discard its datagram(s).













Piscitello                                                      [Page 7]

RFC 1561               CLNP in TUBA Environments           December 1993


4.6  Type field

   The type field distinguishes data CLNP packets from Error Reports
   from Echo packets. The following values of the type field apply:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |   flags   | 1 | 1 | 1 | 0 | 0 |  => Encoding of Type = data packet
   +---+---+---+---+---+---+---+---+
   |   flags   | 0 | 0 | 0 | 0 | 1 |  => Encoding of Type = error report
   +---+---+---+---+---+---+---+---+
   |   flags   | 1 | 1 | 1 | 1 | 0 |  => Encoding of Type = echo request
   +---+---+---+---+---+---+---+---+
   |   flags   | 1 | 1 | 1 | 1 | 1 |  => Encoding of Type = echo reply
   +---+---+---+---+---+---+---+---+

   Error Report packets are described in Section 5.

   Echo packets and their use are described in RFC 1139 [9].

4.7  Fragment Length

   Like the Total Length of the IP header, the Fragment length field
   contains the length in octets of the fragment (i.e., this datagram)
   including both header and data.

   [Note: CLNP also may also have a Total Length field, that contains
   the length of the original datagram; i.e., the sum of the length of
   the CLNP header plus the length of the data submitted by the higher
   level protocol, e.g., TCP or UDP. See Section 4.12.]

4.8  Checksum

   A checksum is computed on the header only. It MUST be verified at
   each host/router that processes the packet; if header fields are
   changed during processing (e.g., the Lifetime), the checksum is
   modified. If the checksum is not used, this field MUST be coded with
   a value of zero (0). See Appendix A for algorithms used in the
   computation and adjustment of the checksum. Readers are encouraged to
   see [10] for a description of an efficient implementation of the
   checksum algorithm.

4.9  Addressing

   CLNP uses OSI network service access point addresses (NSAPAs); NSAPAs
   serve the same identification and location functions as an IP
   address, plus the protocol selector value encoded in the IPv4
   datagram header, and  with additional hierarchy.  General purpose



Piscitello                                                      [Page 8]

RFC 1561               CLNP in TUBA Environments           December 1993


   CLNP implementations MUST handle NSAP addresses of variable length up
   to 20 octets, as defined in ISO/IEC 8348 [11]. TUBA implementations,
   especially routers, MUST accommodate these as well. Thus, for
   compatibility and interoperability with OSI use of CLNP, the initial
   octet of the Destination Address is assumed to be an Authority and
   Format Indicator, as defined in ISO/IEC 8348. NSAP addresses may be
   between 8 and 20 octets long (inclusive).

   TUBA implementations MUST support both ANSI and GOSIP style
   addresses; these are described in RFC 1237 [12], and illustrated in
   Figure 4-2.  RFC 1237 describes the ANSI/GOSIP initial domain parts
   as well as the format and composition of the domain specific part. It
   is further recommended that TUBA implementations support the
   assignment of system identifiers for TUBA/CLNP hosts defined in [13]
   for the purposes of host address autoconfiguration as described in
   [14]. Additional considerations specific to the interpretation and
   encoding of the selector part are described in sections 4.9.2 and
   4.9.4.

            +-------------+
            | <-- IDP --> |
            +----+--------+----------------------------------+
            |AFI |  IDI   |           <-- DSP -->            |
            +----+--------+----+---+-----+----+-----+---+----+
            | 47 |  0005  |DFI |AA |Rsvd | RD |Area |ID |Sel |
            +----+--------+----+---+-----+----+-----+---+----+
     octets | 1  |   2    | 1  | 3 |  2  | 2  | 2   | 6 | 1  |
            +----+--------+----+---+-----+----+-----+---+----+

                 Figure 4-2 (a): GOSIP Version 2 NSAP structure.

            +-------------+
            |<-- IDP -->  |
            +----+--------+----------------------------------+
            |AFI |  IDI   |          <-- DSP -->             |
            +----+--------+----+---+-----+----+-----+---+----+
            | 39 |  840   |DFI |ORG|Rsvd | RD |Area |ID |Sel |
            +----+--------+----+---+-----+----+-----+---+----+
     octets | 1  |   2    | 1  | 3 |  2  | 2  |  2  | 6 | 1  |
            +----+--------+----+---+-----+----+-----+---+----+

             Figure 4-2 (b): ANSI NSAP address format for DCC=840









Piscitello                                                      [Page 9]

RFC 1561               CLNP in TUBA Environments           December 1993


        Definitions:
                     IDP   Initial Domain Part
                     AFI   Authority and Format Identifier
                     IDI   Initial Domain Identifier
                     DSP   Domain Specific Part
                     DFI   DSP Format Identifier
                     AA    Administration Authority
                     ORG   Organization Name (numeric form)
                     Rsvd  Reserved
                     RD    Routing Domain Identifier
                     Area  Area Identifier
                     ID    System Identifier
                     Sel   NSAP Selector

4.9.1  Destination Address Length Indicator

   This field indicates the length, in octets, of the Destination
   Address.

4.9.2  Destination Address

   This field contains an OSI NSAP address, as described in Section 4.9.
   It MUST always contain the address of the final destination. (This is
   true even for packets containing a source route option, see Section
   4.13.4).

   The final octet of the destination address MUST always contain the
   value of the PROTO field, as defined in IP.  The 8-bit PROTO field
   indicates the next level protocol used in the data portion of the
   CLNP datagram.  The values for various protocols are specified in
   "Assigned Numbers" [15]. For the PROTO field, the value of zero (0)
   is reserved.

   TUBA implementations that support TCP/UDP as well as OSI MUST use the
   protocol value (1Dh, Internet decimal 29) reserved for ISO transport
   protocol class 4.

4.9.3  Source Address Length Indicator

   This field indicates the length, in octets, of the Source Address.

4.9.4  Source Address

   This field contains an OSI NSAP address, as described in Section 4.9.

   The final octet of the source address is reserved. It MAY be set to
   the protocol field value on transmission, and shall be ignored on
   reception (the value of zero MUST not be used).



Piscitello                                                     [Page 10]

RFC 1561               CLNP in TUBA Environments           December 1993


4.10  Data Unit Identifier

   Like the Identification field of IP, this 16-bit field is used to
   distinguish segments of the same (original) packet for the purposes
   of reassembly. This field is present when the fragmentation permitted
   flag is set to one.

4.11  Fragment Offset

   Like the Fragment Offset of IP, this 16-bit is used to identify the
   relative octet position of the data in this fragment with respect to
   the start of the data submitted to CLNP; i.e., it indicates where in
   the original datagram this fragment belongs.  The offset is measured
   in octets; the value of this field shall always be a multiple of
   eight (8). This field is present when the fragmentation permitted
   flag is set to one.

4.12  Total Length

   The total length of the CLNP packet in octets is determined by the
   originator and placed in the Total Length field of the header. The
   Total Length field specifies the entire length of the original
   datagram, including both the header and data. This field MUST NOT be
   changed in any fragment of the original packet for the duration of
   the packet lifetime. This field is present when the fragmentation
   permitted flag is set to one.

4.13  Options

   All CLNP options are "triplets" of the form <parameter code>,
   <parameter length>, and <parameter value>.  Both the parameter code
   and length fields are always one octet long; the length parameter
   value, in octets, is indicated in the parameter length field. The
   following options are defined for CLNP for TUBA.

4.13.1  Security

   The value of the parameter code field is binary 1100 0101. The length
   field MUST be set to the length of a Basic (and Extended) Security IP
   option(s) as identified in RFC 1108 [16], plus 1.  Octet 1 of the
   security parameter value field -- the CLNP Security Format Code -- is
   set to a binary value 0100 0000, indicating that the remaining octets
   of the security field contain either the Basic or Basic and Extended
   Security options as identified in RFC 1108. This encoding points to
   the administration of the source address (e.g., ISOC) as the
   administration of the security option; it is thus distinguished from
   the globally unique format whose definition is reserved for OSI use.
   Implementations wishing to use a security option MUST examine the



Piscitello                                                     [Page 11]

RFC 1561               CLNP in TUBA Environments           December 1993


   PROTO field in the source address; if the value of PROTO indicates
   the CLNP client is TCP or UDP, the security option described in RFC
   1108 is used.

   [Note: If IP options change, TUBA implementations MUST follow the new
   recommendations. This RFC, or revisions thereof, must document the
   new recommendations to assure compatibility.]

   The formats of the Security option, encoded as a CLNP option, is as
   follows. The CLNP option will be used to convey the Basic and
   Extended Security options as sub-options; i.e., the exact encoding of
   the Basic/Extended Security IP Option is carried in a single CLNP
   Security Option, with the length of the CLNP Security option
   reflecting the sum of the lengths of the Basic and Extended Security
   IP Option.

   +--------+--------+--------+--------+--------+---//----+-
   |11000100|XXXXXXXX|01000000|10000010|YYYYYYYY|         |      ...
   +--------+--------+--------+--------+--------+---//----+----
    CLNP       CLNP     CLNP     BASIC   BASIC    BASIC
    OPTION    OPTION   FORMAT  SECURITY  OPTION   OPTION
    TYPE      LENGTH    CODE    TYPE     LENGTH   VALUE
    (197)                       (130)

                          ---+------------+------------+----//-------+
                     ...     |  10000101  |  000LLLLL  |             |
                        -----+------------+------------+----//-------+
                                EXTENDED     EXTENDED    EXTENDED OPTION
                                OPTION       OPTION          VALUE
                               TYPE (133)    LENGTH

   The syntax, semantics and  processing of the Basic and Extended IP
   Security Options are defined in RFC 1108.

4.13.2  Type of Service

   [Note: Early drafts recommended the use of IP Type of Service as
   specified in RFC 1349. There now appears to be a broad consensus that
   this encoding is insufficient, and there is renewed interest in
   exploring the utility of the "congestion experienced" flag available
   in the CLNP QOS Maintenance option. This RFC thus recommends the use
   of the QOS Maintenance option native to CLNP.]

   The Quality of Service Maintenance option allows the originator of a
   CLNP datagram to convey information about the quality of service
   requested by the originating upper layer process. Routers MAY use
   this information as an aid in selecting a route when more than one
   route satisfying other routing criteria is available and the



Piscitello                                                     [Page 12]

RFC 1561               CLNP in TUBA Environments           December 1993


   available routes are know to differ with respect to the following
   qualities of service: ability to preserve sequence, transit delay,
   cost, residual error probability. Through this option, a router may
   also indicate that it is experiencing congestion.

   The encoding of this option is as follows:

      +-----------+-----------+----------+
      | 1100 0011 | 0000 0001 | 110ABCDE |
      +-----------+-----------+----------+
       CLNP QOS     OPTION      QOS FLAGS
       TYPE (195)   LENGTH

   The value of the parameter code field MUST be set to a value of
   binary 1100 0011 (the CLNP Quality of Service Option Code point).
   The length field MUST be set to one (1).

   Bits 8-6 MUST be set as indicated in the figure. The flags "ABCDE"
   are interpreted as follows:

         A=1  choose path that maintains sequence over
              one that minimizes transit delay
         A=0  choose path that minimizes transit delay over
              one that maintains sequence