rfc2332.txt

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

     internetwork layer addresses of the stations it serves. The NBMA
     addresses of the stations served by the NHS may be learned via NHRP
     Registration packets.

     If a served NHC is attached to several subnetworks, the
     router/route-server coresident with the serving NHS may also need
     to be configured to advertise routing information to such NHCs.

     If an NHS acts as an egress router for stations connected to other
     subnetworks than the NBMA subnetwork, the NHS must, in addition to
     the above, be configured to exchange routing information between
     the NBMA subnetwork and these other subnetworks.

     In all cases, routing information is exchanged using conventional
     intra-domain and/or inter-domain routing protocols.

5. NHRP Packet Formats

   This section describes the format of NHRP packets.  In the following,
   unless otherwise stated explicitly, the unqualified term "request"
   refers generically to any of the NHRP packet types which are
   "requests".  Further, unless otherwise stated explicitly, the
   unqualified term "reply" refers generically to any of the NHRP packet
   types which are "replies".

   An NHRP packet consists of a Fixed Part, a Mandatory Part, and an
   Extensions Part.  The Fixed Part is common to all NHRP packet types.
   The Mandatory Part MUST be present, but varies depending on packet
   type.  The Extensions Part also varies depending on packet type, and
   need not be present.

   The length of the Fixed Part is fixed at 20 octets.  The length of
   the Mandatory Part is determined by the contents of the extensions
   offset field (ar$extoff).  If ar$extoff=0x0 then the mandatory part
   length is equal to total packet length (ar$pktsz) minus 20 otherwise
   the mandatory part length is equal to ar$extoff minus 20.  The length



Luciani, et. al.            Standards Track                    [Page 11]

RFC 2332                       NBMA NHRP                      April 1998


   of the Extensions Part is implied by ar$pktsz minus ar$extoff.  NHSs
   may increase the size of an NHRP packet as a result of extension
   processing, but not beyond the offered maximum packet size of the
   NBMA network.

   NHRP packets are actually members of a wider class of address mapping
   and management protocols being developed by the IETF. A specific
   encapsulation, based on the native formats used on the particular
   NBMA network over which NHRP is carried, indicates the generic IETF
   mapping and management protocol. For example, SMDS networks always
   use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet
   is preceded by the following LLC/SNAP encapsulation:

   [0xAA-AA-03] [0x00-00-5E] [0x00-03]

   The first three octets are LLC, indicating that SNAP follows.  The
   SNAP OUI portion is the IANA's OUI, and the SNAP PID portion
   identifies the mapping and management protocol. A field in the Fixed
   Header following the encapsulation indicates that it is NHRP.

   ATM uses either LLC/SNAP encapsulation of each packet (including
   NHRP), or uses no encapsulation on VCs dedicated to a single protocol
   (see [7]).  Frame Relay and X.25 both use NLPID/SNAP encapsulation or
   identification of NHRP, using a NLPID of 0x0080 and the same SNAP
   contents as above (see [8], [9]).

   Fields marked "unused" MUST be set to zero on transmission, and
   ignored on receipt.

   Most packet types (ar$op.type) have both internetwork layer
   protocol-independent fields and protocol-specific fields. The
   protocol type/snap fields (ar$pro.type/snap) qualify the format of
   the protocol-specific fields.

5.1 NHRP Fixed Header

   The Fixed Part of the NHRP packet contains those elements of the NHRP
   packet which are always present and do not vary in size with the type
   of packet.












Luciani, et. al.            Standards Track                    [Page 12]

RFC 2332                       NBMA NHRP                      April 1998



    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ar$afn             |          ar$pro.type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ar$pro.snap                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ar$pro.snap  |   ar$hopcnt   |            ar$pktsz           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           ar$chksum           |            ar$extoff          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ar$op.version |   ar$op.type  |    ar$shtl    |    ar$sstl    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   ar$afn
     Defines the type of "link layer" addresses being carried.  This
     number is taken from the 'address family number' list specified in
     [6].  This field has implications to the coding of ar$shtl and
     ar$sstl as described below.

   ar$pro.type
     field is a 16 bit unsigned integer representing the following
     number space:

       0x0000 to 0x00FF  Protocols defined by the equivalent NLPIDs.
       0x0100 to 0x03FF  Reserved for future use by the IETF.
       0x0400 to 0x04FF  Allocated for use by the ATM Forum.
       0x0500 to 0x05FF  Experimental/Local use.
       0x0600 to 0xFFFF  Protocols defined by the equivalent Ethertypes.

     (based on the observations that valid Ethertypes are never smaller
     than 0x600, and NLPIDs never larger than 0xFF.)

   ar$pro.snap
     When ar$pro.type has a value of 0x0080, a SNAP encoded extension is
     being used to encode the protocol type. This snap extension is
     placed in the ar$pro.snap field.  This is termed the 'long form'
     protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be
     zero on transmit and ignored on receive. The ar$pro.type field
     itself identifies the protocol being referred to. This is termed
     the 'short form' protocol ID.

     In all cases, where a protocol has an assigned number in the
     ar$pro.type space (excluding 0x0080) the short form MUST be used
     when transmitting NHRP messages; i.e., if Ethertype or NLPID
     codings exist then they are used on transmit rather than the



