rfc2332.txt

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

   information (e.g., NHRP Resolution Request/Reply, etc.) and variable
   length data which is pertinent to the packet type.

5.2.0.1 Mandatory Part Format

   Sections 5.2.1 through 5.2.6 have a very similar mandatory part.
   This mandatory part includes a common header and zero or more Client
   Information Entries (CIEs). Section 5.2.7 has a different format
   which is specified in that section.

   The common header looks like the following:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Src Proto Len | Dst Proto Len |           Flags               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source NBMA Address (variable length)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source NBMA Subaddress (variable length)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Protocol Address (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Destination  Protocol Address (variable length)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



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


   And the CIEs have the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Code       | Prefix Length |         unused                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maximum Transmission Unit    |        Holding Time           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Client NBMA Address (variable length)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Client NBMA Subaddress (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Client Protocol Address (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        .....................
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Code       | Prefix Length |         unused                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maximum Transmission Unit    |        Holding Time           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Client NBMA Address (variable length)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Client NBMA Subaddress (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Client Protocol Address (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meanings of the fields are as follows:

   Src Proto Len
     This field holds the length in octets of the Source Protocol
     Address.

   Dst Proto Len
     This field holds the length in octets of the Destination Protocol
     Address.

   Flags
     These flags are specific to the given message type and they are
     explained in each section.






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


   Request ID
     A value which, when coupled with the address of the source,
     provides a unique identifier for the information contained in a
     "request" packet.  This value is copied directly from an "request"
     packet into the associated "reply".  When a sender of a "request"
     receives "reply", it will compare the Request ID and source address
     information in the received "reply" against that found in its
     outstanding "request" list.  When a match is found then the
     "request" is considered to be acknowledged.

     The value is taken from a 32 bit counter that is incremented each
     time a new "request" is transmitted.  The same value MUST be used
     when resending a "request", i.e., when a "reply" has not been
     received for a "request" and a retry is sent after an appropriate
     interval.

     It is RECOMMENDED that the initial value for this number be 0.  A
     node MAY reuse a sequence number if and only if the reuse of the
     sequence number is not precluded by use of a particular method of
     synchronization (e.g., as described in Appendix A).

   The NBMA address/subaddress form specified below allows combined
   E.164/NSAPA form of NBMA addressing. For NBMA technologies without a
   subaddress concept, the subaddress field is always ZERO length and
   ar$sstl = 0.

   Source NBMA Address
     The Source NBMA address field is the address of the source station
     which is sending the "request". If the field's length as specified
     in ar$shtl is 0 then no storage is allocated for this address at
     all.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the address of the source
     station which is sending the "request".  If the field's length as
     specified in ar$sstl is 0 then no storage is allocated for this
     address at all.

   For those NBMA technologies which have a notion of "Calling Party
   Addresses", the Source NBMA Addresses above are the addresses used
   when signaling for an SVC.

   "Requests" and "indications" follow the routed path from Source
   Protocol Address to the Destination Protocol Address. "Replies", on
   the other hand, follow the routed path from the Destination Protocol
   Address back to the Source Protocol Address with the following





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


   exceptions: in the case of a NHRP Registration Reply and in the case
   of an NHC initiated NHRP Purge Request, the packet is always returned
   via a direct VC (see Sections 5.2.4 and 5.2.5).

   Source Protocol Address
     This is the protocol address of the station which is sending the
     "request".  This is also the protocol address of the station toward
     which a "reply" packet is sent.

   Destination Protocol Address
     This is the protocol address of the station toward which a
     "request" packet is sent.

   Code
     This field is message specific.  See the relevant message sections
     below.  In general, this field is a NAK code; i.e., when the field
     is 0 in a reply then the packet is acknowledging a request and if
     it contains any other value the packet contains a negative
     acknowledgment.

   Prefix Length
     This field is message specific.  See the relevant message sections
     below.  In general, however, this fields is used to indicate that
     the information carried in an NHRP message pertains to an
     equivalence class of internetwork layer addresses rather than just
     a single internetwork layer address specified. All internetwork
     layer addresses that match the first "Prefix Length" bit positions
     for the specific internetwork layer address are included in the
     equivalence class.  If this field is set to 0x00 then this field
     MUST be ignored and no equivalence information is assumed (note
     that 0x00 is thus equivalent to 0xFF).

   Maximum Transmission Unit
     This field gives the maximum transmission unit for the relevant
     client station.  If this value is 0 then either the default MTU is
     used or the MTU negotiated via signaling is used if such
     negotiation is possible for the given NBMA.

   Holding Time
     The Holding Time field specifies the number of seconds for which
     the Next Hop NBMA information specified in the CIE is considered to
     be valid.  Cached information SHALL be discarded when the holding
     time expires.  This field must be set to 0 on a NAK.








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


   Cli Addr T/L
     Type & length of next hop NBMA address specified in the CIE.  This
     field is interpreted in the context of the 'address family
     number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM).

   Cli SAddr T/L
     Type & length of next hop NBMA subaddress specified in the CIE.
     This field is interpreted in the context of the 'address family
     number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes
     the address an E.164 and the subaddress an ATM Forum NSAP address).
     When an NBMA technology has no concept of a subaddress, the
     subaddress is always null with a length of 0.  When the address
     length is specified as 0 no storage is allocated for the address.

   Cli Proto Len
     This field holds the length in octets of the Client Protocol
     Address specified in the CIE.

   Preference
     This field specifies the preference for use of the specific CIE
     relative to other CIEs.  Higher values indicate higher preference.
     Action taken when multiple CIEs have equal or highest preference
     value is a local matter.

   Client NBMA Address
     This is the client's NBMA address.

   Client NBMA SubAddress
     This is the client's NBMA subaddress.

   Client Protocol Address
     This is the client's internetworking layer address specified.

   Note that an NHS may cache source address binding information from an
   NHRP Resolution Request if and only if the conditions described in
   Section 6.2 are met for the NHS.  In all other cases, source address
   binding information appearing in an NHRP message MUST NOT be cached.

5.2.1 NHRP Resolution Request

   The NHRP Resolution Request packet has a Type code of 1. Its
   mandatory part is coded as described in Section 5.2.0.1 and the
   message specific meanings of the fields are as follows:

   Flags - The flags field is coded as follows:






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


      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Q|A|D|U|S|       unused        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Q
       Set if the station sending the NHRP Resolution Request is a
       router; clear if the it is a host.

     A
       This bit is set in a NHRP Resolution Request if only
       authoritative next hop information is desired and is clear
       otherwise.  See the NHRP Resolution Reply section below for
       further details on the "A" bit and its usage.

     D
       Unused (clear on transmit)

     U
       This is the Uniqueness bit. This bit aids in duplicate address
       detection.  When this bit is set in an NHRP Resolution Request
       and one or more entries exist in the NHS cache which meet the
       requirements of the NHRP Resolution Request then only the CIE in
       the NHS's cache with this bit set will be returned.  Note that
       even if this bit was set at registration time, there may still be
       multiple CIEs that might fulfill the NHRP Resolution Request
       because an entire subnet can be registered through use of the
       Prefix Length in the CIE and the address of interest might be
       within such a subnet. If the "uniqueness" bit is set and the