rfc1707.txt

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

   The domain-specific part is variable length, and can be allocated in
   whatever way the authority identified by the AFI+IDI desires.

Network Layer Datagram

   The common architecture format for network layer datagrams is
   described below. The design is a balance between use on high
   performance networks and routers, and a desire to minimize the number
   of bits in the fixed header. Using the current state of processor
   technology as a reference, the fixed header is all loaded into CPU
   registers on the first memory cycle, and it all fits within the
   operation bandwidth. The header leaves the remaining data aligned on
   the header size (128 bits); with 64 bit addresses present and no
   options it leaves the transport header 256 bit aligned.

   On very slow and low performance networks, the fixed header is still
   fairly small, and could be further compressed by methods similar to
   those used with IP version 4 on links that consider every bit
   precious. In between, it fits nicely into ATM cells and radio
   packets, leaving sufficient space for the transport header and
   application data.
















McGovern & Ullmann                                              [Page 6]

RFC 1707                         CATNIP                     October 1994


      +---------------+---------------+-+-+-+-+-+-+-+-+---------------+
      |   NLPID (70)  |  Header Size  |D|S|R|M|E| MBZ | Time to Live  |
      +---------------+---------------+-+-+-+-+-+-+-+-+---------------+
      |                 Forward Cache Identifier                      |
      +---------------------------------------------------------------+
      |                      Datagram Length                          |
      +---------------------------------------------------------------+
      |     Transport Protocol        |          Checksum             |
      +---------------------------------------------------------------+
      |               Destination Address ...                         |
      +---------------------------------------------------------------+
      |               Source Address ...                              |
      +---------------------------------------------------------------+
      |               Options ...                                     |
      +---------------------------------------------------------------+


  NLPID: The first byte (the network layer protocol identifier in OSI)
         is an 8 bit constant 70 (hex). This corresponds to Internet
         Version 7.

  Header Length: The header length is a 8-bit count of the number of
         32-bit words in the header. This allows the header to
         be up to 1020 bytes in length.

  Flags: This byte is a small set of flags determining the datagram
         header format and the processing semantics. The last three bits
         are reserved, and must be set to zero. (Note that the
         corresponding bits in CLNP version 1 are 001, since this byte
         is the version field. This may be useful.)

  Destination Address Omitted: When the destination address omitted
         (DAO) flag is zero, the destination address is present as shown
         in the datagram format diagram. When a datagram is sent with
         an FCI that identifies the destination and the DAO flag is
         set, the address does not appear in the datagram.

  Source Address Omitted: The source address omitted (SAO) flag is zero
         when the source address is present in the datagram. When
         datagram is sent with an FCI that identifies the source and the
         SAO flag is set, the source address is omitted from the
         datagram.

  Report Fragmentation Done: When this bit (RFD) is set, an intermediate
         router that fragments the datagram (because it is larger than
         the next subnetwork MTU) should report the event with an ICMP
         Datagram Too Big message. (Unlike IP version 4, which uses DF
         for MTU discovery, the RFD flag allows the fragmented datagram



McGovern & Ullmann                                              [Page 7]

RFC 1707                         CATNIP                     October 1994


         to be delivered.)

  Mandatory Router Option: The mandatory router option (MRO) flag
         indicates that routers forwarding the datagram must look at the
         network header options.  If not set, an intermediate router
         should not look at the header options.  (But it may anyway;
         this is a necessary consequence of transparent network layer
         translation, which may occur anywhere.)

         The destination host, or an intermediate router doing
         translation, must look at the header options regardless of
         the setting of the MRO flag.

         A router doing fragmentation will normally only use the F
         flag in options to determine whether options should be copied
         within the fragmentation code path. (It might also recognize
         and elide null options.) If the MRO flag is not set, the router
         may not act on an option even though it copies it properly
         during fragmentation.

         If there are no options present, MRO should always be zero, so
         that routers can follow the no-option profile path in their
         implementation.  (Remember that the presence of options cannot
         be divided from the header length, since the addresses are
         variable length.)

  Error Report Suppression: The ERS flag is set to suppress the sending
         of error reports by any system (whether host or router)
         receiving or forwarding the datagram. The system may log the
         error, increment network management counters, and take any
         similar action, but ICMP error messages or CNLP error reports
         must not be sent.

         The ERS flag is normally set on ICMP messages and other network
         layer error reports. It does not suppress the normal response
         to ICMP queries or similar network layer queries (CNLP echo
         request).

         If both the RFD and ERS flags are set, the fragmentation report
         is sent.  (This definition allows a larger range of
         possibilities than simply over-riding the RFD flag would; a
         sender not desiring this behavior can see to it that RFD is
         clear.)

  Time To Live: The time to live is a 8-bit count, nominally in seconds.
         Each hop is required to decrement TTL by at least one. A hop
         that holds a datagram for an unusual amount of time (more than
         2 seconds, a typical example being a wait for a subnetwork



McGovern & Ullmann                                              [Page 8]

RFC 1707                         CATNIP                     October 1994


         connection establishment) should subtract the entire waiting
         time in seconds (rounded upward) from the TTL.

  Forward Cache Identifier: Each datagram carries a 32 bit field, called
         "forward cache identifier", that is updated (if the information
         is available) at each hop. This field's value is derived from
         ICMP messages sent back by the next hop router, a routing
         protocol (e.g., RAP), or some other method. The FCI is used to
         expedite routing decisions by preserving knowledge where
         possible between consecutive routers. It can also be used to
         make datagrams stay within reserved flows, circuits, and mobile
         host tunnels. If an FCI is not available, this field must be
         zero, the SAO and DAO flags must be clear, and both destination
         and source addresses must appear in the datagram.

  Datagram Length: The 32-bit length of the entire datagram in octets.
         A datagram can therefore be up to 4294967295 bytes in overall
         length.  Particular networks normally impose lower limits.

  Transport Protocol: The transport layer protocol. For example, TCP is
         6.

  Checksum: The checksum is a 16-bit checksum of the entire header,
         using the familiar algorithm used in IP version 4.

  Destination: The destination address, a count byte followed by the
         destination NSAP with the zero selector omitted. This field is
         present only if the DAO flag is zero. If the count field is not
         3 modulo 4 (the destination is not an integral multiple of
         32-bit words) zero bytes are added to pad to the next multiple
         of 32 bits. These pad bytes are not required to be ignored:
         routers may rely on them being zero.

  Source: The source address, in the same format as the destination.
         Present only if the SAO flag is zero. The source is padded in
         the same way as destination to arrive at a 32-bit boundary.

  Options: Options may follow. They are variable length, and always
         32-bit aligned. If the MRO flag in the header is not set,
         routers will usually not look at or take action on any option,
         regardless of the setting of the class field.

