rfc2332.txt

RFC 的详细文档！

     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
       responding NHS has one or more cache entries which match the
       request but no such cache entry has the "uniqueness" bit set,
       then the NHRP Resolution Reply returns with a NAK code of "13 -
       Binding Exists But Is Not Unique" and no CIE is included.  If a
       client wishes  to  receive  non- unique  Next  Hop Entries, then
       the client must have the "uniqueness" bit set to zero in its NHRP
       Resolution Request. Note that when this bit is set in an NHRP
       Registration Request, only a single CIE may be specified in the
       NHRP Registration Request and that CIE must have the Prefix
       Length field set to 0xFF.

     S
       Set if the binding between the Source Protocol Address and the
       Source NBMA information in the NHRP Resolution Request is
       guaranteed to be stable and accurate (e.g., these addresses are
       those of an ingress router which is connected to an ethernet stub
       network or the NHC is an NBMA attached host).




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


   Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP
   Resolution Request.  If one is specified then that entry carries the
   pertinent information for the client sourcing the NHRP Resolution
   Request.  Usage of the CIE in the NHRP Resolution Request is
   described below:

     Prefix Length
       If a CIE is specified in the NHRP Resolution Request then the
       Prefix Length field may be used to qualify the widest acceptable
       prefix which may be used to satisfy the NHRP Resolution Request.
       In the case of NHRP Resolution Request/Reply, the Prefix Length
       specifies the equivalence class of addresses which match the
       first "Prefix Length" bit positions of the Destination Protocol
       Address.  If the "U" bit is set in the common header then this
       field MUST be set to 0xFF.

     Maximum Transmission Unit
       This field gives the maximum transmission unit for the source
       station.  A possible use of this field in the NHRP Resolution
       Request packet is for the NHRP Resolution Requester to ask for a
       target MTU.

     Holding Time
       The Holding Time specified in the one CIE permitted to be
       included in an NHRP Resolution Request is the amount of time
       which the source address binding information in the NHRP
       Resolution Request is permitted to cached by transit and
       responding NHSs.  Note that this field may only have a non-zero
       value if the S bit is set.

     All other fields in the CIE MUST be ignored and SHOULD be set to 0.

   The Destination Protocol Address in the common header of the
   Mandatory Part of this message contains the protocol address of the
   station for which resolution is desired.  An NHC MUST send the NHRP
   Resolution Request directly to one of its serving NHSs (see Section 3
   for more information).

5.2.2 NHRP Resolution Reply

   The NHRP Resolution Reply packet has a Type code of 2. CIEs
   correspond to Next Hop Entries in an NHS's cache which match the
   criteria in the NHRP Resolution Request.  Its mandatory part is coded
   as described in Section 5.2.0.1.  The message specific meanings of
   the fields are as follows:

   Flags - The flags field is coded as follows:




