rfc2332.txt

RFC 的详细文档！

   The protocol proceeds as follows.  An event occurs triggering station
   S to want to resolve the NBMA address of a path to D.  This is most
   likely to be when a data packet addressed to station D is to be
   emitted from station S (either because station S is a host, or
   station S is a transit router), but the address resolution could also
   be triggered by other means (a routing protocol update packet, for
   example). Station S first determines the next hop to station D
   through normal routing processes (for a host, the next hop may simply
   be the default router; for routers, this is the "next hop" to the
   destination internetwork layer address).  If the destination's
   address resolution information is already available in S's cache then
   that information is used to forward the packet.  Otherwise, if the
   next hop is reachable through one of its NBMA interfaces, S
   constructs an NHRP Resolution Request packet (see Section 5.2.1)
   containing station D's internetwork layer address as the (target)
   destination address, S's own internetwork layer address as the source
   address (Next Hop Resolution Request initiator), and station S's NBMA
   addressing information.  Station S may also indicate that it prefers
   an authoritative NHRP Resolution Reply (i.e., station S only wishes
   to receive an NHRP Resolution Reply from an NHS serving the
   destination NHC). Station S emits the NHRP Resolution Request packet
   towards the destination.

   If the NHRP Resolution Request is triggered by a data packet then S
   may, while awaiting an NHRP Resolution Reply, choose to dispose of
   the data packet in one of the following ways:

     (a)  Drop the packet
     (b)  Retain the packet until the NHRP Resolution Reply arrives
          and a more optimal path is available
     (c)  Forward the packet along the routed path toward D

   The choice of which of the above to perform is a local policy matter,
   though option (c) is the recommended default, since it may allow data
   to flow to the destination while the NBMA address is being resolved.
   Note that an NHRP Resolution Request for a given destination MUST NOT
   be triggered on every packet.

   When the NHS receives an NHRP Resolution Request, a check is made to
   see if it serves station D.  If the NHS does not serve D, the NHS
   forwards the NHRP Resolution Request to another NHS.  Mechanisms for
   determining how to forward the NHRP Resolution Request are discussed
   in Section 3.

   If this NHS serves D, the NHS resolves station D's NBMA address
   information, and generates a positive NHRP Resolution Reply on D's
   behalf.  NHRP Resolution Replies in this scenario are always marked
   as "authoritative".  The NHRP Resolution Reply packet contains the



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


   address resolution information for station D which is to be sent back
   to S.  Note that if station D is not on the NBMA subnetwork, the next
   hop internetwork layer address will be that of the egress router
   through which packets for station D are forwarded.

   A transit NHS receiving an NHRP Resolution Reply may cache the
   address resolution information contained therein.  To a subsequent
   NHRP Resolution Request, this NHS may respond with the cached, "non-
   authoritative" address resolution information if the NHS is permitted
   to do so (see Sections 5.2.2 and 6.2 for more information on non-
   authoritative versus authoritative NHRP Resolution Replies).  Non-
   authoritative NHRP Resolution Replies are distinguished from
   authoritative NHRP Resolution Replies so that if a communication
   attempt based on non-authoritative information fails, a source
   station can choose to send an authoritative NHRP Resolution Request.
   NHSs MUST NOT respond to authoritative NHRP Resolution Requests with
   cached information.

   If the determination is made that no NHS in the NBMA subnetwork can
   reply to the NHRP Resolution Request for D then a negative NHRP
   Resolution Reply (NAK) is returned.  This occurs when (a) no next-hop
   resolution information is available for station D from any NHS, or
   (b) an NHS is unable to forward the NHRP Resolution Request (e.g.,
   connectivity is lost).

   NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies,
   and NHRP Error Indications follow a routed path in the same fashion
   that NHRP Resolution Requests and NHRP Resolution Replies do.
   Specifically, "requests" and "indications" follow the routed path
   from Source Protocol Address (which is the address of the station
   initiating the communication) 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 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); if
   one does not exists then one MUST be created.

   NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA
   subnetwork however further study is being done in this area (see
   Section 7).   Thus, the internetwork layer data traffic out of and
   into an NBMA subnetwork always traverses an internetwork layer router
   at its border.

   NHRP optionally provides a mechanism to send a NHRP Resolution Reply
   which contains aggregated address resolution information. For
   example, suppose that router X is the next hop from station S to
   station D and that X is an egress router for all stations sharing an



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


   internetwork layer address prefix with station D.  When an NHRP
   Resolution Reply is generated in response to a NHRP Resolution
   Request, the responder may augment the internetwork layer address of
   station D with a prefix length (see Section 5.2.0.1).  A subsequent
   (non-authoritative) NHRP Resolution Request for some destination that
   shares an internetwork layer address prefix (for the number of bits
   specified in the prefix length) with D may be satisfied with this
   cached information.  See section 6.2 regarding caching issues.

   To dynamically detect subnetwork-layer filtering in NBMA subnetworks
   (e.g., X.25 closed user group facility, or SMDS address screens), to
   trace the routed path that an NHRP packet takes, or to provide loop
   detection and diagnostic capabilities, a "Route Record" may be
   included in NHRP packets (see Sections 5.3.2 and 5.3.3).  The Route
   Record extensions are the NHRP Forward Transit NHS Record Extension
   and the NHRP Reverse Transit NHS Record Extension.  They contain the
   internetwork (and subnetwork layer) addresses of all intermediate
   NHSs between source and destination and between destination and
   source respectively.  When a source station is unable to communicate
   with the responder (e.g., an attempt to open an SVC fails), it may
   attempt to do so successively with other subnetwork layer addresses
   in the NHRP Forward Transit NHS Record Extension until it succeeds
   (if authentication policy permits such action).  This approach can
   find a suitable egress point in the presence of subnetwork-layer
   filtering (which may be source/destination sensitive, for instance,
   without necessarily creating separate logical NBMA subnetworks) or
   subnetwork-layer congestion (especially in connection-oriented
   media).