Multicasting

   The multicast-enable option permits multicast forwarding of the
   CATNIP datagram on subnetworks that directly support media layer
   multicasting. This is a vanishing species, even in 10 Mbps Ethernet,
   given the increasing prevalence of switching hubs. It also (perhaps



McGovern & Ullmann                                              [Page 9]

RFC 1707                         CATNIP                     October 1994


   more usefully) permits a router to forward the datagram on multiple
   paths when a multicast routing algorithm has established such paths.
   There is no option data.

   Note that there is no special address space for multicasting in the
   CATNIP. Multicast destination addresses can be allocated anywhere by
   any administration or authority. This supports a number of differing
   models of addressing. It does require that the transport layer
   protocol know that the destination is multicast; this is desirable in
   any case. (For example, the transport will probably want to set the
   ERS flag.)

   On an IEEE 802.x (ISO 8802.x) type media, the last 23 bits of the
   address (not including the 0 selector) are used in combination with
   the multicast group address assigned to the Internet to form the
   media address when forwarding a datagram with the multicast enable
   option from a router to an attached network provided that the
   datagram was not received on that network with either multicast or
   broadcast media addressing. A host may send a multicast datagram
   either to the media multicast address (the IP catenet model,) or
   media unicast to a router which is expected to repeat it to the
   multicast address within the entire level I area or to repeat copies
   to the appropriate end systems within the area on non-broadcast media
   (the more general CLNP model.)

Network Layer Translation

   The objective of translation is to be able to upgrade systems, both
   hosts and routers, in whatever order desired by their owners.
   Organizations must be able to upgrade any given system without
   reconfiguration or modification of any other, and existing hosts must
   be able to interoperate essentially forever. (Non-CATNIP routers will
   probably be effectively eliminated at some point, except where they
   exist in their own remote or isolated corners.)

   Each CATNIP system, whether host or router, must be able to recognize
   adjacent systems in the topology that are (only) IP version 4, CLNP,
   or IPX and call the appropriate translation routine just before
   sending the datagram.

OSI CNLP

   The translation between CLNP and the CATNIP compressed form of the
   datagrams is the simplest case for CATNIP, since the addresses are
   the same and need not be extended. The resulting CATNIP datagrams may
   omit the source and destination addresses as explained previously,
   and may be mixed with uncompressed datagrams on the same subnetwork
   link. Alternatively, a subnetwork may operate entirely in the CATNIP,



McGovern & Ullmann                                             [Page 10]

RFC 1707                         CATNIP                     October 1994


   converting all transit traffic to CATNIP datagrams, even if FCIs that
   would make the compression effective are not available.

   Similarly, all network datagram formats with CATNIP mappings may be
   compressed into the common form, providing a uniform transit network
   service, with common routing protocols (such as IS-IS).

Internet Protocol

   All existing version 4 numbers are defined as belonging to the
   Internet by using a new AFI, to be assigned to IANA by the ISO. This
   document uses 192 at present for clarity in examples; it is to be
   replaced with the assigned AFI. The AFI specifies that the IDI is two
   bytes long, containing an administrative domain number.

   The AD (Administrative Domain), identifies an administration which
   may be an international authority (such as the existing InterNIC), a
   national administration, or a large multi-organization (e.g., a
   government). The idea is that there should not be more than a few
   hundred of these at first, and eventually thousands or tens of
   thousands at most.

   AD numbers are assigned by IANA. Initially, the only assignment is
   the number 0.0, assigned to the InterNIC, encompassing the entire
   existing version 4 Internet.

   The mapping from/to version 4 IP addresses:

      +----------+----------+---------------+---------------------+
      |  length  |   AFI    |  IDI ...      | DSP ...             |
      +----------+----------+---------------+---------------------+
      |     7    |   192    |  AD number    | version 4 address   |
      +----------+----------+---------------+---------------------+