Luciani, et. al.            Standards Track                    [Page 13]

RFC 2332                       NBMA NHRP                      April 1998


     ethertype.   If both Ethertype and NLPID codings exist then when
     transmitting NHRP messages, the Ethertype coding MUST be used (this
     is consistent with RFC 1483 coding).  So, for example, the
     following codings exist for IP:

       SNAP:      ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00
       NLPID:     ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00
       Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00

     and thus, since the Ethertype coding exists, it is used in
     preference.

   ar$hopcnt
     The Hop count indicates the maximum number of NHSs that an NHRP
     packet is allowed to traverse before being discarded.  This field
     is used in a similar fashion to the way that a TTL is used in an IP
     packet and should be set accordingly.  Each NHS decrements the TTL
     as the NHRP packet transits the NHS on the way to the next hop
     along the routed path to the destination.  If an NHS receives an
     NHRP packet which it would normally forward to a next hop and that
     packet contains an ar$hopcnt set to zero then the NHS sends an
     error indication message back to the source protocol address
     stating that the hop count has been exceeded (see Section 5.2.7)
     and the NHS drops the packet in error;  however, an error
     indication is never sent as a result of receiving an error
     indication.  When a responding NHS replies to an NHRP request, that
     NHS places a value in ar$hopcnt as if it were sending a request of
     its own.

   ar$pktsz
     The total length of the NHRP packet, in octets (excluding link
     layer encapsulation).

   ar$chksum
     The standard IP checksum over the entire NHRP packet starting at
     the fixed header.  If the packet is an odd number of bytes in
     length then this calculation is performed as if a byte set to 0x00
     is appended to the end of the packet.

   ar$extoff
     This field identifies the existence and location of NHRP
     extensions.  If this field is 0 then no extensions exist otherwise
     this field represents the offset from the beginning of the NHRP
     packet (i.e., starting from the ar$afn field) of the first
     extension.






Luciani, et. al.            Standards Track                    [Page 14]

RFC 2332                       NBMA NHRP                      April 1998


   ar$op.version
     This field indicates what version of generic address mapping and
     management protocol is represented by this message.

       0               MARS protocol [11].
       1               NHRP as defined in this document.
       0x02 - 0xEF     Reserved for future use by the IETF.
       0xF0 - 0xFE     Allocated for use by the ATM Forum.
       0xFF            Experimental/Local use.

   ar$op.type
     When ar$op.version == 1, this is the NHRP packet type: NHRP
     Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration
     Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP
     Purge Reply(6), or NHRP Error Indication(7).  Use of NHRP packet
     Types in the range 128 to 255 are reserved for research or use in
     other protocol development and will be administered by IANA as
     described in Section 9.

   ar$shtl
     Type & length of source NBMA address interpreted in the context of
     the 'address family number'[6] indicated by ar$afn.  See below for
     more details.

   ar$sstl
     Type & length of source NBMA subaddress interpreted in the context
     of the 'address family number'[6] indicated by ar$afn.  When an
     NBMA technology has no concept of a subaddress, the subaddress
     length is always coded ar$sstl = 0 and no storage is allocated for
     the subaddress in the appropriate mandatory part.  See below for
     more details.

   Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
   T/L) and subnetwork layer subaddresses type/length fields (e.g.,
   ar$sstl, Cli SAddr T/L) are coded as follows:

    7 6 5 4 3 2 1 0
   +-+-+-+-+-+-+-+-+
   |0|x|  length   |
   +-+-+-+-+-+-+-+-+

   The most significant bit is reserved and MUST be set to zero. The
   second most significant bit (x) is a flag indicating whether the
   address being referred to is in:

      - NSAP format (x = 0).
      - Native E.164 format (x = 1).




Luciani, et. al.            Standards Track                    [Page 15]

RFC 2332                       NBMA NHRP                      April 1998


   For NBMA technologies that use neither NSAP nor E.164 format
   addresses, x = 0 SHALL be used to indicate the native form for the
   particular NBMA technology.

   If the NBMA network is ATM and a subaddress (e.g., Source NBMA
   SubAddress, Client NBMA SubAddress) is to be included in any part of
   the NHRP packet then ar$afn MUST be set to 0x000F; further, the
   subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
   T/L) and subnetwork layer subaddress type/length fields (e.g.,
   ar$sstl, Cli SAddr T/L) MUST be coded as in [11].  If the NBMA
   network is ATM and no subaddress field is to be included in any part
   of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008
   (E.164) accordingly.

   The bottom 6 bits is an unsigned integer value indicating the length
   of the associated NBMA address in octets. If this value is zero the
   flag x is ignored.

5.2.0 Mandatory Part

   The Mandatory Part of the NHRP packet contains the operation specific