draft-ietf-rolc-nhrp-07.txt   draft-ietf-rolc-nhrp-08.txt 
Routing over Large Clouds Working Group Dave Katz Routing over Large Clouds Working Group James V. Luciani
INTERNET-DRAFT (cisco Systems) INTERNET-DRAFT (Bay Networks)
<draft-ietf-rolc-nhrp-07.txt> David Piscitello <draft-ietf-rolc-nhrp-08.txt> Dave Katz
(cisco Systems)
David Piscitello
(Core Competence, Inc.) (Core Competence, Inc.)
Bruce Cole Bruce Cole
(cisco Systems) (cisco Systems)
James V. Luciani Expires December 1996
(Ascom Nexion)
NBMA Next Hop Resolution Protocol (NHRP) NBMA Next Hop Resolution Protocol (NHRP)
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 24 skipping to change at page 2, line 24
layer addresses and NBMA addresses of suitable "NBMA next hops" layer addresses and NBMA addresses of suitable "NBMA next hops"
toward a destination station. A subnetwork can be non-broadcast toward a destination station. A subnetwork can be non-broadcast
either because it technically doesn't support broadcasting (e.g., an either because it technically doesn't support broadcasting (e.g., an
X.25 subnetwork) or because broadcasting is not feasible for one X.25 subnetwork) or because broadcasting is not feasible for one
reason or another (e.g., an SMDS multicast group or an extended reason or another (e.g., an SMDS multicast group or an extended
Ethernet would be too large). If the destination is connected to the Ethernet would be too large). If the destination is connected to the
NBMA subnetwork, then the NBMA next hop is the destination station NBMA subnetwork, then the NBMA next hop is the destination station
itself. Otherwise, the NBMA next hop is the egress router from the itself. Otherwise, the NBMA next hop is the egress router from the
NBMA subnetwork that is "nearest" to the destination station. NBMA subnetwork that is "nearest" to the destination station.
An NBMA subnetwork may, in general, consist of multiple Local Address One way to model an NBMA network is by using the notion of logically
Groups (LAGs). In the case of IP, a logically independent IP subnet independent IP subnets (LISs). LISs, as defined in [3] and [4], have
(LIS) is an example of a LAG. LISs, as defined in [3] and [4], have
the following properties: the following properties:
1) All members of a LIS have the same IP network/subnet number 1) All members of a LIS have the same IP network/subnet number
and address mask. and address mask.
2) All members within a LIS are directly connected to the same 2) All members within a LIS are directly connected to the same
NBMA subnetwork. NBMA subnetwork.
3) All members outside of the LIS are accessed via a router. 3) All members outside of the LIS are accessed via a router.
4) All members within the LIS access each other directly
(without routers)
Address resolution as described in [3] and [4] only resolves the next Address resolution as described in [3] and [4] only resolves the next
hop address if the destination station is a member of the same LIS as hop address if the destination station is a member of the same LIS as
the source station; otherwise, the source station must forward the source station; otherwise, the source station must forward
packets to a router that is a member of multiple LIS's. In multi-LIS packets to a router that is a member of multiple LIS's. In multi-LIS
configurations, hop-by-hop address resolution may not be sufficient configurations, hop-by-hop address resolution may not be sufficient
to resolve the "NBMA next hop" toward the destination station, and IP to resolve the "NBMA next hop" toward the destination station, and IP
packets may traverse the NBMA subnetwork more than once. packets may have multiple IP hops through the NBMA subnetwork.
NHRP describes a next hop resolution method that relaxes the Another way to model NBMA is by using the notion of Local Address
forwarding restrictions of the LIS model. With NHRP when the Groups (LAGs) [10]. The essential difference between the LIS and the
internetwork layer address is of type IP, once the NBMA next hop has LAG models is that while with the LIS model the outcome of the
been resolved, the source may either start sending IP packets to the "local/remote" forwarding decision is driven purely by addressing
destination (in a connectionless NBMA subnetwork such as SMDS) or may information, with the LAG model the outcome of this decision is
first establish a connection to the destination with the desired decoupled from the addressing information and is coupled with the
Quality of Service and/or traffic characteristics. With the LAG
model any two entities on a common NBMA network could establish a
direct communication with each other, irrespective of the entities'
addresses.
Support for the LAG model assumes the existence of a mechanism that
allows any entity (i.e., host or router) connected to an NBMA network
to resolve an internetworking layer address to an NBMA address for
any other entity connected to the same NBMA network. This resolution
would take place regardless of the address assignments to these
entities. NHRP describes such a mechanism. For example, when the
internetworking layer address is of type IP, once the NBMA next hop
has been resolved, the source may either start sending IP packets to
the destination (in a connectionless NBMA subnetwork such as SMDS) or
may first establish a connection to the destination with the desired
bandwidth and QOS characteristics (in a connection-oriented NBMA bandwidth and QOS characteristics (in a connection-oriented NBMA
subnetwork such as ATM). subnetwork such as ATM).
NHRP in its most basic form provides a simple internetworking layer Use of NHRP may be sufficient for hosts doing address resolution when
to NBMA subnetwork layer address binding service. This may be those hosts are directly connected to an NBMA subnetwork, allowing
sufficient for hosts which are directly connected to an NBMA for straightforward implementations in NBMA stations. NHRP also has
subnetwork, allowing for straightforward implementations in NBMA the capability of determining the egress point from an NBMA
stations. NHRP also has the capability of determining the egress subnetwork when the destination is not directly connected to the NBMA
point from an NBMA subnetwork when the destination is not directly subnetwork and the identity of the egress router is not learned by
connected to the NBMA subnetwork and the identity of the egress other methods (such as routing protocols). Optional extensions to
router is not learned by other methods (such as routing protocols). NHRP provide additional robustness and diagnosability.
Optional extensions to NHRP provide additional robustness and
diagnosability.
Address resolution techniques such as those described in [3] and [4] Address resolution techniques such as those described in [3] and [4]
may be in use when NHRP is deployed. ARP servers and services over may be in use when NHRP is deployed. ARP servers and services over
NBMA subnetworks may be required to support hosts that are not NBMA subnetworks may be required to support hosts that are not
capable of dealing with any model for communication other than the capable of dealing with any model for communication other than the
LIS model, and deployed hosts may not implement NHRP but may continue LIS model, and deployed hosts may not implement NHRP but may continue
to support ARP variants such as those described in [3] and [4]. NHRP to support ARP variants such as those described in [3] and [4]. NHRP
is intended to reduce or eliminate the extra router hops required by is intended to reduce or eliminate the extra router hops required by
the LIS model, and can be deployed in a non-interfering manner the LIS model, and can be deployed in a non-interfering manner
alongside existing ARP services. alongside existing ARP services.
skipping to change at page 3, line 46 skipping to change at page 4, line 19
The term "network" is highly overloaded, and is especially confusing The term "network" is highly overloaded, and is especially confusing
in the context of NHRP. We use the following terms: in the context of NHRP. We use the following terms:
Internetwork layer--the media-independent layer (IP in the case of Internetwork layer--the media-independent layer (IP in the case of
TCP/IP networks). TCP/IP networks).
Subnetwork layer--the media-dependent layer underlying the Subnetwork layer--the media-dependent layer underlying the
internetwork layer, including the NBMA technology (ATM, X.25, SMDS, internetwork layer, including the NBMA technology (ATM, X.25, SMDS,
etc.) etc.)
The term "server", unless explicitly stated to the contrary, refers
to an Next Hop Server (NHS). An NHS is an entity performing the
Next Hop Resolution Protocol service within the NBMA cloud. An NHS
is always tightly coupled with a routing entity (router, route
server or edge device) although the converse is not yet guaranteed
until ubiquitous deployment of this functionality occurs.
The term "client", unless explicitly stated to the contrary, refers
to an Next Hop Resolution Protocol client (NHC). An NHC is an
entity which initiates NHRP requests of various types in order to
obtain access to the NHRP service.
The term "station" generally refers to a host or router which
contains an NHRP entity. Occasionally, the term station will
describe a "user" of the NHRP client or service functionality; the
difference in usage is largely semantic.
2.2 Protocol Overview 2.2 Protocol Overview
In this section, we briefly describe how a source S (which In this section, we briefly describe how a source S (which
potentially can be either a router or a host) uses NHRP to determine potentially can be either a router or a host) uses NHRP to determine
the "NBMA next hop" to destination D. the "NBMA next hop" to destination D.
For administrative and policy reasons, a physical NBMA subnetwork may For administrative and policy reasons, a physical NBMA subnetwork may
be partitioned into several, disjoint "Logical NBMA subnetworks". A be partitioned into several, disjoint "Logical NBMA subnetworks". A
Logical NBMA subnetwork is defined as a collection of hosts and Logical NBMA subnetwork is defined as a collection of hosts and
routers that share unfiltered subnetwork connectivity over an NBMA routers that share unfiltered subnetwork connectivity over an NBMA
skipping to change at page 4, line 30 skipping to change at page 5, line 17
Servers" (NHSs). Each NHS serves a set of destination hosts, which Servers" (NHSs). Each NHS serves a set of destination hosts, which
may or may not be directly connected to the NBMA subnetwork. NHSs may or may not be directly connected to the NBMA subnetwork. NHSs
cooperatively resolve the NBMA next hop within their logical NBMA cooperatively resolve the NBMA next hop within their logical NBMA
subnetwork. In addition to NHRP, NHSs may participate in protocols subnetwork. In addition to NHRP, NHSs may participate in protocols
used to disseminate routing information across (and beyond the used to disseminate routing information across (and beyond the
boundaries of) the NBMA subnetwork, and may support "classical" ARP boundaries of) the NBMA subnetwork, and may support "classical" ARP
service as well. service as well.
An NHS maintains a "next-hop resolution" cache, which is a table of An NHS maintains a "next-hop resolution" cache, which is a table of
address mappings (internetwork layer address to NBMA subnetwork layer address mappings (internetwork layer address to NBMA subnetwork layer
address). This table can be constructed from information gleaned from address). This table can be constructed from information gleaned
NHRP Register packets (see Section 5.2.3 and 5.2.4), extracted from from NHRP Register packets (see Section 5.2.3 and 5.2.4), extracted
Next Hop Resolution Requests/Replies that traverse the NHS as they from Next Hop Resolution Requests/Replies that traverse the NHS as
are forwarded, or through mechanisms outside the scope of this they are forwarded, or through mechanisms outside the scope of this
document (examples of such mechanisms include ARP [2, 3, 4] and pre- document (examples of such mechanisms include ARP [2, 3, 4] and pre-
configured tables). Section 6.2 further describes cache management configured tables). Section 6.2 further describes cache management
issues. issues.
A host or router that is not an NHRP server must be configured with A host or router that is not an NHRP server must be configured with
the identity of the NHS which serves it (see Configuration, Section the identity of the NHS which serves it (see Configuration, Section
4). 4).
[Note: for NBMA subnetworks that offer group or multicast addressing [Note: for NBMA subnetworks that offer group or multicast addressing
features, it may be desirable to configure stations with a group features, it may be desirable to configure stations with a group
skipping to change at page 5, line 20 skipping to change at page 6, line 7
The protocol proceeds as follows. An event occurs triggering station 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 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 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 emitted from station S (either because station S is a host, or
station S is a transit router), but the address resolution could also station S is a transit router), but the address resolution could also
be triggered by other means (a routing protocol update packet, for be triggered by other means (a routing protocol update packet, for
example). Station S first determines the next hop to station D example). Station S first determines the next hop to station D
through normal routing processes (for a host, the next hop may simply 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 be the default router; for routers, this is the "next hop" to the
destination internetwork layer address). If the next hop is destination internetwork layer address). If the next hop is
reachable through its NBMA interface, S constructs an Next Hop reachable through one of its NBMA interfaces, S constructs an Next
Resolution Request packet (see Section 5.2.1) containing station D's Hop Resolution Request packet (see Section 5.2.1) containing station
internetwork layer address as the (target) destination address, S's D's internetwork layer address as the (target) destination address,
own internetwork layer address as the source address (Next Hop S's own internetwork layer address as the source address (Next Hop
Resolution Request initiator), and station S's NBMA addressing Resolution Request initiator), and station S's NBMA addressing
information. Station S may also indicate that it prefers an information. Station S may also indicate that it prefers an
authoritative Next Hop Resolution Reply (i.e., station S only wishes authoritative Next Hop Resolution Reply (i.e., station S only wishes
to receive a Next Hop Resolution Reply from the NHS-speaker that to receive a Next Hop Resolution Reply from the NHS-speaker that
maintains the NBMA-to-internetwork layer address mapping for this maintains the NBMA-to-internetwork layer address mapping for this
destination). Station S emits the Next Hop Resolution Request packet destination). Station S emits the Next Hop Resolution Request packet
towards the destination, using the NBMA address of the next routed towards the destination.
hop.
If the Next Hop Resolution Request is triggered by a data packet, If the Next Hop Resolution Request is triggered by a data packet,
station S may choose to dispose of the data packet while awaiting a station S may choose to dispose of the data packet while awaiting a
Next Hop Resolution Reply in one of the following ways: Next Hop Resolution Reply in one of the following ways:
(a) Drop the packet (a) Drop the packet
(b) Retain the packet until the Next Hop Resolution Reply arrives (b) Retain the packet until the Next Hop Resolution Reply arrives
and a more optimal path is available and a more optimal path is available
(c) Forward the packet along the routed path toward D (c) Forward the packet along the routed path toward D
skipping to change at page 6, line 11 skipping to change at page 6, line 45
When the NHS receives an Next Hop Resolution Request, a check is made When the NHS receives an Next Hop Resolution Request, a check is made
to see if it "serves" station D, i.e., the NHS checks to see if there to see if it "serves" station D, i.e., the NHS checks to see if there
is a "next hop" entry for D in its next-hop resolution cache. If the is a "next hop" entry for D in its next-hop resolution cache. If the
NHS does not serve D, the NHS forwards the Next Hop Resolution NHS does not serve D, the NHS forwards the Next Hop Resolution
Request to another NHS. (Mechanisms for determining how to forward Request to another NHS. (Mechanisms for determining how to forward
the Next Hop Resolution Request are discussed in Section 3, the Next Hop Resolution Request are discussed in Section 3,
Deployment.) Note that NHSs must be next hops to one another in order Deployment.) Note that NHSs must be next hops to one another in order
for forwarding of NHRP packets to be possible. for forwarding of NHRP packets to be possible.
If this NHS serves D, the NHS resolves station D's NBMA address, and If this NHS serves D, the NHS resolves station D's NBMA address, and
generates a positive Next Hop Resolution Reply on D's behalf. (Next generates a positive Next Hop Resolution Reply (denoted by a 0 Code
Hop Resolution Replies in this scenario are always marked as in the reply) on D's behalf. (Next Hop Resolution Replies in this
"authoritative".) The Next Hop Resolution Reply packet contains the scenario are always marked as "authoritative".) The Next Hop
next hop internetwork layer address and the NBMA address for station Resolution Reply packet contains the next hop internetwork layer
D and is sent back to S. (Note that if station D is not on the NBMA address and the NBMA address for station D and is sent back to S.
subnetwork, the next hop internetwork layer address will be that of (Note that if station D is not on the NBMA subnetwork, the next hop
the egress router through which packets for station D are forwarded.) internetwork layer address will be that of the egress router through
which packets for station D are forwarded.)
An NHS receiving a Next Hop Resolution Reply may cache the NBMA next An NHS receiving a Next Hop Resolution Reply may cache the NBMA next
hop information contained therein. To a subsequent Next Hop hop information contained therein. To a subsequent Next Hop
Resolution Request, this NHS may respond with the cached, non- Resolution Request, this NHS may respond with the cached, non-
authoritative, NBMA next hop information or with cached negative authoritative, NBMA next hop information or with cached negative
information, if the NHS is allowed to do so, see section 6.2. Non- information, if the NHS is allowed to do so, see section 5.2.2 and
authoritative Next Hop Resolution Replies are distinguished from 6.2. Non-authoritative Next Hop Resolution Replies are distinguished
authoritative Next Hop Resolution Replies so that if a communication from authoritative Next Hop Resolution Replies so that if a
attempt based on non-authoritative information fails, a source communication attempt based on non-authoritative information fails, a
station can choose to send an authoritative Next Hop Resolution source station can choose to send an authoritative Next Hop
Request. NHSs MUST NOT respond to authoritative Next Hop Resolution Resolution Request. NHSs MUST NOT respond to authoritative Next Hop
Requests with cached information. Resolution Requests with cached information.
[Note: An Next Hop Resolution Reply can be returned directly to the [Note: An Next Hop Resolution Reply can be returned directly to the
Next Hop Resolution Request initiator, i.e., without traversing the Next Hop Resolution Request initiator, i.e., without traversing the
list of NHSs that forwarded the Next Hop Resolution Request, if all list of NHSs that forwarded the Next Hop Resolution Request, if all
of the following criteria are satisfied: of the following criteria are satisfied:
(a) Direct communication is available via datagram transfer (a) Direct communication is available via datagram transfer
(e.g., SMDS) or the NHS has an existing virtual circuit (e.g., SMDS) or the NHS has an existing virtual circuit
connection to the Next Hop Resolution Request initiator or is connection to the Next Hop Resolution Request initiator or is
permitted to open one. permitted to open one.
skipping to change at page 7, line 14 skipping to change at page 7, line 49
The process of forwarding the Next Hop Resolution Request is repeated The process of forwarding the Next Hop Resolution Request is repeated
until the Next Hop Resolution Request is satisfied, or an error until the Next Hop Resolution Request is satisfied, or an error
occurs (e.g., no NHS in the NBMA subnetwork can resolve the Next Hop occurs (e.g., no NHS in the NBMA subnetwork can resolve the Next Hop
Resolution Request.) If the determination is made that station D's Resolution Request.) If the determination is made that station D's
next hop cannot be resolved, a negative Next Hop Resolution Reply next hop cannot be resolved, a negative Next Hop Resolution Reply
(NAK) is returned. This occurs when (a) no next-hop resolution (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 information is available for station D from any NHS, or (b) an NHS is
unable to forward the Next Hop Resolution Request (e.g., connectivity unable to forward the Next Hop Resolution Request (e.g., connectivity
is lost). is lost).
NHRP Registration Requests, NHRP Registration Replies, NHRP Purge NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies,
Requests, NHRP Purge Replies, and NHRP Error Indications follow the and NHRP Error Indications follow the routed path from sender to
routed path from sender to receiver in the same fashion that Next Hop receiver in the same fashion that Next Hop Resolution Requests and
Resolution Requests and Next Hop Resolution Replies do. That is, Next Hop Resolution Replies do. That is, "requests" and
"requests" and "indications" follow the routed path from Source "indications" follow the routed path from Source Protocol Address
Protocol Address (which is the address of the station initiating the (which is the address of the station initiating the communication) to
communication) to the Destination Protocol Address. "Replies", on the Destination Protocol Address. "Replies", on the other hand,
the other hand, follow the routed path from the Destination Protocol follow the routed path from the Destination Protocol Address back to
Address back to the Source Protocol Address with the exceptions the Source Protocol Address with the exceptions mentioned above where
mentioned above where a direct VC may be created. a direct VC may be created. In the case of a NHRP Registration
Reply, the packet is always returned via a direct VC (see Section
5.2.4).
Next Hop Resolution Requests and Next Hop Resolution Replies MUST NOT NHRP Requests and NHRP Replies MUST NOT cross the borders of a
cross the borders of a logical NBMA subnetwork (an explicit NBMA logical NBMA subnetwork (an explicit NBMA subnetwork identifier may
subnetwork identifier may be included as an extension in the Next Hop be included as an extension in the Next Hop Resolution Request, see
Resolution Request, see section 5.3.2). Thus, the internetwork layer section 5.3.2). Thus, the internetwork layer traffic out of and into
traffic out of and into a logical NBMA subnetwork always traverses an a logical NBMA subnetwork always traverses an internetwork layer
internetwork layer router at its border. Internetwork layer router at its border. Internetwork layer filtering can then be
filtering can then be implemented at these border routers. implemented at these border routers.
NHRP optionally provides a mechanism to send a Next Hop Resolution NHRP optionally provides a mechanism to send a Next Hop Resolution
Reply which contains aggregated NBMA next hop information. Suppose Reply which contains aggregated NBMA next hop information. Suppose
that router X is the NBMA next hop from station S to station D. that router X is the NBMA next hop from station S to station D.
Suppose further that X is an egress router for all stations sharing Suppose further that X is an egress router for all stations sharing
an internetwork layer address prefix with station D. When an Next an internetwork layer address prefix with station D. When an Next
Hop Resolution Reply is generated in response to a Next Hop Hop Resolution Reply is generated in response to a Next Hop
Resolution Request, the responder may augment the internetwork layer Resolution Request, the responder may augment the internetwork layer
address of station D with a prefix length (see Section 5.3.1). A address of station D with a prefix length (see Section 5.2.0.1). A
subsequent (non-authoritative) Next Hop Resolution Request for some subsequent (non-authoritative) Next Hop Resolution Request for some
destination that shares an internetwork layer address prefix (for the destination that shares an internetwork layer address prefix (for the
number of bits specified in the prefix length) with D may be number of bits specified in the prefix length) with D may be
satisfied with this cached information. See section 6.2 regarding satisfied with this cached information. See section 6.2 regarding
caching issues. caching issues.
To dynamically detect subnetwork-layer filtering in NBMA subnetworks To dynamically detect subnetwork-layer filtering in NBMA subnetworks
(e.g., X.25 closed user group facility, or SMDS address screens), as (e.g., X.25 closed user group facility, or SMDS address screens), to
well as to provide loop detection and diagnostic capabilities, a trace the routed path that an NHRP packet takes, or to provide loop
"Route Record" may be included in NHRP packets (see Sections 5.3.4 detection and diagnostic capabilities, a "Route Record" may be
and 5.3.5). The Route Record extensions contain the internetwork included in NHRP packets (see Sections 5.3.4 and 5.3.5). The Route
(and subnetwork layer) addresses of all intermediate NHSs between Record extensions contain the internetwork (and subnetwork layer)
source and destination (in the forward direction) and between addresses of all intermediate NHSs between source and destination (in
destination and source (in the reverse direction). When a source the forward direction) and between destination and source (in the
station is unable to communicate with the responder (e.g., an attempt reverse direction). When a source station is unable to communicate
to open an SVC fails), it may attempt to do so successively with with the responder (e.g., an attempt to open an SVC fails), it may
other subnetwork layer addresses in the Route Record until it attempt to do so successively with other subnetwork layer addresses
succeeds (if authentication policy permits such action). This in the Route Record until it succeeds (if authentication policy
approach can find a suitable egress point in the presence of permits such action). This approach can find a suitable egress point
subnetwork-layer filtering (which may be source/destination in the presence of subnetwork-layer filtering (which may be
sensitive, for instance, without necessarily creating separate source/destination sensitive, for instance, without necessarily
logical NBMA subnetworks) or subnetwork-layer congestion (especially creating separate logical NBMA subnetworks) or subnetwork-layer
in connection-oriented media). congestion (especially in connection-oriented media).
3. Deployment 3. Deployment
Next Hop Resolution Requests traverse one or more hops within an NBMA Next Hop Resolution Requests traverse one or more hops within an NBMA
subnetwork before reaching the station that is expected to generate a subnetwork before reaching the station that is expected to generate a
response. Each station, including the source station, chooses a response. Each station, including the source station, chooses a
neighboring NHS to which it will forward the Next Hop Resolution neighboring NHS to which it will forward the Next Hop Resolution
Request. The NHS selection procedure typically involves performing a Request. The NHS selection procedure typically involves applying a
routing decision based upon the network layer destination address of destination protocol layer address to the protocol layer routing
the Next Hop Resolution Request. Ignoring error situations, the Next table which causes a routing decision to be returned. This routing
Hop Resolution Request eventually arrives at a station that is to decision is then used to forward the Next Hop Resolution Request to
generate an Next Hop Resolution Reply. This responding station the downstream NHS. The destination protocol layer address previously
either serves the destination, or is the destination itself if both mentioned is carried within the Next Hop Resolution Request packet.
NHRP client and server functionality are co-resident in the same Note that even though a protocol layer address was used to acquire a
station. The responding station generates a Next Hop Resolution routing decision, NHRP packets are not encapsulated within a protocol
Reply using the source address from within the NHRP packet to layer header but rather are carried at the NBMA layer using the
determine where the Next Hop Resolution Reply should be sent. encapsulation described in Section 5.
The Next Hop Resolution Request packet is carried at the NBMA layer, Each NHS/router examines the Next Hop Resolution Request packet on
with a destination NBMA address set to that of the locally determined its way toward the destination. Each NHS which the NHRP packet
NHS. If the addressed NHS does not serve the destination address traverses on the way to the packet's destination might modify the
specified in the Next Hop Resolution Request, the Next Hop Resolution packet (e.g., updating the Forward Record extension). Ignoring error
Request packet is routed at the network layer based upon the Next Hop situations, the Next Hop Resolution Request eventually arrives at a
Resolution Requester's destination address, and forwarded to the station that is to generate an Next Hop Resolution Reply. This
neighboring NHS determined by the routing decision. Alternately, the responding station "serves" the destination. The responding station
NHS may use static configuration information in order to determine to generates a Next Hop Resolution Reply using the source protocol
which neighboring NHSs to forward the Next Hop Resolution Request address from within the NHRP packet to determine where the Next Hop
packet. Each NHS/router examines the Next Hop Resolution Request Resolution Reply should be sent.
packet on its way toward the destination, optionally modifying it on
the way (such as updating the Forward Record extension), and Rather than use routing to determine the next hop for an NHRP packet,
continues to forward it until it reaches the NHS that serves the an NHS may use static configuration information (or other applicable
destination network layer address. means) in order to determine to which neighboring NHSs to forward the
Next Hop Resolution Request packet. The use of static configuration
information for this purpose is beyond the scope of this document.
In order to forward NHRP packets to a neighboring NHS, NHRP clients In order to forward NHRP packets to a neighboring NHS, NHRP clients
must nominally be configured with the NBMA address of at least one must nominally be configured with the NBMA address of at least one
NHS. In practice, a client's default router should also be its NHS. NHS. In practice, a client's default router should also be its NHS
A client may be able to derive the NBMA address of its NHS from the in that way a client may be able to know the NBMA address of its NHS
configuration that was already required for the client to be able to from the configuration which was already required for the client to
communicate with its next hop router. be able to communicate.
Forwarding of NHRP packets within an NBMA subnetwork requires a
contiguous deployment of NHRP capable stations. During migration to
NHRP, it cannot be expected that all stations within the NBMA
subnetwork are NHRP capable. NHRP traffic which would otherwise need
to be forwarded through such stations can be expected to be dropped
due to the NHRP packet being unrecognized. In this case, NHRP will
be unable to establish any transit paths whose discovery requires the
traversal of the non-NHRP speaking stations. If the client has tried
and failed to acquire a cut through path the the client should use
the network layer routed path as a default.
The path taken by Next Hop Resolution Requests will normally be the
same as the path taken by data packets which are routed at the
network layer to the desired destination. (The paths may be
different in situations where NHSs have been statically configured to
forward traffic by other means. For example, an Next Hop Resolution
Request may be forwarded to a group multicast address.)
NHSs should acquire knowledge about destinations other NHSs serve as
a direct consequence of participating in intra-domain and inter-
domain routing protocol exchange. In this case, 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.
NHSs (and end stations) may alternately be statically configured with
the NBMA addresses of their neighbors, the identities of the
destinations that each of them serves, and optionally a logical NBMA
subnetwork identifier. Such static configurations may be necessary
in cases where NHSs do not contain network layer routing protocol
implementations.
If the NBMA subnetwork offers a link layer group addressing or The NHS serving a particular destination must lie along the routed
multicast feature, the client (station) may be configured with a path to that destination. In practice, this means that all egress
group address assigned to the group of next-hop servers. The client routers must double as NHSs serving the destinations beyond them, and
might then submit Next Hop Resolution Requests to the group address, that hosts on the NBMA subnetwork are served by routers that double
eliciting a response from one or more NHSs, depending on the response as NHSs. Also, this implies that forwarding of NHRP packets within
strategy selected. Note that the constraints described in Section 2 an NBMA subnetwork requires a contiguous deployment of NHRP capable
regarding directly sending Next Hop Resolution Reply may apply. routers. 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.
NHSs may also be deployed with the group or multicast address of If a subnetwork offers a link layer group addressing or multicast
their peers, and an NHS might use this as a means of forwarding Next feature, the client (station) may be configured with a group address
Hop Resolution Requests it cannot satisfy to its peers. This might assigned to the group of next-hop servers. The client might then
elicit a response (to the NHS) from one or more NHSs, depending on submit Next Hop Resolution Requests to the group address, eliciting a
the response strategy. The NHS would then forward the Next Hop response from one or more NHSs, depending on the response strategy
Resolution Reply to the Next Hop Resolution Request originator. The selected. Note that the constraints described in Section 2 regarding
purpose of using group addressing or a similar multicast mechanism in directly sending Next Hop Resolution Reply may apply.
this scenario would be to eliminate the need to preconfigure each NHS
in a logical NBMA subnetwork with both the individual identities of
other NHSs as well as the destinations they serve. It reduces the
number of NHSs that might be traversed to process an Next Hop
Resolution Request (in those configurations where NHSs either respond
or forward via the multicast, only two NHSs would be traversed), and
allows the NHS that serves the Next Hop Resolution Request originator
to cache next hop information associated with the Next Hop Resolution
Reply (again, within the constraints described in Section 2).
4. Configuration 4. Configuration
Stations Clients
To participate in NHRP, a station connected to an NBMA subnetwork To participate in NHRP, a client connected to an NBMA subnetwork
should be configured with the NBMA address(es) of its NHS(s) should be configured with the NBMA address(es) of its NHS(s)
(alternatively, it should be configured with a means of acquiring (alternatively, it should be configured with a means of acquiring
them, i.e., the group address that members of a NHS group use for them, i.e., the group address that members of a NHS group use for
the purpose of address or next-hop resolution.) The NHS(s) will the purpose of address or next-hop resolution.) The NHS(s) will
likely also represent the station's default or peer routers, so likely also represent the client's default or peer routers, so
their NBMA addresses may be obtained from the station's existing their NBMA addresses may be obtained from the client's existing
configuration. If the station is attached to several subnetworks configuration. If the client is attached to several subnetworks
(including logical NBMA subnetworks), the station should also be (including logical NBMA subnetworks), the client should also be
configured to receive routing information from its NHS(s) and peer configured to receive routing information from its NHS(s) and peer
routers so that it can determine which internetwork layer networks routers so that it can determine which internetwork layer networks
are reachable through which subnetworks. are reachable through which subnetworks.
Next Hop Servers Next Hop Servers
An NHS is configured with knowledge of its own internetwork layer An NHS is configured with knowledge of its own internetwork layer
and NBMA addresses, a set of internetwork layer address prefixes and NBMA addresses and a logical NBMA subnetwork identifier (see
that correspond to the internetwork layer addresses of the stations Section 5.3.2). An NHS MAY also be configured with a set of
it serves, and a logical NBMA subnetwork identifier (see Section internetwork layer address prefixes that correspond to the
5.3.2). If a served station is attached to several subnetworks, internetwork layer addresses of the stations it serves. If a served
the NHS may also need to be configured to advertise routing client is attached to several subnetworks, the NHS may also need to
information to such stations. be configured to advertise routing information to such client.
If an NHS acts as an egress router for stations connected to other If an NHS acts as an egress router for stations connected to other
subnetworks than the NBMA subnetwork, the NHS must, in addition to subnetworks than the NBMA subnetwork, the NHS must, in addition to
the above, be configured to exchange routing information between the above, be configured to exchange routing information between
the NBMA subnetwork and these other subnetworks. the NBMA subnetwork and these other subnetworks.
In all cases, routing information is exchanged using conventional In all cases, routing information is exchanged using conventional
intra-domain and/or inter-domain routing protocols. intra-domain and/or inter-domain routing protocols.
The NBMA addresses of the stations served by the NHS may be learned The NBMA addresses of the stations served by the NHS may be learned
via NHRP Register packets or manual configuration. via NHRP Register packets or manual configuration.
5. NHRP Packet Formats 5. NHRP Packet Formats
This section describes the format of NHRP packets. 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 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. Extensions Part. The Fixed Part is common to all NHRP packet types.
The Mandatory Part MUST be present, but varies depending on packet The Mandatory Part MUST be present, but varies depending on packet
type. The Extensions Part also varies depending on packet type, and type. The Extensions Part also varies depending on packet type, and
need not be present. need not be present.
The length of the Fixed Part is fixed at 20 octets. The length of 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 the Mandatory Part is determined by the contents of the extensions
offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part
length is equal to total packet length (ar$pktsz) minus 20 otherwise 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 the mandatory part length is equal to ar$extoff minus 20. The length
of the Extensions Part is implied by ar$pktsz minus ar$extoff minus of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs
20. NHSs may increase the size of an NHRP packet as a result of may increase the size of an NHRP packet as a result of extension
extension processing, but not beyond the offered maximum SDU size of processing, but not beyond the offered maximum SDU size of the NBMA
the NBMA network. network.
NHRP packets are encapsulated using the native formats used on the NHRP packets are encapsulated using the native formats used on the
particular NBMA network over which NHRP is carried. For example, particular NBMA network over which NHRP is carried. For example,
SMDS networks always use LLC/SNAP encapsulation at the NBMA layer, SMDS networks always use LLC/SNAP encapsulation at the NBMA layer,
and an NHRP packet is preceded by the following LLC/SNAP and an NHRP packet is preceded by the following LLC/SNAP
encapsulation: encapsulation:
[0xAA-AA-03] [0x00-00-5E] [0x00-03] [0xAA-AA-03] [0x00-00-5E] [0x00-03]
The first three octets are LLC, indicating that SNAP follows. The The first three octets are LLC, indicating that SNAP follows. The
skipping to change at page 12, line 4 skipping to change at page 12, line 16
NHRP), or uses no encapsulation on VCs dedicated to a single protocol 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 (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 identification of NHRP, using a NLPID of 0x0080 and the same SNAP
contents as above (see [8], [9]). contents as above (see [8], [9]).
Fields marked "unused" MUST be set to zero on transmission, and Fields marked "unused" MUST be set to zero on transmission, and
ignored on receipt. ignored on receipt.
Most packet types (ar$op.type) have both internetwork layer Most packet types (ar$op.type) have both internetwork layer
protocol-independent fields and protocol-specific fields. The protocol-independent fields and protocol-specific fields. The
protocol-independent fields always come first in the packet, and the
protocol type/snap fields (ar$pro.type/snap) qualify the format of protocol type/snap fields (ar$pro.type/snap) qualify the format of
the protocol-specific fields. the protocol-specific fields.
5.1 NHRP Fixed Header 5.1 NHRP Fixed Header
The Fixed Part of the NHRP packet contains those elements of the NHRP 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 packet which are always present and do not vary in size with the type
of packet. of packet.
0 1 2 3 0 1 2 3
skipping to change at page 13, line 32 skipping to change at page 13, line 42
The total length of the NHRP packet, in octets (excluding link The total length of the NHRP packet, in octets (excluding link
layer encapsulation). layer encapsulation).
ar$chksum ar$chksum
The standard IP checksum over the entire NHRP packet (starting with The standard IP checksum over the entire NHRP packet (starting with
the fixed header). If only the hop count field is changed, the the fixed header). If only the hop count field is changed, the
checksum is adjusted without full recomputation. The checksum is checksum is adjusted without full recomputation. The checksum is
completely recomputed when other header fields are changed. completely recomputed when other header fields are changed.
ar$extoff ar$extoff
This field identifies the existence and location NHRP extensions. This field identifies the existence and location of NHRP
If this field is 0 then no extensions exist otherwise this field extensions. If this field is 0 then no extensions exist otherwise
represents the offset from the beginning of the NHRP packet (i.e., this field represents the offset from the beginning of the NHRP
starting from the ar$afn field) of the first extension. packet (i.e., starting from the ar$afn field) of the first
extension.
ar$op.version ar$op.version
This field is set to 0x0001 for NHRP version 1. This field is set to 0x01 for NHRP version 1.
ar$op.type ar$op.type
This is the NHRP packet type: NHRP Next Hop Resolution Request(1), This is the NHRP packet type: NHRP Next Hop Resolution Request(1),
NHRP Next Hop Resolution Reply(2), NHRP Registration Request(3), NHRP Next Hop Resolution Reply(2), NHRP Registration Request(3),
NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Purge NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Purge
Reply(6), or NHRP Error Indication(7). 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.
ar$shtl ar$shtl
Type & length of source NBMA address interpreted in the context of Type & length of source NBMA address interpreted in the context of
the 'address family number'[6] indicated by ar$afn (e.g., the 'address family number'[6] indicated by ar$afn (e.g.,
ar$afn=0x0003 for NSAP, ar$afn=8 for E.164). When ar$afn=0x000F ar$afn=0x0003 for NSAP, ar$afn=8 for E.164). When ar$afn=0x000F
(E.164 address plus NSAP subaddress) then both ar$shtl and ar$sstl (E.164 address plus NSAP subaddress) then both ar$shtl and ar$sstl
must be coded appropriately (see below). must be coded appropriately (see below).
ar$sstl ar$sstl
Type & length of source NBMA subaddress interpreted in the context Type & length of source NBMA subaddress interpreted in the context
skipping to change at page 14, line 40 skipping to change at page 15, line 5
particular NBMA technology. particular NBMA technology.
In the case where the NBMA is ATM, if a subaddress is to be included In the case where the NBMA is ATM, if a subaddress is to be included
then ar$afn MUST be set to 0x000F which means that if a subaddress then ar$afn MUST be set to 0x000F which means that if a subaddress
exists then it is of type NSAP. exists then it is of type NSAP.
The bottom 6 bits is an unsigned integer value indicating the length 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 of the associated NBMA address in octets. If this value is zero the
flag x is ignored. flag x is ignored.
5.2 Mandatory Part 5.2.0 Mandatory Part
The Mandatory Part of the NHRP packet contains the operation specific The Mandatory Part of the NHRP packet contains the operation specific
information (e.g., Next Hop Resolution Request/Reply, etc.) and information (e.g., Next Hop Resolution Request/Reply, etc.) and
variable length data which is pertinent to the packet type. variable length data which is pertinent to the packet type.
5.2.1 NHRP Next Hop Resolution Request 5.2.0.1 Mandatory Part Format
The NHRP Next Hop Resolution Request packet has a Type code of 1. The Sections 5.2.1 through 5.2.6 have a very similar mandatory part.
Mandatory Part has the following format: 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
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 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 |Q|A|P|B| unused | | Src Proto Len | Dst Proto Len | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | | Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) | | Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) | | Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) | | Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) | | Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Src Proto Len
This field holds the length in octets of the Source Protocol This field holds the length in octets of the Source Protocol
Address. Address.
Dst Proto Len Dst Proto Len
This field holds the length in octets of the Destination Protocol This field holds the length in octets of the Destination Protocol
Address. Address.
NHRP Next Hop Resolution Request/Reply Flags Flags
These flags are specific to the given message type and they are
Q explained in each section.
Set if the station sending the Next Hop Resolution Request is a
router; clear if the it is a host.
A
A response to a Next Hop Resolution Request may contain cached
information. If an authoritative answer is desired, then this bit
("Authoritative") should be set. If non-authoritative (cached)
information is acceptable, this bit should be clear.
P
Unused (clear on transmit)
B
Unused (clear on transmit)
Request ID Request ID
A value which, when coupled with the address of the source, A value which, when coupled with the address of the source,
provides a unique identifier for the information contained in a provides a unique identifier for the information contained in a
Next Hop Resolution Request and its associated Next Hop Resolution "request" packet. This value is copied directly from an "request"
Reply, and any subsequent Purge. This value can be used by the packet into the associated "reply". When a sender of a "request"
source to aid in matching a Next Hop Resolution Request with a Next receives "reply", it will compare the Request ID and source address
Hop Resolution Reply. This value could also be sent across a information in the received "reply" against that found in its
virtual circuit (in SVC environments) to aid in matching NHRP outstanding "request" list. When a match is found then the
transactions with virtual circuits (this use is for further study). "request" is considered to be acknowledged.
The value is taken from a 32 bit counter that is incremented each The value is taken from a 32 bit counter that is incremented each
time a new Next Hop Resolution Request is transmitted. The same time a new "request" is transmitted. The same value MUST be used
value MUST be used when sending another Next Hop Resolution Request when resending a "request", i.e., when a "reply" has not been
for the same destination when a previous Next Hop Resolution received for a "request" and a retry is sent after an appropriate
Request is still active or pending, i.e., when retransmitting a interval.
Next Hop Resolution Request because a Next Hop Resolution Reply was
not received, or when refreshing an existing entry to avoid holding
timer expiration. A new value MUST be used when sending a Next Hop
Resolution Request when no cache entry is present, or a previous
cache entry was deleted for any reason.
Maximum Transmission Unit
This field gives the maximum transmission unit for the target
station. This field is ignored in Next Hop Resolution Requests and
should be set to 0. A possible use of this field in the Next Hop
Resolution Request packet is for the Next Hop Resolution Requester
to ask for a target MTU. This use is for further study.
Holding Time The NBMA address/subaddress form specified below allows combined
The Holding Time field specifies the number of seconds for which E.164/NSAPA form of NBMA addressing. For NBMA technologies without a
the client NBMA information (the information of the client issuing subaddress concept, the subaddress field is always ZERO length and
the Next Hop Resolution Request) is considered to be valid. The ar$sstl = 0.
contents of this field along with the source address information
MAY be cached by transit NHSs. The holding time should be set to
the remaining time left in the client's registration with its
server. If this field is set to 0 then transit NHSs MUST not cache
the client's NBMA information.
Source NBMA Address Source NBMA Address
The Source NBMA address field is the address of the source station The Source NBMA address field is the address of the source station
which is sending the Next Hop Resolution Request. If the field's which is sending the "request". If the field's length as specified
length as specified in ar$shtl is 0 then no storage is allocated in ar$shtl is 0 then no storage is allocated for this address at
for this address at all. all.
Source NBMA SubAddress Source NBMA SubAddress
The Source NBMA subaddress field is the address of the source The Source NBMA subaddress field is the address of the source
station which is sending the Next Hop Resolution Request. If the station which is sending the "request". If the field's length as
field's length as specified in ar$sstl is 0 then no storage is specified in ar$sstl is 0 then no storage is allocated for this
allocated for this address at all. address at all.
Source Protocol Address Source Protocol Address
This is the protocol address of the station which is sending the This is the protocol address of the station which is sending the
Next Hop Resolution Request. "request". This is also the protocol address of the station toward
which a "reply" packet is sent.
Destination Protocol Address Destination Protocol Address
This is the protocol address of the station for which the NBMA next This is the protocol address of the station toward which a
hop is desired. "request" packet is sent.
(The NBMA address/subaddress form allows combined E.164/NSAPA form of Code
NBMA addressing. For NBMA technologies without a subaddress concept, This field is message specific. See the relevant message sections
the subaddress field is always ZERO length and ar$sstl = 0.) 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.
5.2.2 NHRP Next Hop Resolution Reply 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 the 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.
The NHRP Next Hop Resolution Reply packet has a type code of 2. The Maximum Transmission Unit
Mandatory Part has the following format: 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.
0 1 2 3 Holding Time
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 The Holding Time field specifies the number of seconds for which
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the Next Hop NBMA information specified in the CIE is considered to
| Src Proto Len | Dst Proto Len |Q|A|P|B| unused | be valid. Cached information SHALL be discarded when the holding
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ time expires. This field must be set to 0 on a NAK.
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH Addr T/L | NH SAddr T/L | NH Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src Proto Len Cli Addr T/L
This field holds the length in octets of the Source Protocol Type & length of next hop NBMA address specified in the CIE. This
Address. field is interpreted in the context of the 'address family
number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM).
Dst Proto Len Cli SAddr T/L
This field holds the length in octets of the Destination Protocol Type & length of next hop NBMA subaddress specified in the CIE.
Address. 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.
Next Hop Resolution Request/Reply Flags 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 SHOULD NOT cache source information which is in an
NHRP message because this information could be inappropriately used
to set up a cut-through without doing proper filtering along a routed
path. Further, in the case where a distributed router exists in the
network, incorrect or incomplete information may be included in the
source information.
5.2.1 NHRP Next Hop Resolution Request
The NHRP Next Hop 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:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|B|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q
Set if the station sending the Next Hop Resolution Request is a
router; clear if the it is a host.
A
This bit is set in a Next Hop Resolution Request if only
authoritative next hop information is desrired and is clear
otherwise. See the NHRP Next Hop Resolution Reply section below
for further details on the "A" bit and its usage.
B
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.
Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP
Next Hop Resolution Request. If one is specified then that entry
carries the pertinent information for the client sourcing the NHRP
Next Hop Resolution Request. Usage of the CIE in the NHRP Next Hop
Resolution Request is described below:
Prefix Length
If a CIE is specified in the NHRP Next Hop Resolution Request
then the Prefix Length field may be used to qualify the widest
acceptable prefix which may be used to satisfy the NHRP Next Hop
Resolution Request. In the case of NHRP Next Hop 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 this field is set to
0x00 then this field MUST be ignored. 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 Next Hop Resolution
Request packet is for the Next Hop Resolution Requester to ask
for a target MTU. In lieu of that usage, the CIE must be omitted.
All other fields in the CIE MUST be ignored and SHOULD be set to 0.
5.2.2 NHRP Next Hop Resolution Reply
The NHRP Next Hop 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 Next Hop 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:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|B|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q Q
Copied from the Next Hop Resolution Request. Set if the Next Hop Copied from the Next Hop Resolution Request. Set if the Next Hop
Resolution Requester is a router; clear if it is a host. Resolution Requester is a router; clear if it is a host.
A A
Set if the next hop in the Next Hop Resolution Reply is Set if the next hop CIE in the Next Hop Resolution Reply is
authoritative; clear if the Next Hop Resolution Reply is non- authoritative; clear if the Next Hop Resolution Reply is non-
authoritative. authoritative.
P When an NHS receives a Next Hop Resolution Request for
Set if the Next Hop Resolution Reply is positive; clear if the authoritative information for which it is the authoritative
Next Hop Resolution Reply is negative. source, it MUST respond with a Next Hop 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 Next Hop
Resolution Request and are authoritative cache entries. An NHS
is an authoritative source for a Next Hop Resolution Request if
the information in the NHS's cache matches the Next Hop
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-authoriative CIEs through promiscuous
listening to NHRP packets other than NHRP Registrations which are
directed at it. A Next Hop Resolution Request which indicates a
request for non-authoritative information should cause a Next Hop
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.
B B
Set if the association between the destination and the next hop Set if the association between the destination and the next hop
information is guaranteed to be stable for the lifetime of the information is guaranteed to be stable for the lifetime of the
information (the holding time). This is the case if the Next Hop information (the holding time). This is the case if the Next Hop
protocol address identifies the destination (though it may be protocol address identifies the destination (though it may be
different in value than the Destination address if the different in value than the Destination address if the
destination system has multiple addresses) or if the destination destination system has multiple addresses) or if the destination
is not connected directly to the NBMA subnetwork but the egress is not connected directly to the NBMA subnetwork but the egress
router to that destination is guaranteed to be stable (such as router to that destination is guaranteed to be stable (such as
when the destination is immediately adjacent to the egress router when the destination is immediately adjacent to the egress router
through a non-NBMA interface). This information affects caching through a non-NBMA interface). This information affects caching
strategies (see section 6.2). strategies (see section 6.2).
An NHS is not allowed to send a Next Hop Resolution Reply to an U
Next Hop Resolution Request for authoritative information with This is the Uniqueness bit. See the NHRP Resolution Request
cached information, but may do so for an NHRP Next Hop Resolution section above for details. When this bit is set only, only one
Request which indicates a request for non-authoritative CIE is included since only one unique binding should exist in an
information. An NHS may send an Next Hop Resolution Reply to an NHS's cache.
Next Hop Resolution Request for non-authoritative information with
authoritative information.
Request ID
A value which, when coupled with the address of the source,
provides a unique identifier for the information contained in a
Next Hop Resolution Request and its associated Next Hop Resolution
Reply, and any subsequent Purge. This value can be used by the
source to aid in matching a Next Hop Resolution Request with a Next
Hop Resolution Reply. This value could also be sent across a
virtual circuit (in SVC environments) to aid in matching NHRP
transactions with virtual circuits (this use is for further study).
The value is taken from a 32 bit counter that is incremented each
time a new Next Hop Resolution Request is transmitted. The same
value MUST be used when sending another Next Hop Resolution Request
for the same destination when a previous Next Hop Resolution
Request is still active or pending, i.e., when retransmitting a
Next Hop Resolution Request because a Next Hop Resolution Reply was
not received, or when refreshing an existing entry to avoid holding
timer expiration. A new value MUST be used when sending a Next Hop
Resolution Request when no cache entry is present, or a previous
cache entry was deleted for any reason.
Maximum Transmission Unit
This field gives the maximum transmission unit for the Next Hop
information supplied in the mandatory part of the packet. 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 mandatory part of
the packet 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.
NH Addr T/L
Type & length of next hop NBMA address specified in the mandatory
part of the packet. This field is interpreted in the context of the
'address family number'[6] indicated by ar$afn (e.g., ar$afn=0x0003
for ATM).
NH SAddr T/L
Type & length of next hop NBMA subaddress specified in the
mandatory part of the packet. 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.
NH Proto Len
This field holds the length in octets of the Next Hop Protocol
Address specified in the mandatory part of the packet (additional
next hop entries may be specified in the Additional Next Hop
Entries Extension (see Section 5.2.9)).
Preference
This field specifies the preference of the Next Hop entry specified
in the mandatory part of the packet. This preference value is
relative to other Next Hop entries in this NHRP Next Hop Resolution
Reply packet which may be by the Additional Next Hop Entries
Extension (see Section 5.3.9) for the given internetworking
protocol. Higher values indicate higher preference. Action taken
when multiple next hop entries have the highest preference value is
a local matter. Set to 0 on a NAK.
Source NBMA Address One or more CIEs are specified in the NHRP Next Hop Resolution Reply.
The Source NBMA address field is the address of the source station Each CIE contains NHRP next hop information which the responding NHS
which sent the Next Hop Resolution Request. If the field's length has cached and which matches the parameters specified in the NHRP
as specified in ar$shtl is 0 then no storage is allocated for this Next Hop Resolution Request. If no match is found by the NHS issuing
address at all. the NHRP Next Hop 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.
Source NBMA SubAddress Code
The Source NBMA subaddress field is the address of the source If this field is set to zero then this packet contains a
station which sent the Next Hop Resolution Request. If the field's positively acknowledged NHRP Resolution Reply. If this field
length as specified in ar$sstl is 0 then no storage is allocated contains any other value then this message contains an NHRP
for this address at all. 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:
Source Protocol Address 12 - No Internetworking Layer Address to NBMA Address Binding
This is the protocol address of the station which sent the Next Hop Exists
Resolution Request.
Destination Protocol Address This code states that there were absolutely no internetworking
This is the protocol address of the station for which the NBMA next layer address to NBMA address bindings found in the responding
hop is desired. NHS's cache.
(The NBMA address/subaddress form allows combined E.164/NSAPA form 13 - Binding Exists But Is Not Unique
of NBMA addressing. For NBMA technologies without a subaddress
concept, the subaddress field is always ZERO length and ar$sstl =
0.)
The following is the Next Hop entry as specified in the Mandatory This code states that there were one or more internetworking
Part of the packet: layer address to NBMA address bindings found in the responding
NHS's cache, however none of them had the uniqueness bit set.
Next Hop NBMA Address Prefix Length
This is the NBMA address of the station that is the next hop for In the case of NHRP Next Hop Resolution Reply, the Prefix Length
packets bound for the internetworking layer address specified. specifies the equivalence class of addresses which match the
first "Prefix Length" bit positions of the Destination Protocol
Address.
Next Hop NBMA SubAddress Holding Time
This is the NBMA subaddress of the station that is the next hop The Holding Time specified in a CIE of an NHRP Resolution Reply
for packets bound for the internetworking layer address is the amount of time remaining before the expiration of the
specified. client information which is cached at the replying NHS. It is
not the value which was registered by the client.
Next Hop Protocol Address The remainder of the fields for the CIE for each next hop are
This internetworking layer address specifies the next hop. This filled out as they were defined when the next hop was registered
will be the address of the destination host if it is directly with the responding NHS (or one of the responding NHS's
attached to the NBMA subnetwork, or the egress router if it is synchronized servers) via the NHRP Registration Request.
not directly attached.
There may be multiple Next Hop entries returned in the Next Hop Load-splitting may be performed when more than one Client Information
Resolution Reply by including the Additional Next Hop Entries Entry is returned to a requester when equal preference values are
Extension. See Section 5.3.9 for use of these entries. The most specified. Also, the alternative addresses may be used in case of
preferable Next Hop must be specified in the mandatory part of the connectivity failure in the NBMA subnetwork (such as a failed call
Next Hop Resolution Reply. attempt in connection-oriented NBMA subnetworks).
Any extensions present in the Next Hop Resolution Request packet MUST Any extensions present in the Next Hop Resolution Request packet MUST
be present in the NHRP Next Hop Resolution Reply packet, except for be present in the NHRP Next Hop Resolution Reply even if the
the case of unrecognized non-Compulsory extensions. extension is non-Compulsory.
If an unsolicited NHRP Next Hop Resolution Reply packet is received, If an unsolicited NHRP Next Hop Resolution Reply packet is received,
an Error Indication of type Invalid Next Hop Resolution Reply an Error Indication of type Invalid Next Hop Resolution Reply
Received SHOULD be sent in response. Received SHOULD be sent in response.
5.2.3 NHRP Registration Request 5.2.3 NHRP Registration Request
The NHRP Registration Request is sent from a station to an NHS to 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 notify the NHS of the station's NBMA information. It has a Type code
of 3. The Mandatory Part has the following format: 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:
0 1 2 3 Flags - The flags field is coded as follows:
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 | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Register Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src Proto Len 0 1
This field holds the length in octets of the Source Protocol 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Address. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dst Proto Len U
This field holds the length in octets of the Destination Protocol This is the Uniqueness bit. When set in an NHRP Registration
Address. Request, this bit indicates that the registration of the protocol
address is unique within the confines of the set of synchronized
NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC
cache. Any attempt to register a binding between the protocol
address and an NBMA address when this bit is set MUST be rejected
with a Code of "14 - Unique Internetworking Layer Address Already
Registered" if the replying NHS already has a cache entry for the
protocol address and the cache entry has the "uniqueness" bit
set. A registration of a CIE's information is rejected when the
CIE is returned with the Code field set to anything other than
0x00. See the description of the uniqueness bit in NHRP
Resolution Request section above for further details. When this
bit is set only, only one CIE MAY be included in the NHRP
Registration Request.
Request ID Request ID
A value which, when coupled with the address of the source, The request ID has the same meaning as described in Section
provides a unique identifier for the information contained in an 5.2.0.1. However, the request ID for NHRP Registrations which is
NHRP Registration Request packet. This value is copied directly maintained at each client MUST be kept in non-volatile memory so
from an NHRP Registration Request packet into the associated that when a client crashes and reregisters there will be no
Registration Reply. This value could also be sent across a virtual inconsistency in the NHS's database. In order to reduce the
circuit (in SVC environments) to aid in matching the NHRP overhead associated with updating non-volatile memory, the actual
transactions with virtual circuits (this use is for further study). updating need not be done with every increment of the Request ID
but could be done, for example, every 50 or 100 increments. In
Register Holding Time this scenario, when a client crashes and reregisters it knows to
The Register Holding Time field specifies the number of seconds for add 100 to the value of the Request ID in the non-volatile memory
which the registered NBMA information is considered to be valid. before using the Request ID for subsequent registrations.
Cached information SHALL be discarded when the holding time
expires.
Source NBMA Address One or more CIEs are specified in the NHRP Registration Request.
The Source NBMA address field is the address of the source station Each CIE contains next hop information which a client is attempting
which is sending the NHRP Registration Request. to register with its servers. Generally, all fields in CIEs enclosed
in NHRP Registration Requests are coded as described in Section
5.2.0.1. However, if a station is only registering itself with the
NHRP Registration Request then it MAY code the Cli Addr T/L, Cli
SAddr T/L, and Cli Proto Len as zero which signifies that the client
address information is to be taken from the source information in the
common header (see Section 5.2.0.1). Below, further clarification is
given for some fields in a CIE in the context of a NHRP Registration
Request.
Source NBMA SubAddress Code
The Source NBMA subaddress field is the address of the source This field is set to 0x00 in NHRP Registration Requests.
station which is sending the NHRP Registration Request. If the
field's length as specified in ar$sstl is 0 then no storage is
allocated for this address at all.
Source Protocol Address Prefix Length
This is the protocol address of the station which is sending the
NHRP Registration Request.
Destination Protocol Address This field may be used in a NHRP Registration Request to register
This is the protocol address of the NHS for which the source NBMA equivalence information for the Client Protocol Address specified
next hop information is being registered. in the CIE of an NHRP Registration Request In the case of NHRP
Registration Request, the Prefix Length specifies the equivalence
class of addresses which match the first "Prefix Length" bit
positions of the Client Protocol Address. If this field is set
to 0x00 then this field MUST be ignored and no equivalence
information is assumed (i.e., only Client Protocol Address is
bound to the NBMA information). If the "U" bit is set in the
common header then this field MUST be set to 0xFF.
This packet is used to register a station's Protocol and NBMA This packet is used to register a station's NHRP information with its
addresses with its NHSs, as configured or known through conventional NHSs, as configured or known through conventional routing means.
routing means. This allows static configuration information to be NHSs may also be configured with the identities of stations that they
reduced; the NHSs need not be configured with the identities of all serve. If an NHS receives an NHRP Registration Request packet which
of the stations that they serve. If an NHS receives an NHRP has the Destination Protocol Address field set to an address other
Registration Request packet for a station that it does not serve and than the NHS's own protocol address then the NHS MUST forward the
that packet has a Destination Protocol Address which is not the packet along the routed path toward the Destination Protocol Address.
protocol address of the NHS that is currently inspecting the packet
then the NHS inspecting the packet MUST forward the registration
along the routed path to the Destination Protocol Address.
It is possible that a misconfigured station will attempt to register It is possible that a misconfigured station will attempt to register
with the wrong NHS (i.e., one that cannot serve it due to policy with the wrong NHS (i.e., one that cannot serve it due to policy
constraints or routing state). If this is the case, the NHS MUST constraints or routing state). If this is the case, the NHS MUST
reply with a NAK-ed Registration Reply of type Can't Serve This reply with a NAK-ed Registration Reply of type Can't Serve This
Address. Address.
If an NHS cannot serve a station due to a lack of resources, the NHS If an NHS cannot serve a station due to a lack of resources, the NHS
MUST reply with a NAK-ed Registration Reply of type Registration MUST reply with a NAK-ed Registration Reply of type Registration
Overflow. Overflow.
skipping to change at page 23, line 25 skipping to change at page 25, line 41
In order to keep the registration entry from being discarded, the In order to keep the registration entry from being discarded, the
station MUST re-send the NHRP Registration Request packet often station MUST re-send the NHRP Registration Request packet often
enough to refresh the registration, even in the face of occasional enough to refresh the registration, even in the face of occasional
packet loss. It is recommended that the NHRP Registration Request packet loss. It is recommended that the NHRP Registration Request
packet be sent at an interval equal to one-third of the Holding Time packet be sent at an interval equal to one-third of the Holding Time
specified therein. specified therein.
5.2.4 NHRP Registration Reply 5.2.4 NHRP Registration Reply
The NHRP Registration Reply is sent by an NHS to a client in response The NHRP Registration Reply is sent by an NHS to a client in response
to that client's NHRP Registration Request. If the NAK Code field has to that client's NHRP Registration Request. If the Code field of a
anything other than 0 zero in it then the NHRP Registration Reply is CIE in the NHRP Registration Reply has anything other than 0 zero in
a NAK otherwise the reply is an ACK. The NHRP Registration Reply has it then the NHRP Registration Reply is a NAK otherwise the reply is
a Type code of 4. Its mandatory part has the following format: an ACK. The NHRP Registration Reply has a Type code of 4.
0 1 2 3 An NHRP Registration Reply is formed from an NHRP Registration
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 Request by changing the type code to 4, updating the CIE Code field,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and filling in the appropriate extensions if they exist. The message
| Src Proto Len | Dst Proto Len | unused | specific meanings of the fields are as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK Code | unused | Register Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src Proto Len Attempts to register the information in the CIEs of an NHRP
This field holds the length in octets of the Source Protocol Registration Request may fail for various reasons. If this is the
Address. case then each failed attempt to register the information in a CIE of
an NHRP Registration Request is logged in the associated NHRP
Registration Reply by setting the CIE Code field to the appropriate
error code as shown below:
Dst Proto Len CIE Code
This field holds the length in octets of the Destination Protocol
Address.
Request ID 0 - Successful Registration
A value which, when coupled with the address of the source,
provides a unique identifier for the information contained in an
NHRP Registration Reply packet. This value is copied directly from
an NHRP Registration Request packet into the associated NHRP
Registration Reply. This value could also be sent across a virtual
circuit (in SVC environments) to aid in matching NHRP transactions
with virtual circuits (this use is for further study).
NAK Code The information in the CIE was sucessfully registered with the
If this field is set to zero then this packet contains a positively NHS.
acknowledged NHRP Registration Reply. If this field contains any
other value then this contains an NHRP Registration Reply NAK which
means that the internetworking layer to NBMA address binding was
not stored at the client's NHS. Currently defined NAK Codes are as
follows:
4 - Can't Serve This Address 4 - Can't Serve This Address
An NHS may refuse an NHRP Registration Request attempt for An NHS may refuse an NHRP Registration Request attempt for
administrative reasons. If so, the NHS MUST send an NHRP administrative reasons (due to policy constraints or routing
Registration Reply which contains a NAK code of 4. state). If so, the NHS MUST send an NHRP Registration Reply
which contains a NAK code of 4.
5 - Registration Overflow 5 - Registration Overflow
If an NHS cannot serve a station due to a lack of resources, If an NHS cannot serve a station due to a lack of resources,
the NHS MUST reply with a NAKed NHRP Registration Reply which the NHS MUST reply with a NAKed NHRP Registration Reply which
contains a NAK code of 5. contains a NAK code of 5.
Register Holding Time 14 - Unique Internetworking Layer Address Already Registered
The Register Holding Time field specifies the number of seconds for If a client tries to register a protocol address to NBMA
which the registered NBMA information is considered to be valid. address binding with the uniqueness bit on and the protocol
Cached information SHALL be discarded when the holding time address already exists in the NHS's cache then if that cache
expires. entry also has the uniqueness bit on then this NAK Code is
returned in the CIE in the NHRP Registration Reply.
Source NBMA Address
The Source NBMA address field is the address of the source station
which sent the Next Hop Registration Request.
Source NBMA SubAddress
The Source NBMA subaddress field is the subaddress of the source
station which sent the Next Hop Registration Request. If the
field's length as specified in ar$sstl is 0 then no storage is
allocated for this address at all.
Source Protocol Address Due to the possible existence of asymmetric routing, an NHRP
This is the protocol address of the station which sent the NHRP Registration Reply may not be able to merely follow the routed path
back to the source protocol address specified in the common header of
the NHRP Registration Reply. As a result, there MUST exist a direct
NBMA level connection between the client and its NHS on which to send
the NHRP Registration Reply before NHRP Registration Reply may be
returned to the client. If such a connection does not exist then the
NHS must setup such a connection to he client by using the source
NBMA information supplied in the common header of the NHRP
Registration Request. Registration Request.
Destination Protocol Address
This is the protocol address of the NHS in which the client is
attempting to register the client's NBMA information.
This packet is used to register a station's Protocol and NBMA
addresses with its neighboring NHSs, as configured or known through
conventional routing means. This allows static configuration
information to be reduced; the NHSs need not be configured with the
identities of all of the stations that they serve. If an NHS receives
an NHRP Registration Request packet for a station that it does not
serve and that packet has a Destination Protocol Address which is not
the protocol address of the NHS that is currently inspecting the
packet then the NHS inspecting the packet MUST forward the
registration along the routed path to the Destination Protocol
Address.
It is possible that a misconfigured station will attempt to send a
Next Hop Registration Request to the wrong NHS (i.e., one that cannot
serve it due to policy constraints or routing state). If this is the
case, the NHS MUST reply with a NAK-ed NHRP Registration Reply of
type Can't Serve This Address.
If an NHS cannot serve a station due to a lack of resources, the NHS
MUST reply with a NAK-ed NHRP Registration Reply of type Registration
Overflow.
In order to keep the client's registration entry in the client's NHS
from being timed out, the station MUST re-send the NHRP Registration
Request packet often enough to refresh the registration entry, even
in the face of occasional packet loss. It is recommended that the
NHRP Registration Request packet be sent at an interval equal to
one-third of the Holding Time specified therein.
5.2.5 NHRP Purge Request 5.2.5 NHRP Purge Request
The NHRP Purge Request packet is sent in order to invalidate cached The NHRP Purge Request packet is sent in order to invalidate cached
information in a station. The NHRP Purge Request packet has a type information in a station. The NHRP Purge Request packet has a type
code of 5. The Mandatory Part has the following format: code of 5. The mandatory part of an NHRP Purge Request is coded as
described in Section 5.2.0.1. The message specific meanings of the
0 1 2 3 fields are as follows:
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 |Trgt Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src Proto Len Flags - The flags field is coded as follows:
This field holds the length in octets of the Source Protocol
Address.
Dst Proto Len 0 1
This field holds the length in octets of the Destination Protocol 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Address. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trgt Proto Len N
This field holds the length in octets of the Target Protocol When set, this bit tells the receiver of the NHRP Purge Request
Address. that the requester does not expect to receive an NHRP Purge
Reply. If an unsolicited NHRP Purge Reply is received by a
station where that station is identified in the Source Protocol
Address of the packet then that packet must be ignored.
Source NBMA Address One or more CIEs are specified in the NHRP Purge Request. Each CIE
The Source NBMA address field is the address of the source station contains next hop information which is to be purged from an NHS/NHC
which is sending the NHRP Purge Request. cache. Generally, all fields in CIEs enclosed in NHRP Purge Requests
are coded as described in Section 5.2.0.1. Below, further
clarification is given for some fields in a CIE in the context of a
NHRP Purge Request.
Source NBMA SubAddress Code
The Source NBMA subaddress field is the address of the source This field is set to 0x00 in NHRP Purge Requests.
station which is sending the NHRP Purge Request. If its length as
specified in ar$sstl is 0 then no storage is allocated for this
address at all.
Source Protocol Address Prefix Length
The address of the station which is sending the NHRP Purge Request.
Destination Protocol Address In the case of NHRP Purge Requests, the Prefix Length specifies
The address of the station that will be receiving the NHRP Purge the equivalence class of addresses which match the first "Prefix
Request. Length" bit positions of the Client Protocol Address specified in
the CIE. All next hop information which contains a protocol
address which matches an element of this equivalence class is to
be purged from the receivers cache. If this field is set to 0x00
then this field MUST be ignored and no equivalence information is
assumed.
Target Protocol Address The Maximum Transmission Unit and Preference fields of the CIE are
The address which is to be purged from the receiver's database. coded as zero. The Holding Time should be coded as zero but there
may be some utility in supplying a "short" holding time to be
applied to the matching next hop information before that
information would be purged; this usage is for further study. The
Client Protocol Address field and the Cli Proto Len field MUST be
filled in. The Client Protocol Address is filled in with the
protocol address to be purged from the receiving station's cache
while the Cli Proto Len is set the length of the purged client's
protocol address. All remaining fields in the CIE MAY be set to
zero although the client NBMA information (and associated length
fields) MAY be specified to narrow the scope of the NHRP Purge
Request if requester desires. However, the receiver of an NHRP
Purge Request may choose to ignore the Client NBMA information if
it is supplied.
An NHRP Purge Request packet is sent from an NHS to a station to An NHRP Purge Request packet is sent from an NHS to a station to
cause it to delete previously cached information. This is done when cause it to delete previously cached information. This is done when
the information may be no longer valid (typically when the NHS has the information may be no longer valid (typically when the NHS has
previously provided next hop information for a station that is not previously provided next hop information for a station that is not
directly connected to the NBMA subnetwork, and the egress point to directly connected to the NBMA subnetwork, and the egress point to
that station may have changed). that station may have changed).
An NHRP Purge Request packet may also be sent from a client to an NHS An NHRP Purge Request packet may also be sent from a client to an NHS
with which the client had previously registered. This allows for a with which the client had previously registered. This allows for a
client to invalidate it's registration with NHRP before it would client to invalidate its registration with NHRP before it would
otherwise expire via the holding timer. otherwise expire via the holding timer.
The station sending the NHRP Purge Request MAY periodically The station sending the NHRP Purge Request MAY periodically
retransmit the NHRP Purge Request until either NHRP Purge Request is retransmit the NHRP Purge Request until either NHRP Purge Request is
acknowledged or until the holding time of the information being acknowledged or until the holding time of the information being
purged has expired. Retransmission strategies are for further purged has expired. Retransmission strategies for NHRP Purge
investigation. Requests are a local matter.
When a station receives an NHRP Purge Request, it MUST discard any When a station receives an NHRP Purge Request, it MUST discard any
previously cached information that matches the Target Protocol previously cached information that matches the information in the
Address. CIEs.
An NHRP Purge Reply MUST be returned for the NHRP Purge Request even An NHRP Purge Reply MUST be returned for the NHRP Purge Request even
if the station does not have a matching cache entry. if the station does not have a matching cache entry assuming that the
"N" bit is off in the NHRP Purge Request.
If the station wishes to reestablish communication with the If the station wishes to reestablish communication with the
destination shortly after receiving an NHRP Purge Request, it should destination shortly after receiving an NHRP Purge Request, it should
make an authoritative Next Hop Resolution Request in order to avoid make an authoritative Next Hop Resolution Request in order to avoid
any stale cache entries that might be present in intermediate NHSs any stale cache entries that might be present in intermediate NHSs
(See section 6.2.2.). It is recommended that authoritative Next Hop (See section 6.2.2.). It is recommended that authoritative Next Hop
Resolution Requests be made for the duration of the holding time of Resolution Requests be made for the duration of the holding time of
the old information. the old information.
5.2.6 NHRP Purge Reply 5.2.6 NHRP Purge Reply
The NHRP Purge Reply packet is sent in order to assure the sender of The NHRP Purge Reply packet is sent in order to assure the sender of
an NHRP Purge Request that all cached information of the specified an NHRP Purge Request that all cached information of the specified
type has been purged from the station sending the reply. The NHRP type has been purged from the station sending the reply. The NHRP
Purge packet has a type code of 6. The Mandatory Part has the Purge Reply has a type code of 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len |Trgt Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Trgt Proto Len
This field holds the length in octets of the Target Protocol
Address.
Source NBMA Address
The Source NBMA address field is the address of the source station
which sent the NHRP Purge Request.
Source NBMA SubAddress
The Source NBMA subaddress field is the address of the source
station which sent the NHRP Purge Request. If its length as
specified in ar$sstl is 0 then no storage is allocated for this
address at all.
Source Protocol Address
The address of the station which sent the NHRP Purge Request.
Destination Protocol Address
The address of the station which is sending the NHRP Purge Reply.
Target Protocol Address
The address which is to be purged from the receiver's database.
An NHRP Purge Request packet is sent from an NHS to a station to
cause it to delete previously cached information. This is done when
the information may be no longer valid (typically when the NHS has
previously provided next hop information for a station that is not
directly connected to the NBMA subnetwork, and the egress point to
that station may have changed).
An NHRP Purge Request packet may also be sent from a client to an NHS
with which the client had previously registered. This allows for a
client to invalidate it's registration with NHRP before it would
otherwise expire via the holding timer.
The station sending the NHRP Purge Request MAY periodically
retransmit the NHRP Purge Request until it is acknowledged, or until
the holding time of the information being purged has expired.
Retransmission strategies are for further investigation.
When a station receives an NHRP Purge Request, it MUST discard any
previously cached information that matches the Target Protocol
Address.
An NHRP Purge Reply MUST be returned as a result of receiving an NHRP
Purge Request even if the station does not have a matching cache
entry.
If the station wishes to reestablish communication with the An NHRP Purge Reply is formed from an NHRP Purge Request by merely
destination shortly after receiving an NHRP Purge Request, it should changing the type code in the request to 6. The packet is then
make an authoritative Next Hop Resolution Request in order to avoid returned to the requester after filling in the appropriate extensions
any stale cache entries that might be present in intermediate NHSs. if they exist.
(See section 6.2.2.) It is recommended that authoritative Next Hop
Resolution Requests be made for the duration of the holding time of
the old information.
5.2.7 NHRP Error Indication 5.2.7 NHRP Error Indication
The NHRP Error Indication is used to convey error indications to the The NHRP Error Indication is used to convey error indications to the
sender of an NHRP packet. It has a type code of 6. The Mandatory sender of an NHRP packet. It has a type code of 7. The Mandatory
Part has the following format: Part has the following format:
0 1 2 3 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 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 | unused | | Src Proto Len | Dst Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error Offset | | Error Code | Error Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) | | Source NBMA Address (variable length) |
skipping to change at page 31, line 4 skipping to change at page 30, line 16
extension, it SHALL ignore the extension. extension, it SHALL ignore the extension.
2 - Subnetwork ID Mismatch 2 - Subnetwork ID Mismatch
This error occurs when the current station receives an NHRP This error occurs when the current station receives an NHRP
packet whose NBMA subnetwork identifier matches none of the packet whose NBMA subnetwork identifier matches none of the
locally known identifiers for the NBMA subnetwork on which the locally known identifiers for the NBMA subnetwork on which the
packet is received. packet is received.
3 - NHRP Loop Detected 3 - NHRP Loop Detected
A Loop Detected error is generated when it is determined that A Loop Detected error is generated when it is determined that
an NHRP packet is being forwarded in a loop. an NHRP packet is being forwarded in a loop.
6 - Protocol Address Unreachable
This error occurs when a packet it moving along the routed path
and it reaches a point such that the protocol address of
interest is not reachable.
7 - Protocol Error
A generic packet processing error has occurred (e.g., invalid
version number, invalid protocol type, failed checksum, etc.)
8 - NHRP SDU Size Exceeded 8 - NHRP SDU Size Exceeded
If the SDU size of the NHRP packet exceeds the maximum SDU size If the SDU size of the NHRP packet exceeds the MTU size of the
of the NBMA network, this error is returned. NBMA network then this error is returned.
9 - Invalid Extension 9 - Invalid Extension
If an NHS finds an extension in a packet which is inappropriate If an NHS finds an extension in a packet which is inappropriate
for the packet type, an error is sent back to the sender with for the packet type, an error is sent back to the sender with
Invalid Extension as the code. Invalid Extension as the code.
10- Invalid Next Hop Resolution Reply Received 10- Invalid Next Hop Resolution Reply Received
If a client receives a Next Hop Resolution Reply for a Next Hop If a client receives a Next Hop Resolution Reply for a Next Hop
Resolution Request which it believes it did not make then an Resolution Request which it believes it did not make then an
error packet is sent to the station making the reply with an error packet is sent to the station making the reply with an
error code of Invalid Reply Received. error code of Invalid Reply Received.
11- Authentication Failure
If a received packet fails an authentication test then this
error is returned.
14- Hop Count Exceeded
The hop count which was specified in the Fixed Header of an
NHRP message has been exceeded.
Error Offset Error Offset
The offset in octets into the NHRP packet, starting at the NHRP The offset in octets into the NHRP packet, starting at the NHRP
Fixed Header, at which the error was detected. Fixed Header, at which the error was detected.
Source NBMA Address Source NBMA Address
The Source NBMA address field is the address of the station which The Source NBMA address field is the address of the station which
observed the error. observed the error.
Source NBMA SubAddress Source NBMA SubAddress
The Source NBMA subaddress field is the address of the station The Source NBMA subaddress field is the address of the station
skipping to change at page 32, line 15 skipping to change at page 31, line 48
If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA
and Source Protocol address fields of a transiting NHRP Error and Source Protocol address fields of a transiting NHRP Error
Indication packet then the NHS will quietly drop the packet and do Indication packet then the NHS will quietly drop the packet and do
nothing (this scenario would occur when the NHRP Error Indication nothing (this scenario would occur when the NHRP Error Indication
packet was itself in a loop). packet was itself in a loop).
Note that no extensions may be added to an NHRP Error Indication. Note that no extensions may be added to an NHRP Error Indication.
5.3 Extensions Part 5.3 Extensions Part
In the following, unless otherwise stated explicitly, the term
"request" refers generically to any of the NHRP packet types which
are "requests". Also, unless otherwise stated explicitly, the term
"reply" refers generically to any of the NHRP packet types which are
"replies".
The Extensions Part, if present, carries one or more extensions in The Extensions Part, if present, carries one or more extensions in
{Type, Length, Value} triplets. Extensions are only present in a {Type, Length, Value} triplets. Extensions are only present in a
"reply" if they were present in the corresponding "request"; "reply" if they were present in the corresponding "request";
therefore, minimal NHRP station implementations that do not act as an therefore, minimal NHRP client implementations which do not also act
NHS and do not transmit extensions need not be able to receive as an NHS and do not transmit extensions need not be able to receive
extensions. An implementation that is incapable of processing extensions. The previous statement is not intended to preclude the
extensions SHALL return an NHRP Error Indication of type Unrecognized creation of NHS-only extensions which might be added to and removed
Extension when it receives an NHRP packet containing extensions. from NHRP packets by the same NHS; such extensions MUST not be
propagated to clients. An implementation that is incapable of
processing extensions SHALL return an NHRP Error Indication of type
Unrecognized Extension when it receives an NHRP packet containing
extensions.
Extensions have the following format: Extensions have the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|u| Type | Length | |C|u| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 41 skipping to change at page 33, line 26
If a transit NHS (one which is not going to generate a "reply") If a transit NHS (one which is not going to generate a "reply")
detects an unrecognized extension, it SHALL ignore the extension. If detects an unrecognized extension, it SHALL ignore the extension. If
the Compulsory bit is set, the transit NHS MUST NOT cache the the Compulsory bit is set, the transit NHS MUST NOT cache the
information contained in the packet and MUST NOT identify itself as information contained in the packet and MUST NOT identify itself as
an egress router (in the Forward Record or Reverse Record an egress router (in the Forward Record or Reverse Record
extensions). Effectively, this means, if a transit NHS encounters an extensions). Effectively, this means, if a transit NHS encounters an
extension which it cannot process and which has the Compulsory bit extension which it cannot process and which has the Compulsory bit
set then that NHS MUST NOT participate in any way in the protocol set then that NHS MUST NOT participate in any way in the protocol
exchange other than acting as a forwarding agent. exchange other than acting as a forwarding agent.
Use of NHRP extension Types in the range 8192 to 16383 are reserved
for research or use in other protocol development and will be
administered by IANA.
5.3.0 The End Of Extensions 5.3.0 The End Of Extensions
Compulsory = 1 Compulsory = 1
Type = 0 Type = 0
Length = 0 Length = 0
When extensions exist, the extensions list is terminated by the End When extensions exist, the extensions list is terminated by the End
Of Extensions/Null TLV. Of Extensions/Null TLV.
5.3.1 Destination Prefix Length 5.3.1 Extension with Type 1 not assigned.
Compulsory = 0
Type = 1
Length = 1
This extension is used to indicate that the information carried in an
NHRP packet 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.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the case of an Next Hop Resolution Request, if equivalence
information is desired from the Next Hop Resolution Reply then the
Destination Prefix Length extension is included in the Next Hop
Resolution Request and the Prefix Length value is coded as 0xffff.
For the Next Hop Resolution Reply, the Prefix Length is set to the
length of the prefix of the Next Hop Protocol Address present in the
mandatory part of the packet.
In the case of an NHRP Registration Request, if equivalence
information is desired to be registered then the Destination Prefix
Length extension is included in the NHRP Registration Request with
the Prefix Length value set to the length of the prefix of the
equivalence information for the Source Protocol Address. In Next Hop
Registration Reply, the Destination Prefix Length extension is merely
copied unchanged.
In the case of an Next Hop Purge Request, if equivalence information
is desired then the Prefix Length value is set to the length of the
prefix of the Target Protocol Address which represents the
equivalence information to be purged. In Next Hop Purge Reply, the
Destination Prefix Length extension is merely copied unchanged.
5.3.2 NBMA Subnetwork ID Extension 5.3.2 NBMA Subnetwork ID Extension
Compulsory = 1 Compulsory = 1
Type = 2 Type = 2
Length = variable Length = variable
This extension is used to carry one or more identifiers for the NBMA This extension is used to carry one or more identifiers for the NBMA
subnetwork. This can be used as a validity check to ensure that an subnetwork. This can be used as a validity check to ensure that an
NHRP packet does not leave a particular NBMA subnetwork. The NHRP packet does not leave a particular NBMA subnetwork. The
extension is placed in a "request" packet with an ID value of zero. extension is placed in a "request" packet with an ID value of zero.
The first NHS along the routed path fills in the field with the The first NHS along the routed path fills in the field with the
identifier(s) for the NBMA subnetwork. identifier(s) for the NBMA subnetwork.
Multiple NBMA Subnetwork IDs may be used as a transition mechanism Multiple NBMA Subnetwork IDs may be used as a transition mechanism
while NBMA Subnetworks are being split or merged. while NBMA Subnetworks are being split or merged.
skipping to change at page 35, line 46 skipping to change at page 34, line 40
When an NHS is building a "reply" and the NBMA Subnetwork ID When an NHS is building a "reply" and the NBMA Subnetwork ID
extension is present in the correspond "request" then the NBMA extension is present in the correspond "request" then the NBMA
Subnetwork ID extension SHALL be copied from the "request" to the Subnetwork ID extension SHALL be copied from the "request" to the
"reply". "reply".
5.3.3 Responder Address Extension 5.3.3 Responder Address Extension
Compulsory = 1 Compulsory = 1
Type = 3 Type = 3
Length = 4 Length = variable
This extension is used to determine the address of the NHRP This extension is used to determine the address of the NHRP
responder; i.e., the entity that generates the appropriate "reply" responder; i.e., the entity that generates the appropriate "reply"
packet for a given "request" packet. In the case of an Next Hop packet for a given "request" packet. In the case of an Next Hop
Resolution Request, the station responding may be different (in the Resolution Request, the station responding may be different (in the
case of cached replies) than the system identified in the Next Hop case of cached replies) than the system identified in the Next Hop
field of the Next Hop Resolution Reply. Further, this extension may field of the Next Hop Resolution Reply. Further, this extension may
aid in detecting loops in the NHRP forwarding path. aid in detecting loops in the NHRP forwarding path.
0 1 2 3 0 1 2 3
skipping to change at page 43, line 31 skipping to change at page 42, line 18
The remaining octets after the Vendor ID in the payload are The remaining octets after the Vendor ID in the payload are
vendor-dependent data. vendor-dependent data.
This extension may be added to any "request" or "reply" packet and it This extension may be added to any "request" or "reply" packet and it
is the only extension that may be included multiple times. If the is the only extension that may be included multiple times. If the
receiver does not handle this extension, or does not match the Vendor receiver does not handle this extension, or does not match the Vendor
ID in the extension then the extension may be completely ignored by ID in the extension then the extension may be completely ignored by
the receiver. If a Vendor Private Extension is included in a the receiver. If a Vendor Private Extension is included in a
"request" then is must be copied in the corresponding "reply". "request" then is must be copied in the corresponding "reply".
5.3.9 Additional Next Hop Entries Extension 5.3.9 Extension with Type 9 not assigned.
Compulsory = 0
Type = 9
Length = variable
This extension may be used to return multiple Next Hop entries in a
single NHRP Reply packet. This extension MUST only be used for
positive replies. The preference values are used to specify the
relative preference of the entries contained in the extension. The
same next Hop Protocol address may be associated with multiple NBMA
addresses. Load-splitting may be performed over the addresses, given
equal preference values, and 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).
The following shows the format for additional Next Hop Entries:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH Addr T/L | NH SAddr T/L | NH Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH Addr T/L | NH SAddr T/L | NH Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An NHS is not allowed to reply to an NHRP request for authoritative
information with cached information, but may do so for an NHRP
Request which indicates a request for non-authoritative information.
An NHS may reply to an NHRP request for non-authoritative information
with authoritative information.
Maximum Transmission Unit
This field gives the maximum transmission unit for the target
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 Next Hop Entry 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.
NH Addr T/L
Type & length of next hop NBMA address specified in the Next Hop
Entry. This field is interpreted in the context of the 'address
family number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for
ATM).
NH SAddr T/L
Type & length of next hop NBMA subaddress specified in the Next Hop
Entry. 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.
NH Proto Len
This field holds the length in octets of the Next Hop Protocol
Address specified in the Next Hop Entry.
Preference
This field specifies the preference of the specific Next Hop Entry
relative to other Next Hop entries in this Next Hop Resolution
Reply mandatory part or in the Additional Next Hop Entries
Extension for the given internetworking protocol. Higher values
indicate higher preference. Action taken when multiple next hop
entries have the highest preference value is a local matter.
Next Hop NBMA Address
This is the NBMA address of the station that is the next hop for
packets bound for the internetworking layer address specified.
Next Hop NBMA SubAddress
This is the NBMA subaddress of the station that is the next hop for
packets bound for the internetworking layer address specified.
Next Hop Protocol Address
This internetworking layer address specifies the next hop. This
will be the address of the destination host if it is directly
attached to the NBMA subnetwork, or the egress router if it is not
directly attached.
6. Protocol Operation 6. Protocol Operation
In this section, we discuss certain operational considerations of In this section, we discuss certain operational considerations of
NHRP. NHRP.
6.1 Router-to-Router Operation 6.1 Router-to-Router Operation
In practice, the initiating and responding stations may be either In practice, the initiating and responding stations may be either
hosts or routers. However, there is a possibility under certain hosts or routers. However, there is a possibility under certain
skipping to change at page 48, line 21 skipping to change at page 44, line 43
If the source of a Next Hop Resolution Request is a host and the If the source of a Next Hop Resolution Request is a host and the
destination is not directly attached to the NBMA subnetwork, and destination is not directly attached to the NBMA subnetwork, and
the route to that destination is not considered to be "stable," the the route to that destination is not considered to be "stable," the
destination mapping may be very dynamic (except in the case of a destination mapping may be very dynamic (except in the case of a
subnetwork where each destination is only singly homed to the NBMA subnetwork where each destination is only singly homed to the NBMA
subnetwork). As such the cached information may very likely become subnetwork). As such the cached information may very likely become
stale. The consequence of stale information in this case will be a stale. The consequence of stale information in this case will be a
suboptimal path (unless the internetwork has partitioned or some suboptimal path (unless the internetwork has partitioned or some
other routing failure has occurred). other routing failure has occurred).
Strategies for maintaining NHRP cache information in the presence 6.3 Use of the Prefix Length field of a CIE
of dynamic routing changes will be discussed in a separate
document.
6.3 Use of the Destination Prefix Length Extension
A certain amount of care needs to be taken when using the Destination A certain amount of care needs to be taken when using the Prefix
Prefix Length Extension, in particular with regard to the prefix Length field of a CIE, in particular with regard to the prefix length
length advertised (and thus the size of the equivalence class advertised (and thus the size of the equivalence class specified by
specified by it). Assuming that the routers on the NBMA subnetwork it). Assuming that the routers on the NBMA subnetwork are exchanging
are exchanging routing information, it should not be possible for an routing information, it should not be possible for an NHS to create a
NHS to create a black hole by advertising too large of a set of black hole by advertising too large of a set of destinations, but
destinations, but suboptimal routing (e.g., extra internetwork layer suboptimal routing (e.g., extra internetwork layer hops through the
hops through the NBMA) can result. To avoid this situation an NHS NBMA) can result. To avoid this situation an NHS that wants to send
that wants to send the Destination Prefix Length Extension MUST obey the Prefix Length MUST obey the following rule:
the following rule:
The NHS examines the Network Layer Reachability Information (NLRI) The NHS examines the Network Layer Reachability Information (NLRI)
associated with the route that the NHS would use to forward towards associated with the route that the NHS would use to forward towards
the destination (as specified by the Destination internetwork layer the destination (as specified by the Destination internetwork layer
address in the Next Hop Resolution Request), and extracts from this address in the Next Hop Resolution Request), and extracts from this
NLRI the shortest address prefix such that: (a) the Destination NLRI the shortest address prefix such that: (a) the Destination
internetwork layer address (from the Next Hop Resolution Request) internetwork layer address (from the Next Hop Resolution Request)
is covered by the prefix, (b) the NHS does not have any routes with is covered by the prefix, (b) the NHS does not have any routes with
NLRI that forms a subset of what is covered by the prefix. The NLRI that forms a subset of what is covered by the prefix. The
prefix may then be used for the Destination Prefix Length prefix may then be used in the CIE.
Extension.
The NHRP Destination Prefix Length Extension should be used with The Prefix Length field of the CIE should be used with restraint, in
restraint, in order to avoid NHRP stations choosing suboptimal order to avoid NHRP stations choosing suboptimal transit paths when
transit paths when overlapping prefixes are available. This overlapping prefixes are available. This document specifies the use
extension SHOULD only be used in a Next Hop Resolution Reply when of the prefix length only when all the destinations covered by the
either: prefix are "stable". That is, either:
(a) All destinations covered by the prefix are on the NBMA network, or (a) All destinations covered by the prefix are on the NBMA network, or
(b) All destinations covered by the prefix are directly attached to (b) All destinations covered by the prefix are directly attached to
the NHRP responding station. the NHRP responding station.
For other cases, there may be no single optimal transit path for Use of the Prefix Length field of the CIE in other circumstances is
destinations encompassed by the address prefix, and an NHRP station outside the scope of this document.
may fail to choose the optimal transit path simply because it is not
aware of all such paths. So for cases not covered by (a) and (b), an
Next Hop Resolution Reply packet should not include the NHRP
Destination Prefix Length Extension.
6.4 Domino Effect 6.4 Domino Effect
One could easily imagine a situation where a router, acting as an One could easily imagine a situation where a router, acting as an
ingress station to the NBMA subnetwork, receives a data packet, such ingress station to the NBMA subnetwork, receives a data packet, such
that this packet triggers an Next Hop Resolution Request. If the that this packet triggers an Next Hop Resolution Request. If the
router forwards this data packet without waiting for an NHRP transit router forwards this data packet without waiting for an NHRP transit
path to be established, then when the next router along the path path to be established, then when the next router along the path
receives the packet, the next router may do exactly the same - receives the packet, the next router may do exactly the same -
originate its own Next Hop Resolution Request (as well as forward the originate its own Next Hop Resolution Request (as well as forward the
packet). In fact such a data packet may trigger Next Hop Resolution packet). In fact such a data packet may trigger Next Hop Resolution
Request generation at every router along the path through an NBMA Request generation at every router along the path through an NBMA
subnetwork. We refer to this phenomena as the NHRP "domino" effect. subnetwork. We refer to this phenomena as the NHRP "domino" effect.
The NHRP domino effect is clearly undesirable. At best it may result The NHRP domino effect is clearly undesirable. At best it may result
in excessive NHRP traffic. At worst it may result in an excessive in excessive NHRP traffic. At worst it may result in an excessive
number of virtual circuits being established unnecessarily. number of virtual circuits being established unnecessarily.
Therefore, it is important to take certain measures to avoid or Therefore, it is important to take certain measures to avoid or
suppress this behavior. NHRP implementations for NHSs MUST provide a suppress this behavior. NHRP implementations for NHSs MUST provide a
mechanism to address this problem. It is recommended that mechanism to address this problem. One possible strategy to address
implementations provide one or more of the following solutions. this problem would be to configure a router in such a way that Next
Hop Resolution Request generation by the router would be driven only
Possibly the most straightforward solution for suppressing the domino by the traffic the router receives over its non-NBMA interfaces
effect would be to require transit routers to be preconfigured not to (interfaces that are not attached to an NBMA subnetwork). Traffic
originate Next Hop Resolution Requests for data traffic which is received by the router over its NBMA-attached interfaces would not
simply being forwarded (not originated). In this case the routers trigger NHRP Next Hop Resolution Requests. Such a router avoids the
avoid the domino effect through an administrative policy. NHRP domino effect through administrative means.
A second possible solution would be to require that when a router
forwards an Next Hop Resolution Request, the router instantiates a
(short-lived) state. This state consists of the route that was used
to forward the Next Hop Resolution Request. If the router receives a
data packet, and the packet triggers an Next Hop Resolution Request
generation by the router, the router checks whether the route to
forward the Next Hop Resolution Request was recently used to forward
some other Next Hop Resolution Request. If so, then the router
suppresses generation of the new Next Hop Resolution Request (but
still forwards the data packet). This solution also requires that
when a station attempts to originate an Next Hop Resolution Request
the station should send the Next Hop Resolution Request before the
data packet that triggered the origination of the Next Hop Resolution
Request. Otherwise, unnecessary Next Hop Resolution Requests may
still be generated.
A third possible strategy would be to configure a router in such a 7. NHRP over Legacy BMA Networks
way that Next Hop Resolution Request generation by the router would
be driven only by the traffic the router receives over its non-NBMA
interfaces (interfaces that are not attached to an NBMA subnetwork).
Traffic received by the router over its NBMA-attached interfaces
would not trigger NHRP Next Hop Resolution Requests. Just as in the
first case, such a router avoids the NHRP domino effect through
administrative means.
Lastly, rate limiting of Next Hop Resolution Requests may help to There would appear to be no significant impediment to running NHRP
avoid the NHRP domino effect. Intermediate routers which would over legacy broadcast subnetworks. There may be issues around
otherwise generate unnecessary Next Hop Resolution Requests may running NHRP across multiple subnetworks. Running NHRP on broadcast
instead suppress such Next Hop Resolution Requests due to the media has some interesting possibilities; especially when setting up
measured Next Hop Resolution Request rate exceeding a certain a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both
threshold. Of course, such rate limiting would have to be very end stations are legacy attached. This use for NHRP requires further
aggressive in order to completely avoid the domino effect. Further research.
work is needed to analyze this solution.
7. Security Considerations 8. Security Considerations
As in any routing protocol, there are a number of potential security As in any routing protocol, there are a number of potential security
attacks possible. Plausible examples include denial-of-service attacks possible. Plausible examples include denial-of-service
attacks, and masquerade attacks using register and purge packets. attacks, and masquerade attacks using register and purge packets.
The use of authentication on all packets is recommended to avoid such The use of authentication on all packets is recommended to avoid such
attacks. attacks.
The authentication schemes described in this document are intended to The authentication schemes described in this document are intended to
allow the receiver of a packet to validate the identity of the allow the receiver of a packet to validate the identity of the
sender; they do not provide privacy or protection against replay sender; they do not provide privacy or protection against replay
attacks. attacks.
Detailed security analysis of this protocol is for further study. Detailed security analysis of this protocol is for further study.
8. Discussion 9. Discussion
The result of an Next Hop Resolution Request depends on how routing The result of an Next Hop Resolution Request depends on how routing
is configured among the NHSs of an NBMA subnetwork. If the is configured among the NHSs of an NBMA subnetwork. If the
destination station is directly connected to the NBMA subnetwork and destination station is directly connected to the NBMA subnetwork and
the the routed path to it lies entirely within the NBMA subnetwork, the the routed path to it lies entirely within the NBMA subnetwork,
the Next Hop Resolution Replies always return the NBMA address of the the Next Hop Resolution Replies always return the NBMA address of the
destination station itself rather than the NBMA address of some destination station itself rather than the NBMA address of some
egress router. On the other hand, if the routed path exits the NBMA egress router. On the other hand, if the routed path exits the NBMA
subnetwork, NHRP will be unable to resolve the NBMA address of the subnetwork, NHRP will be unable to resolve the NBMA address of the
destination, but rather will return the address of the egress router. destination, but rather will return the address of the egress router.
skipping to change at page 51, line 27 skipping to change at page 47, line 18
the NBMA next hop or just send the packets to one of its the NBMA next hop or just send the packets to one of its
connectionless servers. The latter option may be desirable if connectionless servers. The latter option may be desirable if
communication with the destination is short-lived and/or doesn't communication with the destination is short-lived and/or doesn't
require much network resources. The connectionless servers could, of require much network resources. The connectionless servers could, of
course, be physically integrated in the NHSs by augmenting them with course, be physically integrated in the NHSs by augmenting them with
internetwork layer switching functionality. internetwork layer switching functionality.
References References
[1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh
Govindan, draft-ietf-rolc-nbma-arp-00.txt. Govindan, RFC1735.
[2] Address Resolution Protocol, David C. Plummer, RFC 826. [2] Address Resolution Protocol, David C. Plummer, RFC 826.
[3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577.
[4] Transmission of IP datagrams over the SMDS service, J. Lawrence [4] Transmission of IP datagrams over the SMDS service, J. Lawrence
and D. Piscitello, RFC 1209. and D. Piscitello, RFC 1209.
[5] Protocol Identification in the Network Layer, ISO/IEC TR [5] Protocol Identification in the Network Layer, ISO/IEC TR
9577:1990. 9577:1990.
skipping to change at page 52, line 5 skipping to change at page 47, line 41
[7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen, [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen,
RFC1483. RFC1483.
[8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode,
A. Malis, D. Robinson, and R. Ullmann, RFC1356. A. Malis, D. Robinson, and R. Ullmann, RFC1356.
[9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and
A. Malis, RFC1490. A. Malis, RFC1490.
[10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks,
Yakov Rekhter, Dilip Kandlur, RFCxxxx.
Acknowledgments Acknowledgments
We would like to thank Juha Heinenan of Telecom Finland and Ramesh We would like to thank Juha Heinenan of Telecom Finland and Ramesh
Govidan of ISI for their work on NBMA ARP and the original NHRP Govidan of ISI for their work on NBMA ARP and the original NHRP
draft, which served as the basis for this work. John Burnett of draft, which served as the basis for this work. Russell Gardo of
Adaptive, Dennis Ferguson of ANS, Joel Halpern of Newbridge, Paul IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Joel Halpern
Francis of NTT, Tony Li and Yakov Rekhter of cisco, and Grenville of Newbridge, Paul Francis of NTT, Tony Li and Yakov Rekhter of
Armitage of Bellcore should also be acknowledged for comments and cisco, and Grenville Armitage of Bellcore should also be acknowledged
suggestions that improved this work substantially. We would also for comments and suggestions that improved this work substantially.
like to thank the members of the Routing Over Large Clouds working We would also like to thank the members of the ION working group of
group of the IETF, whose review and discussion of this document have the IETF, whose review and discussion of this document have been
been invaluable. invaluable.
Authors' Addresses Authors' Addresses
Dave Katz David Piscitello James V. Luciani Dave Katz
cisco Systems Core Competence Bay Networks cisco Systems
170 W. Tasman Dr. 1620 Tuckerstown Road 3 Federal Street 170 W. Tasman Dr.
San Jose, CA 95134 USA Dresher, PA 19025 USA Mail Stop: BL3-04 San Jose, CA 95134 USA
Billerica, MA 01821 Phone: +1 408 526 8284
Phone: +1 408 526 8284 Phone: +1 215 830 0692 Phone: +1 508 439 4737 Email: dkatz@cisco.com
Email: dkatz@cisco.com Email: dave@corecom.com Email: luciani@baynetworks.com
Bruce Cole James V. Luciani
cisco Systems Ascom Nexion
170 W. Tasman Dr. 289 Great Road
San Jose, CA 95134 USA Acton, MA 01720-4379 USA
Phone: +1 408 526 4000 Phone: +1 508 266 3450 David Piscitello Bruce Cole
Email: bcole@cisco.com Email: luciani@nexen.com Core Competence cisco Systems
1620 Tuckerstown Road 170 W. Tasman Dr.
Dresher, PA 19025 USA San Jose, CA 95134 USA
Phone: +1 215 830 0692Phone: Phone: +1 408 526 4000
Email: dave@corecom.comEmail: Email: bcole@cisco.com
 End of changes. 130 change blocks. 
945 lines changed or deleted 764 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/