Luciani, et. al.            Standards Track                    [Page 22]

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
       Copied from the NHRP Resolution Request.  Set if the NHRP
       Resolution Requester is a router;  clear if it is a host.

     A
       Set if the next hop CIE in the NHRP Resolution Reply is
       authoritative; clear if the NHRP Resolution Reply is non-
       authoritative.

       When an NHS receives a NHRP Resolution Request for authoritative
       information for which it is the authoritative source, it MUST
       respond with a NHRP Resolution Reply containing all and only
       those next hop CIEs which are contained in the NHS's cache which
       both match the criteria of the NHRP Resolution Request and are
       authoritative cache entries.  An NHS is an authoritative source
       for a NHRP Resolution Request if the information in the NHS's
       cache matches the NHRP Resolution Request criteria and that
       information was obtained through a NHRP Registration Request or
       through synchronization with an NHS which obtained this
       information through a NHRP Registration Request.  An
       authoritative cache entry is one which is obtained through a NHRP
       Registration Request or through synchronization with an NHS which
       obtained this information through a NHRP Registration Request.

       An NHS obtains non-authoritative CIEs through promiscuous
       listening to NHRP packets other than NHRP Registrations which are
       directed at it.  A NHRP Resolution Request which indicates a
       request for non-authoritative information should cause a NHRP
       Resolution Reply which contains all entries in the replying NHS's
       cache (i.e., both authoritative and non-authoritative) which
       match the criteria specified in the request.

     D
       Set if the association between destination and the associate next
       hop information included in all CIEs of the NHRP Resolution Reply
       is guaranteed to be stable for the lifetime of the information
       (the holding time).  This is the case if the Next Hop protocol
       address in a CIE identifies the destination (though it may be
       different in value than the Destination address if the
       destination system has multiple addresses) or if the destination
       is not connected directly to the NBMA subnetwork but the egress
       router to that destination is guaranteed to be stable (such as



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


       when the destination is immediately adjacent to the egress router
       through a non-NBMA interface).

     U
       This is the Uniqueness bit. See the NHRP Resolution Request
       section above for details.  When this bit is set, only one CIE is
       included since only one unique binding should exist in an NHS's
       cache.

     S
       Copied from NHRP Resolution Request message.

   One or more CIEs are specified in the NHRP Resolution Reply. Each CIE
   contains NHRP next hop information which the responding NHS has
   cached and which matches the parameters specified in the NHRP
   Resolution Request.  If no match is found by the NHS issuing the NHRP
   Resolution Reply then a single CIE is enclosed with the a CIE Code
   set appropriately (see below) and all other fields MUST be ignored
   and SHOULD be set to 0.  In order to facilitate the use of NHRP by
   minimal client implementations, the first CIE MUST contain the next
   hop with the highest preference value so that such an implementation
   need parse only a single CIE.

     Code
       If this field is set to zero then this packet contains a
       positively acknowledged NHRP Resolution Reply.  If this field
       contains any other value then this message contains an NHRP
       Resolution Reply NAK which means that an appropriate
       internetworking layer to NBMA address binding was not available
       in the responding NHS's cache.  If NHRP Resolution Reply contains
       a Client Information Entry with a NAK Code other than 0 then it
       MUST NOT contain any other CIE.  Currently defined NAK Codes are
       as follows:

       4 - Administratively Prohibited

         An NHS may refuse an NHRP Resolution Request attempt for
         administrative reasons (due to policy constraints or routing
         state).  If so, the NHS MUST send an NHRP Resolution Reply
         which contains a NAK code of 4.

       5 - Insufficient Resources

         If an NHS cannot serve a station due to a lack of resources
         (e.g., can't store sufficient information to send a purge if
         routing changes), the NHS MUST reply with a NAKed NHRP
         Resolution Reply which contains a NAK code of 5.




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


       12 - No Internetworking Layer Address to NBMA Address Binding
            Exists

         This code states that there were absolutely no internetworking
         layer address to NBMA address bindings found in the responding
         NHS's cache.

       13 - Binding Exists But Is Not Unique

         This code states that there were one or more internetworking
         layer address to NBMA address bindings found in the responding
         NHS's cache, however none of them had the uniqueness bit set.

     Prefix Length
       In the case of NHRP Resolution Reply, the Prefix Length specifies
       the equivalence class of addresses which match the first "Prefix
       Length" bit positions of the Destination Protocol Address.

     Holding Time
       The Holding Time specified in a CIE of an NHRP Resolution Reply
       is the amount of time remaining before the expiration of the
       client information which is cached at the replying NHS.  It is
       not the value which was registered by the client.

     The remainder of the fields for the CIE for each next hop are
     filled out as they were defined when the next hop was registered
     with the responding NHS (or one of the responding NHS's
     synchronized servers) via the NHRP Registration Request.

   Load-splitting may be performed when more than one Client Information
   Entry is returned to a requester when equal preference values are
   specified.  Also, the alternative addresses may be used in case of
   connectivity failure in the NBMA subnetwork (such as a failed call
   attempt in connection-oriented NBMA subnetworks).

   Any extensions present in the NHRP Resolution Request packet MUST be
   present in the NHRP Resolution Reply even if the extension is non-
   Compulsory.

   If an unsolicited NHRP Resolution Reply packet is received, an Error
   Indication of type Invalid NHRP Resolution Reply Received SHOULD be
   sent in response.

   When an NHS that serves a given NHC receives an NHRP Resolution Reply
   destined for that NHC then the NHS must MUST send the NHRP Resolution
   Reply directly to the NHC (see Section 3).





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


5.2.3 NHRP Registration Request

   The NHRP Registration Request is sent from a station to an NHS to
   notify the NHS of the station's NBMA information.  It has a Type code
   of 3. Each CIE corresponds to Next Hop information which is to be
   cached at an NHS.  The mandatory part of an NHRP Registration Request
   is coded as described in Section 5.2.0.1.  The message specific
   meanings of the fields are as follows:

   Flags - The flags field is coded as follows:

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5