rfc1561.txt

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

         B=1  congestion experienced
         B=0  no congestion to report
         C=1  choose path that minimizes transit delay over
              over low cost
         C=0  choose low cost over path that
              minimizes transit delay
         D=1  choose pathe with low residual error probability over
              one that minimizes transit delay
         D=0  choose path that minimizes transit delay over
              one with low residual error probability
         E=1  choose path with low residual error probability over
              low cost
         E=0  choose path with low cost over one with low
              residual error probability

4.13.3  Padding

   The padding field is used to lengthen the packet header to a
   convenient size. The parameter code field MUST be set to a value of
   binary 1100 1100. The value of the  parameter length field is
   variable. The parameter value MAY contain any value; the contents of
   padding fields MUST be ignored by the receiver.





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


      +----------+----------+-----------+
      | 11001100 | LLLLLLLL | VVVV VVVV |
      +----------+----------+-----------+

4.13.4  Source Routing

   Like the strict source route option of IP, the Complete Source Route
   option of CLNP is used to specify the exact and entire route an
   internet datagram MUST take. Similarly, the Partial Source Route
   option of CLNP provides the equivalent of the loose source route
   option of IP; i.e., a means for the source of an internet datagram to
   supply (some) routing information to be used by gateways in
   forwarding the internet datagram towards its destination. The
   identifiers encoded in this option are network entity titles, which
   are semantically and syntactically the same as NSAPAs and which can
   be used to unambiguously identify a network entity in an intermediate
   system (router).

   The parameter code for Source Routing is binary 1100 1000. The length
   of the source routing parameter value is variable.

   The first octet of the parameter value is a type code, indicating
   Complete Source Routing (binary 0000 0001) or Partial Source Routing
   (binary 0000 0000). The second octet identifies the offset of the
   next network entity title to be processed in the list, relative to
   the start of the parameter (i.e., a value of 3 is used to identify
   the first address in the list). The offset value is modified by each
   router using a complete source route or by each listed router using a
   partial source route to point to the next NET.

   The third octet begins the list of network entity titles. Only the
   NETs of intermediate systems are included in the list; the source and
   destination addresses shall not be included.  The list consists of
   variable length network entity title entries; the first octet of each
   entry gives the length of the network entity title that comprises the
   remainder of the entry.

4.13.5  Record Route

   Like the IP record route option, the Record route option of CLNP is
   used to trace the route a CLNP datagram takes.  A recorded route
   consists of a list of network entity titles (see Source Routing). The
   list is constructed as the CLNP datagram is forwarded along a path
   towards its final destination. Only titles of intermediate systems
   (routers) that processed the datagram are included in the recorded
   route; the network entity title of the originator of the datagram
   SHALL NOT be recorded in the list.




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


   The parameter code for Record Route is binary 1100 1011. The length
   of the record route parameter value is variable.

   The first octet of the parameter value is a type code, indicating
   Complete Recording of Route (0000 0001) or Partial Recording of Route
   (0000 0000). When complete recording of route is selected, reassembly
   at intermediate systems MAY be performed only when all fragments of a
   given datagram followed the same route; partial recording of route
   eliminates or "loosens" this constraint.

   The second octet identifies the offset where the next network entity
   title entry (see Source Routing) MAY be recorded (i.e., the end of
   the current list), relative to the start of the parameter.  A value
   of 3 is used to identify the initial recording position. The process
   of recording a network entity title entry is as follows. A router
   adds the length of its network entity title entry to the value of
   record route offset and compares this new value to the record route
   list length indicator; if the value does not exceed the length of the
   list, entity title entry is recorded, and the offset value is
   incremented by the value of the length of the network entity title
   entry. Otherwise, the recording of route is terminated, and the
   router MUST not record its network entity title in the option. If
   recording of route has been terminated, this (second) octet has a
   value 255.

   The third octet begins the list of network entity titles.

4.13.6  Timestamp

   [Note: There is no timestamp option in edition 1 of ISO/IEC 8473, but
   the option has been proposed and submitted to ISO/IEC JTC1/SC6.]

   The parameter code value 1110 1110 is used to identify the Timestamp
   option; the syntax and semantics of Timestamp are identical to that
   defined in IP.

   The Timestamp Option is defined in STD 5, RFC 791. The CLNP parameter
   code 1110 1110 is used rather than the option type code 68 to
   identify the Timestamp option, and  the parameter value conveys the
   option length. Octet 1 of the Timestamp parameter value shall be
   encoded as the pointer (octet 3 of IP Timestamp); octet 2 of the
   parameter value shall be encoded as the overflow/format octet (octet
   4 of IP Timestamp); the remaining octets shall be used to encode the
   timestamp list. The size is fixed by the source, and cannot be
   changed to accommodate additional timestamp information.






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


        +--------+--------+--------+--------+
        |11101110| length | pointer|oflw|flg|
        +--------+--------+--------+--------+
        |         network entity title      |
        +--------+--------+--------+--------+
        |             timestamp             |
        +--------+--------+--------+--------+
        |                 .                 |
                          .