3. Deployment

   NHRP Resolution Requests traverse one or more hops within an NBMA
   subnetwork before reaching the station that is expected to generate a
   response.  Each station, including the source station, chooses a
   neighboring NHS to which it will forward the NHRP Resolution Request.
   The NHS selection procedure typically involves applying a destination
   protocol layer address to the protocol layer routing table which
   causes a routing decision to be returned.  This routing decision is
   then used to forward the NHRP Resolution Request to the downstream
   NHS. The destination protocol layer address previously mentioned is
   carried within the NHRP Resolution Request packet.  Note that even
   though a protocol layer address was used to acquire a routing
   decision, NHRP packets are not encapsulated within a protocol layer
   header but rather are carried at the NBMA layer using the
   encapsulation described in Section 5.






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


   Each NHS/router examines the NHRP Resolution Request packet on its
   way toward the destination.  Each NHS which the NHRP packet traverses
   on the way to the packet's destination might modify the packet (e.g.,
   updating the Forward Record extension).  Ignoring error situations,
   the NHRP Resolution Request eventually arrives at a station that is
   to generate an NHRP Resolution Reply.  This responding station
   "serves" the destination.  The responding station generates an NHRP
   Resolution Reply using the source protocol address from within the
   NHRP packet to determine where the NHRP Resolution Reply should be
   sent.

   Rather than use routing to determine the next hop for an NHRP packet,
   an NHS may use other applicable means (such as static configuration
   information ) in order to determine to which neighboring NHSs to
   forward the NHRP Resolution Request packet as long as such other
   means would not cause the NHRP packet to arrive at an NHS which is
   not along the routed path.  The use of static configuration
   information for this purpose is beyond the scope of this document.

   The NHS serving a particular destination must lie along the routed
   path to that destination.  In practice, this means that all egress
   routers must double as NHSs serving the destinations beyond them, and
   that hosts on the NBMA subnetwork are served by routers that double
   as NHSs.  Also, this implies that forwarding of NHRP packets within
   an NBMA subnetwork requires a contiguous deployment of NHRP capable
   routers.  It is important that, in a given LIS/LAG which is using
   NHRP, all NHSs within the LIS/LAG have at least some portion of their
   resolution databases synchronized so that a packet arriving at one
   router/NHS in a given LIS/LAG will be forwarded in the same fashion
   as a packet arriving at a different router/NHS for the given LIS/LAG.
   One method, among others, is to use the Server Cache Synchronization
   Protocol (SCSP) [12].  It is RECOMMENDED that SCSP be the method used
   when a LIS/LAG contains two or more router/NHSs.

   During migration to NHRP, it cannot be expected that all routers
   within the NBMA subnetwork are NHRP capable.  Thus, NHRP traffic
   which would otherwise need to be forwarded through such routers can
   be expected to be dropped due to the NHRP packet not being
   recognized.  In this case, NHRP will be unable to establish any
   transit paths whose discovery requires the traversal of the non-NHRP
   speaking routers.  If the client has tried and failed to acquire a
   cut through path then the client should use the network layer routed
   path as a default.

   If an NBMA technology offers a group, an anycast, or a multicast
   addressing feature then the NHC may be configured with such an
   address (appropriate to the routing realm it participates in) which
   would be assigned to all NHS serving that routing realm.  This



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


   address can then be used for establishing an initial connection to an
   NHS to transmit a registration request.  This address may not be used
   for sending NHRP requests.  The resulting VC may be used for NHRP
   requests if and only if the registration response is received over
   that VC, thereby indicating that one happens to have anycast
   connected to an NHS serving the LIS/LAG.  In the case of non-
   connection oriented networks, or of multicast (rather than anycast)
   addresses, the addres MUST NOT be used for sending NHRP resolution
   requests.

   When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined
   for the NHC directly to the NHC.  That is, the NHRP message MUST NOT
   transit through any NHS which is not serving the NHC when the NHRP
   message is currently at an NHS which does serve the NHC (this, of
   course, assumes the NHRP message is destined for the NHC).  Further,
   an NHS which serves an NHC SHOULD have a direct NBMA level connection
   to that NHC (see Section 5.2.3 and 5.2.4 for examples).

   With the exception of NHRP Registration Requests (see Section 5.2.3
   and 5.2.4 for details of the NHRP Registration Request case), an NHC
   MUST send NHRP messages over a direct NBMA level connection between
   the serving NHS and the served NHC.

   It may not be desirable to maintain semi-permanent NBMA level
   connectivity between the NHC and the NHS.   In this case, when NBMA
   level connectivity is initially setup between the NHS and the NHC (as
   described in Section 5.2.4), the NBMA address of the NHS should be
   obtained through the NBMA level signaling technology.  This address
   should be stored for future use in setting up subsequent NBMA level
   connections.  A somewhat more information rich technique to obtain
   the address information (and more) of the serving NHS would be for
   the NHC to include the Responder Address extension (see Section
   5.3.1) in the NHRP Registration Request and to store the information
   returned to the NHC in the Responder Address extension which is
   subsequently included in the NHRP Registration Reply.  Note also
   that, in practice, a client's default router should also be its NHS;
   thus a client may be able to know the NBMA address of its NHS from
   the configuration which was already required for the client to be
   able to communicate.  Further, as mentioned in Section 4, NHCs may be
   configured with the addressing information of one or more NHSs.

4. Configuration

   Next Hop Clients

     An NHC connected to an NBMA subnetwork MAY be configured with the
     Protocol address(es) and NBMA address(es) of its NHS(s).  The
     NHS(s) will likely also represent the NHC's default or peer



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


     routers, so their NBMA addresses may be obtained from the NHC's
     existing configuration.  If the NHC is attached to several