5.  Error Reporting and Control Message Handling

   CLNP and IP  differ in the way in which errors are reported to hosts.
   In IP environments, the Internet Control Message Protocol (ICMP, [7])
   is used to return (error) messages to hosts that originate packets
   that cannot be processed. ICMP messages are transmitted as user data
   in IP datagrams. Unreachable destinations, incorrectly composed IP
   datagram headers, IP datagram discards due to congestion, and
   lifetime/reassembly time exceeded are reported; the complete internet
   header that caused the error plus (at least) 8 octets of the segment
   contained in that IP datagram are returned to the sender as part of
   the ICMP error message. For certain errors, e.g., incorrectly
   composed IP datagram headers, the specific octet which caused the
   problem is identified.

   In CLNP environments, an unique message type, the Error Report type,
   is used in the network layer protocol header to distinguish Error
   Reports from CLNP datagrams. CLNP Error Reports are generated on
   detection of the same types of errors as with ICMP.  Like ICMP error
   messages, the complete CLNP header that caused the error is returned
   to the sender in the data portion of the Error Report.
   Implementations SHOULD return at least 8 octets of the datagram
   contained in the CLNP datagram to the sender of the original CLNP
   datagram. Here too, for certain errors, the specific octet which
   caused the problem is identified.

   A summary of the contents of the CLNP Error Report, as it is proposed
   for use in TUBA environments, is illustrated in Figure 5-1:













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


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        ........Data Link Header........       | NLP ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Header Length  |     Version   | Lifetime (TTL)| 000 | Type=ER |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TOTAL Length of Error Report |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Dest Addr Len |               Destination Address...          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Destination Address...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Destination Address...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Destination Address...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Destination Address...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PROTO field   | Src  Addr Len |  Source  Address...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Source Address...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Source Address...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Source Address...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Source Address...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       ... Source Address      | Reason for Discard (type/len) |
   |                               |   1100 0001   | 0000 0010     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Reason for Discard        |    Options...                 |
   |   code        |   pointer     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Options                             |
   :                                                               :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Data                               |
   :                                                               :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Note that each tick mark represents one bit position.

                      Figure 5-1. Error Report Format




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


5.1  Rules for processing an Error Report

   The following is a summary of the rules for processing an Error
   Report:

         * An Error Report is not generated to report a problem
           encountered while processing an Error Report.

         * Error Reports MAY NOT be fragmented (hence, the
           fragmentation part is absent).

         * The Reason for Discard Code field is populated with one of
           the values from Table 5-1.

         * The Pointer field is populated with number of the first
           octet of the field that caused the Error Report to be
           generated. If it is not possible to identify the offending
           octet, this field MUST be zeroed.

         * If the Priority or Type of Service option is present in the
           errored datagram, the Error Report MUST specify the same
           option, using the value specified in the original datagram.

         * If the Security option is present in the errored datagram,
           the Error Report MUST specify the same option, using the
           value specified in the original datagram; if the Security
           option is not supported by the intermediate system, no Error
           Report is to be generated (i.e., "silently discard" the
           received datagram).

         * If the Complete Source Route option is specified in the
           errored datagram, the Error Report MUST compose a reverse of
           that route, and return the datagram along the same path.


















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


5.2  Comparison of ICMP and CLNP Error Messages

   Table 5-1 provides a loose comparison of ICMP message types and codes
   to CLNP Error Type Codes (values in Internet decimal):

 CLNP Error Type  Codes            | ICMP Message           (Type, Code)
 ----------------------------------|------------------------------------
 Reason not specified          (0) | Parameter Problem           (12, 0)
 Protocol Procedure Error      (1) | Parameter Problem           (12, 0)
 Incorrect Checksum            (2) | Parameter Problem           (12, 0)
 PDU Discarded--Congestion     (3) | Source Quench                (4, 0)
 Header Syntax Error           (4) | Parameter problem           (12, 0)
 Need to Fragment could not    (5) | Frag needed, DF set          (3, 4)
 Incomplete PDU received       (6) | Parameter Problem           (12, 0)
 Duplicate Option              (7) | Parameter Problem           (12, 0)
 Destination Unreachable     (128) | Dest Unreachable,Net unknown (3, 0)
 Destination Unknown         (129) | Dest Unreachable,host unknown(3, 1)
 Source Routing Error        (144) | Source Route failed          (3, 5)
 Source Route Syntax Error   (145) | Source Route failed          (3, 5)
 Unknown Address in Src Route(146) | Source Route failed          (3, 5)
 Path not acceptable         (147) | Source Route failed          (3, 5)
 Lifetime expired            (160) | TTL exceeded                (11, 0)
 Reassembly Lifetime Expired (161) | Reassembly time exceeded    (11, 1)
 Unsupported Option          (176) | Parameter Problem           (12, 0)
 Unsupported Protocol Version(177) | Parameter problem           (12, 0)
 Unsupported Security Option (178) | Parameter problem           (12, 0)
 Unsupported Src Rte Option  (179) | Parameter problem           (12, 0)
 Unsupported Rcrd Rte        (180) | Parameter problem           (12, 0)
 Reassembly interference     (192) | Reassembly time exceeded    (11, 1)

    Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages

 Note 1: The current accepted practice for IP is that source quench
         should not be used; if it is used, implementations MUST
         not return a source quench packet for every relevant packet.
         TUBA/CLNP implementations are encouraged to adhere to these
         guidelines.

 Note 2: There are no corresponding CLNP Error Report Codes for the