draft-ietf-rolc-nhrp-06.txt   draft-ietf-rolc-nhrp-07.txt 
Routing over Large Clouds Working Group Dave Katz Routing over Large Clouds Working Group Dave Katz
INTERNET-DRAFT (cisco Systems) INTERNET-DRAFT (cisco Systems)
<draft-ietf-rolc-nhrp-06.txt> David Piscitello <draft-ietf-rolc-nhrp-07.txt> David Piscitello
(Core Competence, Inc.) (Core Competence, Inc.)
Bruce Cole Bruce Cole
(cisco Systems) (cisco Systems)
James V. Luciani James V. Luciani
(Ascom Nexion) (Ascom Nexion)
November 1995
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 1, line 37 skipping to change at page 1, line 35
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
Abstract Abstract
This document describes the NBMA Next Hop Resolution Protocol (NHRP). This document describes the NBMA Next Hop Resolution Protocol (NHRP).
NHRP can be used by a source station (host or router) connected to a NHRP can be used by a source station (host or router) connected to a
Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the IP and Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
NBMA subnetwork addresses of the "NBMA next hop" towards a internetworking layer address and NBMA subnetwork addresses of the
destination station. If the destination is connected to the NBMA "NBMA next hop" towards a destination station. If the destination is
subnetwork, then the NBMA next hop is the destination station itself. connected to the NBMA subnetwork, then the NBMA next hop is the
Otherwise, the NBMA next hop is the egress router from the NBMA destination station itself. Otherwise, the NBMA next hop is the
subnetwork that is "nearest" to the destination station. Although egress router from the NBMA subnetwork that is "nearest" to the
this document focuses on NHRP in the context of IP, the technique is destination station. NHRP is intended for use in a multiprotocol
applicable to other internetwork layer protocols (e.g., IPX, CLNP, internetworking layer environment over NBMA subnetworks.
Appletalk) as well.
This document is intended to be a functional superset of the NBMA This document is intended to be a functional superset of the NBMA
Address Resolution Protocol (NARP) documented in [1]. Address Resolution Protocol (NARP) documented in [1].
Operation of NHRP as a means of establishing a transit path across an Operation of NHRP as a means of establishing a transit path across an
NBMA subnetwork between two routers will be addressed in a separate NBMA subnetwork between two routers will be addressed in a separate
document. document.
1. Introduction 1. Introduction
The NBMA Next Hop Resolution Protocol (NHRP) allows a source station The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
(a host or router), wishing to communicate over a Non-Broadcast, (a host or router), wishing to communicate over a Non-Broadcast,
Multi-Access (NBMA) subnetwork, to determine the IP and NBMA Multi-Access (NBMA) subnetwork, to determine the internetworking
addresses of the "NBMA next hop" toward a destination station. A layer addresses and NBMA addresses of suitable "NBMA next hops"
subnetwork can be non-broadcast either because it technically doesn't toward a destination station. A subnetwork can be non-broadcast
support broadcasting (e.g., an X.25 subnetwork) or because either because it technically doesn't support broadcasting (e.g., an
broadcasting is not feasible for one reason or another (e.g., an SMDS X.25 subnetwork) or because broadcasting is not feasible for one
multicast group or an extended Ethernet would be too large). If the reason or another (e.g., an SMDS multicast group or an extended
destination is connected to the NBMA subnetwork, then the NBMA next Ethernet would be too large). If the destination is connected to the
hop is the destination station itself. Otherwise, the NBMA next hop NBMA subnetwork, then the NBMA next hop is the destination station
is the egress router from the NBMA subnetwork that is "nearest" to itself. Otherwise, the NBMA next hop is the egress router from the
the destination station. NBMA subnetwork that is "nearest" to the destination station.
An NBMA subnetwork may, in general, consist of multiple logically An NBMA subnetwork may, in general, consist of multiple Local Address
independent IP subnets (LISs), defined in [3] and [4] as having the Groups (LAGs). In the case of IP, a logically independent IP subnet
following properties: (LIS) is an example of a LAG. LISs, as defined in [3] and [4], have
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.
IP routing described in [3] and [4] only resolves the next hop Address resolution as described in [3] and [4] only resolves the next
address if the destination station is a member of the same LIS as the hop address if the destination station is a member of the same LIS as
source station; otherwise, the source station must forward packets to the source station; otherwise, the source station must forward
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 IP routing may not be sufficient to configurations, hop-by-hop address resolution may not be sufficient
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 traverse the NBMA subnetwork more than once.
NHRP describes a routing method that relaxes the forwarding NHRP describes a next hop resolution method that relaxes the
restrictions of the LIS model. With NHRP, once the NBMA next hop has forwarding restrictions of the LIS model. With NHRP when the
internetwork layer address is of type IP, once the NBMA next hop has
been resolved, the source may either start sending IP packets to the been resolved, the source may either start sending IP packets to the
destination (in a connectionless NBMA subnetwork such as SMDS) or may destination (in a connectionless NBMA subnetwork such as SMDS) or may
first establish a connection to the destination with the desired 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 IP-to-NBMA-address NHRP in its most basic form provides a simple internetworking layer
binding service. This may be sufficient for hosts which are directly to NBMA subnetwork layer address binding service. This may be
connected to an NBMA subnetwork, allowing for straightforward sufficient for hosts which are directly connected to an NBMA
implementations in NBMA stations. NHRP also has the capability of subnetwork, allowing for straightforward implementations in NBMA
determining the egress point from an NBMA subnetwork when the stations. NHRP also has the capability of determining the egress
destination is not directly connected to the NBMA subnetwork and the point from an NBMA subnetwork when the destination is not directly
identity of the egress router is not learned by other methods (such connected to the NBMA subnetwork and the identity of the egress
as routing protocols). Optional extensions to NHRP provide router is not learned by other methods (such as routing protocols).
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 4, line 26 skipping to change at page 4, line 29
answering Next Hop Resolution Requests are known as "Next Hop answering Next Hop Resolution Requests are known as "Next Hop
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 (IP-to-NBMA address). This table can be constructed address mappings (internetwork layer address to NBMA subnetwork layer
from information gleaned from NHRP Register packets (see Section address). This table can be constructed from information gleaned from
5.2.3 and 5.2.4), extracted from Next Hop Resolution Requests or NHRP Register packets (see Section 5.2.3 and 5.2.4), extracted from
replies that traverse the NHS as they are forwarded, or through Next Hop Resolution Requests/Replies that traverse the NHS as they
mechanisms outside the scope of this document (examples of such are forwarded, or through mechanisms outside the scope of this
mechanisms include ARP [2, 3, 4] and pre-configured tables). Section document (examples of such mechanisms include ARP [2, 3, 4] and pre-
6.2 further describes cache management issues. configured tables). Section 6.2 further describes cache management
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
identity for NHSs, i.e., addressing information that would solicit a identity for NHSs, i.e., addressing information that would solicit a
response from "all NHSs". The means whereby a group of NHSs divide response from "all NHSs". The means whereby a group of NHSs divide
responsibilities for next hop resolution are not described here.] responsibilities for next hop resolution are not described here.]
skipping to change at page 5, line 15 skipping to change at page 5, line 19
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 IP address). If the next hop is reachable through its destination internetwork layer address). If the next hop is
NBMA interface, S constructs an Next Hop Resolution Request packet reachable through its NBMA interface, S constructs an Next Hop
(see Section 5.2.1) containing station D's IP address as the (target) Resolution Request packet (see Section 5.2.1) containing station D's
destination address, S's own IP address as the source address (Next internetwork layer address as the (target) destination address, S's
Hop Resolution Request initiator), and station S's NBMA addressing own internetwork layer address as the source address (Next Hop
Resolution Request initiator), and station S's NBMA addressing
information. Station S may also indicate that it prefers an information. Station S may also indicate that it prefers an
authoritative reply (i.e., station S only wishes to receive a reply authoritative Next Hop Resolution Reply (i.e., station S only wishes
from the NHS-speaker that maintains the NBMA-to-IP address mapping to receive a Next Hop Resolution Reply from the NHS-speaker that
for this destination). Station S emits the Next Hop Resolution maintains the NBMA-to-internetwork layer address mapping for this
Request packet towards the destination, using the NBMA address of the destination). Station S emits the Next Hop Resolution Request packet
next routed hop. towards the destination, using the NBMA address of the next routed
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 an station S may choose to dispose of the data packet while awaiting a
NHRP 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 reply arrives and a more optimal (b) Retain the packet until the Next Hop Resolution Reply arrives
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
The choice of which of the above to perform is a local policy matter, The choice of which of the above to perform is a local policy matter,
though option (c) is the recommended default, since it may allow data though option (c) is the recommended default, since it may allow data
to flow to the destination while the NBMA address is being resolved. to flow to the destination while the NBMA address is being resolved.
Note that an Next Hop Resolution Request for a given destination MUST Note that an Next Hop Resolution Request for a given destination MUST
NOT be triggered on every packet, though periodically retrying a Next NOT be triggered on every packet, though periodically retrying a Next
Hop Resolution Request is permitted. Hop Resolution Request is permitted.
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 because NHRP packets are encapsulated with the Deployment.) Note that NHSs must be next hops to one another in order
NBMA address of neighboring stations (see encapsulation discussion, for forwarding of NHRP packets to be possible.
section 5), NHSs must be next hops to one another in order for
forwarding of these 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 NHRP reply on D's behalf. (NHRP replies in this generates a positive Next Hop Resolution Reply on D's behalf. (Next
scenario are always marked as "authoritative".) The NHRP reply Hop Resolution Replies in this scenario are always marked as
packet contains the next hop IP and NBMA address for station D and is "authoritative".) The Next Hop Resolution Reply packet contains the
sent back to S. (Note that if station D is not on the NBMA next hop internetwork layer address and the NBMA address for station
subnetwork, the next hop IP address will be that of the egress router D and is sent back to S. (Note that if station D is not on the NBMA
through which packets for station D are forwarded.) subnetwork, the next hop internetwork layer address will be that of
the egress router through which packets for station D are forwarded.)
An NHS receiving an NHRP reply may cache the NBMA next hop An NHS receiving a Next Hop Resolution Reply may cache the NBMA next
information contained therein. To a subsequent Next Hop Resolution hop information contained therein. To a subsequent Next Hop
Request, this NHS may respond with the cached, non-authoritative, Resolution Request, this NHS may respond with the cached, non-
NBMA next hop information or with cached negative information, if the authoritative, NBMA next hop information or with cached negative
NHS is allowed to do so, see section 6.2. Non-authoritative NHRP information, if the NHS is allowed to do so, see section 6.2. Non-
replies are distinguished from authoritative replies so that if a authoritative Next Hop Resolution Replies are distinguished from
communication attempt based on non-authoritative information fails, a authoritative Next Hop Resolution Replies so that if a communication
source station can choose to send an authoritative Next Hop attempt based on non-authoritative information fails, a source
Resolution Request. NHSs MUST NOT respond to authoritative Next Hop station can choose to send an authoritative Next Hop Resolution
Resolution Requests with cached information. Request. NHSs MUST NOT respond to authoritative Next Hop Resolution
Requests with cached information.
[Note: An NHRP reply can be returned directly to the Next Hop [Note: An Next Hop Resolution Reply can be returned directly to the
Resolution Request initiator, i.e., without traversing the list of Next Hop Resolution Request initiator, i.e., without traversing the
NHSs that forwarded the request, if all of the following criteria list of NHSs that forwarded the Next Hop Resolution Request, if all
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 permitted connection to the Next Hop Resolution Request initiator or is
to open one. permitted to open one.
(b) The Next Hop Resolution Request initiator has not included the NHRP (b) The Next Hop Resolution Request initiator has not included the
Reverse NHS record Extension (see Section 5.3.5). NHRP Reverse NHS record Extension (see Section 5.3.5).
(c) The authentication policy in force permits direct (c) The authentication policy in force permits direct
communication between the NHS and the Next Hop Resolution Request communication between the NHS and the Next Hop Resolution
initiator. Request initiator.
The purpose of allowing an NHS to reply directly is to reduce
response time. A consequence of allowing a direct reply is that
NHSs that would under normal circumstances be traversed by the
reply would not cache next hop information contained therein.]
The purpose of allowing an NHS to send a Next Hop Resolution Reply
directly is to reduce response time. A consequence of allowing a
direct Next Hop Resolution Reply is that NHSs that would under
normal circumstances be traversed by the Next Hop Resolution Reply
would not cache next hop information contained therein.]
The process of forwarding the Next Hop Resolution Request is repeated The process of forwarding the Next Hop Resolution Request is repeated
until the request is satisfied, or an error occurs (e.g., no NHS in until the Next Hop Resolution Request is satisfied, or an error
the NBMA subnetwork can resolve the request.) If the determination is occurs (e.g., no NHS in the NBMA subnetwork can resolve the Next Hop
made that station D's next hop cannot be resolved, a negative reply Resolution Request.) If the determination is made that station D's
is returned. This occurs when (a) no next-hop resolution information next hop cannot be resolved, a negative Next Hop Resolution Reply
is available for station D from any NHS, or (b) an NHS is unable to (NAK) is returned. This occurs when (a) no next-hop resolution
forward the Next Hop Resolution Request (e.g., connectivity is lost). 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
is lost).
Next Hop Resolution Requests and replies MUST NOT cross the borders NHRP Registration Requests, NHRP Registration Replies, NHRP Purge
of a logical NBMA subnetwork (an explicit NBMA subnetwork identifier Requests, NHRP Purge Replies, and NHRP Error Indications follow the
may be included as an extension in the Next Hop Resolution Request, routed path from sender to receiver in the same fashion that Next Hop
see section 5.3.2). Thus, IP traffic out of and into a logical NBMA Resolution Requests and Next Hop Resolution Replies do. That is,
subnetwork always traverses an IP router at its border. Internetwork "requests" and "indications" follow the routed path from Source
layer filtering can then be implemented at these border routers. Protocol Address (which is the address of the station initiating the
communication) to the Destination Protocol Address. "Replies", on
the other hand, follow the routed path from the Destination Protocol
Address back to the Source Protocol Address with the exceptions
mentioned above where a direct VC may be created.
NHRP optionally provides a mechanism to reply with aggregated NBMA Next Hop Resolution Requests and Next Hop Resolution Replies MUST NOT
next hop information. Suppose that router X is the NBMA next hop cross the borders of a logical NBMA subnetwork (an explicit NBMA
from station S to station D. Suppose further that X is an egress subnetwork identifier may be included as an extension in the Next Hop
router for all stations sharing an IP address prefix with station D. Resolution Request, see section 5.3.2). Thus, the internetwork layer
When an NHRP reply is generated in response to a request, the traffic out of and into a logical NBMA subnetwork always traverses an
responder may augment the IP address of station D with a mask internetwork layer router at its border. Internetwork layer
defining this prefix (see Section 5.3.1). A subsequent (non- filtering can then be implemented at these border routers.
authoritative) Next Hop Resolution Request for some destination that
shares an IP address prefix with D may be satisfied with this cached NHRP optionally provides a mechanism to send a Next Hop Resolution
information. See section 6.2 regarding caching issues. Reply which contains aggregated NBMA next hop information. Suppose
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
an internetwork layer address prefix with station D. When an Next
Hop Resolution Reply is generated in response to a Next Hop
Resolution Request, the responder may augment the internetwork layer
address of station D with a prefix length (see Section 5.3.1). A
subsequent (non-authoritative) Next Hop Resolution Request for some
destination that shares an internetwork layer address prefix (for the
number of bits specified in the prefix length) with D may be
satisfied with this cached information. See section 6.2 regarding
caching issues.
To dynamically detect subnetwork-layer filtering in NBMA subnetworks 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), as
well as to provide loop detection and diagnostic capabilities, NHRP well as to provide loop detection and diagnostic capabilities, a
optionally incorporates a "Route Record" in requests and replies (see "Route Record" may be included in NHRP packets (see Sections 5.3.4
Sections 5.3.4 and 5.3.5). The Route Record extensions contain the and 5.3.5). The Route Record extensions contain the internetwork
internetwork (and subnetwork layer) addresses of all intermediate (and subnetwork layer) addresses of all intermediate NHSs between
NHSs between source and destination (in the forward direction) and source and destination (in the forward direction) and between
between destination and source (in the reverse direction). When a destination and source (in the reverse direction). When a source
source station is unable to communicate with the responder (e.g., an station is unable to communicate with the responder (e.g., an attempt
attempt to open an SVC fails), it may attempt to do so successively to open an SVC fails), it may attempt to do so successively with
with other subnetwork layer addresses in the Route Record until it other subnetwork layer addresses in the Route Record until it
succeeds (if authentication policy permits such action). This succeeds (if authentication policy permits such action). This
approach can find a suitable egress point in the presence of approach can find a suitable egress point in the presence of
subnetwork-layer filtering (which may be source/destination subnetwork-layer filtering (which may be source/destination
sensitive, for instance, without necessarily creating separate sensitive, for instance, without necessarily creating separate
logical NBMA subnetworks) or subnetwork-layer congestion (especially logical NBMA subnetworks) or subnetwork-layer congestion (especially
in connection-oriented media). in connection-oriented media).
NHRP messages, with the exception of Purge packets, are sent using a
best effort delivery service. Next Hop Resolution Requests should be
retransmitted periodically until either a Reply or an Error packet is
received.
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 forward the request on to. The NHS selection neighboring NHS to which it will forward the Next Hop Resolution
procedure typically involves performing a routing decision based upon Request. The NHS selection procedure typically involves performing a
the network layer destination address of the Next Hop Resolution routing decision based upon the network layer destination address of
Request. Ignoring error situations, the Next Hop Resolution Request the Next Hop Resolution Request. Ignoring error situations, the Next
eventually arrives at a station that is to generate an NHRP reply. Hop Resolution Request eventually arrives at a station that is to
This responding station either serves the destination, or is the generate an Next Hop Resolution Reply. This responding station
destination itself if both NHRP client and server functionality are either serves the destination, or is the destination itself if both
co-resident in the same station. The responding station generates a NHRP client and server functionality are co-resident in the same
reply using the source address from within the NHRP packet to station. The responding station generates a Next Hop Resolution
determine where the reply should be sent. Reply using the source address from within the NHRP packet to
determine where the Next Hop Resolution Reply should be sent.
The Next Hop Resolution Request packet is carried at the NBMA layer, The Next Hop Resolution Request packet is carried at the NBMA layer,
with a destination NBMA address set to that of the locally determined with a destination NBMA address set to that of the locally determined
NHS. If the addressed NHS does not serve the destination address NHS. If the addressed NHS does not serve the destination address
specified in the Next Hop Resolution Request, the request packet is specified in the Next Hop Resolution Request, the Next Hop Resolution
routed at the network layer based upon the request's destination Request packet is routed at the network layer based upon the Next Hop
address, and forwarded to the neighboring NHS determined by the Resolution Requester's destination address, and forwarded to the
routing decision. Alternately, the NHS may use static configuration neighboring NHS determined by the routing decision. Alternately, the
information in order to determine which neighboring NHSs to forward NHS may use static configuration information in order to determine to
the request packet to. Each NHS/router examines the NHRP request which neighboring NHSs to forward the Next Hop Resolution Request
packet. Each NHS/router examines the Next Hop Resolution Request
packet on its way toward the destination, optionally modifying it on packet on its way toward the destination, optionally modifying it on
the way (such as updating the Forward Record extension), and the way (such as updating the Forward Record extension), and
continues to forward it until it reaches the NHS that serves the continues to forward it until it reaches the NHS that serves the
destination network layer address. destination network layer address.
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 A client may be able to derive the NBMA address of its NHS from the
configuration that was already required for the client to be able to configuration that was already required for the client to be able to
communicate with its next hop router. communicate with its next hop router.
Forwarding of NHRP packets within an NBMA subnetwork requires a Forwarding of NHRP packets within an NBMA subnetwork requires a
contiguous deployment of NHRP capable stations. During migration to contiguous deployment of NHRP capable stations. During migration to
NHRP, it cannot be expected that all stations within the NBMA NHRP, it cannot be expected that all stations within the NBMA
subnetwork are NHRP capable. NHRP traffic which would otherwise need subnetwork are NHRP capable. NHRP traffic which would otherwise need
to be forwarded through such stations can be expected to be dropped to be forwarded through such stations can be expected to be dropped
due to the NHRP packet being unrecognized. In this case, NHRP will due to the NHRP packet being unrecognized. In this case, NHRP will
be unable to establish any transit paths whose discovery requires the be unable to establish any transit paths whose discovery requires the
traversal of the non-NHRP speaking stations. In such a scenario, traversal of the non-NHRP speaking stations. If the client has tried
NHRP is still able to provide basic address resolution functionality and failed to acquire a cut through path the the client should use
between stations which do support NHRP. the network layer routed path as a default.
The path taken by Next Hop Resolution Requests will normally be the 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 same as the path taken by data packets which are routed at the
network layer to the desired destination. (The paths may be network layer to the desired destination. (The paths may be
different in situations where NHSs have been statically configured to different in situations where NHSs have been statically configured to
forward traffic by other means. For example, an Next Hop Resolution forward traffic by other means. For example, an Next Hop Resolution
Request may be forwarded to a group multicast address.) Request may be forwarded to a group multicast address.)
NHSs should acquire knowledge about destinations other NHSs serve as NHSs should acquire knowledge about destinations other NHSs serve as
a direct consequence of participating in intradomain and interdomain a direct consequence of participating in intra-domain and inter-
routing protocol exchange. In this case, the NHS serving a domain routing protocol exchange. In this case, the NHS serving a
particular destination must lie along the routed path to that particular destination must lie along the routed path to that
destination. In practice, this means that all egress routers must destination. In practice, this means that all egress routers must
double as NHSs serving the destinations beyond them, and that hosts double as NHSs serving the destinations beyond them, and that hosts
on the NBMA subnetwork are served by routers that double as NHSs. on the NBMA subnetwork are served by routers that double as NHSs.
NHSs (and end stations) may alternately be statically configured with NHSs (and end stations) may alternately be statically configured with
the NBMA addresses of their neighbors, the identities of the the NBMA addresses of their neighbors, the identities of the
destinations that each of them serves, and optionally a logical NBMA destinations that each of them serves, and optionally a logical NBMA
subnetwork identifier. Such static configurations may be necessary subnetwork identifier. Such static configurations may be necessary
in cases where NHSs do not contain network layer routing protocol in cases where NHSs do not contain network layer routing protocol
implementations. implementations.
If the NBMA subnetwork offers a group addressing or multicast If the NBMA subnetwork offers a link layer group addressing or
feature, the client (station) may be configured with a group address multicast feature, the client (station) may be configured with a
assigned to the group of next-hop servers. The client might then group address assigned to the group of next-hop servers. The client
submit Next Hop Resolution Requests to the group address, eliciting a might then submit Next Hop Resolution Requests to the group address,
response from one or more NHSs, depending on the response strategy eliciting a response from one or more NHSs, depending on the response
selected. Note that the constraints described in Section 2 regarding strategy selected. Note that the constraints described in Section 2
direct replies may apply. regarding directly sending Next Hop Resolution Reply may apply.
NHSs may also be deployed with the group or multicast address of NHSs may also be deployed with the group or multicast address of
their peers, and an NHS might use this as a means of forwarding Next their peers, and an NHS might use this as a means of forwarding Next
Hop Resolution Requests it cannot satisfy to its peers. This might Hop Resolution Requests it cannot satisfy to its peers. This might
elicit a response (to the NHS) from one or more NHSs, depending on elicit a response (to the NHS) from one or more NHSs, depending on
the response strategy. The NHS would then forward the NHRP reply to the response strategy. The NHS would then forward the Next Hop
the Next Hop Resolution Request originator. The purpose of using Resolution Reply to the Next Hop Resolution Request originator. The
group addressing or a similar multicast mechanism in this scenario purpose of using group addressing or a similar multicast mechanism in
would be to eliminate the need to preconfigure each NHS in a logical this scenario would be to eliminate the need to preconfigure each NHS
NBMA subnetwork with both the individual identities of other NHSs as in a logical NBMA subnetwork with both the individual identities of
well as the destinations they serve. It reduces the number of NHSs other NHSs as well as the destinations they serve. It reduces the
that might be traversed to process an Next Hop Resolution Request (in number of NHSs that might be traversed to process an Next Hop
those configurations where NHSs either respond or forward via the Resolution Request (in those configurations where NHSs either respond
multicast, only two NHSs would be traversed), and allows the NHS that or forward via the multicast, only two NHSs would be traversed), and
serves the Next Hop Resolution Request originator to cache next hop allows the NHS that serves the Next Hop Resolution Request originator
information associated with the reply (again, within the constraints to cache next hop information associated with the Next Hop Resolution
described in Section 2). Reply (again, within the constraints described in Section 2).
4. Configuration 4. Configuration
Stations Stations
To participate in NHRP, a station connected to an NBMA subnetwork To participate in NHRP, a station 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 stations's default or peer routers, so likely also represent the station'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 station's existing
configuration. If the station is attached to several subnetworks configuration. If the station is attached to several subnetworks
(including logical NBMA subnetworks), the station should also be (including logical NBMA subnetworks), the station 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 IP networks are reachable routers so that it can determine which internetwork layer networks
through which subnetworks. are reachable through which subnetworks.
Next Hop Servers Next Hop Servers
An NHS is configured with knowledge of its own IP and NBMA An NHS is configured with knowledge of its own internetwork layer
addresses, a set of IP address prefixes that correspond to the IP and NBMA addresses, a set of internetwork layer address prefixes
addresses of the stations it serves, and a logical NBMA subnetwork that correspond to the internetwork layer addresses of the stations
identifier (see Section 5.3.2). If a served station is attached to it serves, and a logical NBMA subnetwork identifier (see Section
several subnetworks, the NHS may also need to be configured to 5.3.2). If a served station is attached to several subnetworks,
advertise routing information to such stations. the NHS may also need to be configured to advertise routing
information to such stations.
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
skipping to change at page 10, line 48 skipping to change at page 11, line 24
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 lenth 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 minus
20. NHSs may increase the size of an NHRP packet as a result of 20. NHSs may increase the size of an NHRP packet as a result of
extension processing, but not beyond the offered maximum SDU size of extension processing, but not beyond the offered maximum SDU size of
the NBMA network. the NBMA 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:
skipping to change at page 12, line 8 skipping to change at page 12, line 17
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$hrd | ar$pro.type | | ar$afn | ar$pro.type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap | | ar$pro.snap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap | ar$hopcnt | ar$pktsz | | ar$pro.snap | ar$hopcnt | ar$pktsz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$chksum | ar$extoff | | ar$chksum | ar$extoff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$op.version | ar$op.type | ar$shtl | ar$sstl | | ar$op.version | ar$op.type | ar$shtl | ar$sstl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$hrd ar$afn
Defines the type of "link layer" addresses being carried. This Defines the type of "link layer" addresses being carried. This
number is taken from the number hardware type from the list in [6]. number is taken from the 'address family number' list specified in
[6]. This field has implications to the coding of ar$shtl and
***The use of the number hardware type or of the address family number ar$sstl as described below.
is still an open issue.
ar$pro.type ar$pro.type
field is a 16 bit unsigned integer representing the following field is a 16 bit unsigned integer representing the following
number space: number space:
0x0000 to 0x00FF Protocols defined by the equivalent NPLIDs. 0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs.
0x0100 to 0x03FF Reserved for future use by the IETF. 0x0100 to 0x03FF Reserved for future use by the IETF.
0x0400 to 0x04FF Allocated for use by the ATM Forum. 0x0400 to 0x04FF Allocated for use by the ATM Forum.
0x0500 to 0x05FF Experimental/Local use. 0x0500 to 0x05FF Experimental/Local use.
0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes. 0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes.
(based on the observations that valid Ethertypes are never smaller (based on the observations that valid Ethertypes are never smaller
than 0x600, and NPLIDs never larger than 0xFF.) than 0x600, and NLPIDs never larger than 0xFF.)
ar$pro.snap ar$pro.snap
When ar$pro.type has a value of 0x0080, a SNAP encoded extension is When ar$pro.type has a value of 0x0080, a SNAP encoded extension is
being used to encode the protocol type. This snap extension is being used to encode the protocol type. This snap extension is
placed in the ar$pro.snap field. This is termed the 'long form' placed in the ar$pro.snap field. This is termed the 'long form'
protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be
zero on transmit and ignored on receive. The ar$pro.type field zero on transmit and ignored on receive. The ar$pro.type field
itself identifies the protocol being referred to. This is termed itself identifies the protocol being referred to. This is termed
the 'short form' protocol ID. the 'short form' protocol ID.
In all cases, where a protocol has an assigned number in the In all cases, where a protocol has an assigned number in the
ar$pro.type space (excluding 0x0080) the short form MUST be used ar$pro.type space (excluding 0x0080) the short form MUST be used
when transmitting NHRP messages. Additionally, where a protocol has when transmitting NHRP messages. Additionally, where a protocol has
valid short and long forms of identification, receivers MAY choose valid short and long forms of identification, receivers MAY choose
to recognise the long form. to recognize the long form.
ar$hopcnt ar$hopcnt
The Hop count indicates the maximum number of NHSs that an NHRP The Hop count indicates the maximum number of NHSs that an NHRP
packet is allowed to traverse before being discarded. packet is allowed to traverse before being discarded.
ar$pktsz ar$pktsz
The total length of the NHRP packet, in octets (exluding link layer The total length of the NHRP packet, in octets (excluding link
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 NHRP extensions.
If this field is 0 then no extensions exist otherwise this field If this field is 0 then no extensions exist otherwise this field
represents the offset from the beginning of the NHRP packet (i.e., represents the offset from the beginning of the NHRP packet (i.e.,
starting from the ar$afn field) of the first extension. 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 0x0001 for NHRP version 1.
ar$op.type ar$op.type
This is the NHRP packet type (request, reply, purge, or error). This is the NHRP packet type: NHRP Next Hop Resolution Request(1),
NHRP Next Hop Resolution Reply(2), NHRP Registration Request(3),
NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Purge
Reply(6), or NHRP Error Indication(7).
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 'hardware' (NBMA media) indicated by ar$afn (e.g., the 'address family number'[6] indicated by ar$afn (e.g.,
ar$afn=0x0003 for ATM). 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
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
of the 'hardware' (NBMA media) indicated by ar$afn (e.g., of the 'address family number'[6] indicated by ar$afn (e.g.,
ar$afn=0x0003 for ATM). When an NBMA technology has no concept of ar$afn=0x000F for NSAP). When an NBMA technology has no concept of
a subaddress the subaddress is always null and ar$sstl = 0 and no a subaddress, the subaddress length is always coded ar$sstl = 0 and
storage is allocated for the address in the appropriate mandatory no storage is allocated for the subaddress in the appropriate
part. mandatory part.
The ar$shtl and ar$sstl fields are coded as follows: ar$shtl, ar$sstl, subnetwork layer addresses, and subnetwork layer
subaddresses fields are coded as follows:
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|x| length | |0|x| length |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The most significant bit is reserved and MUST be set to zero. The The most significant bit is reserved and MUST be set to zero. The
second most significant bit (x) is a flag indicating whether the NBMA second most significant bit (x) is a flag indicating whether the
address being referred to is in: address being referred to is in:
- NSAP format (x = 0). - NSAP format (x = 0).
- Native E.164 format (x = 1). - Native E.164 format (x = 1).
For NBMA technologies that use neither NSAP nor E.164 format For NBMA technologies that use neither NSAP nor E.164 format
addresses, x = 0 SHALL be used to indicate the native form for the addresses, x = 0 SHALL be used to indicate the native form for the
particular NBMA technology. particular NBMA technology.
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
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 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 Next Hop Resolution Request 5.2.1 NHRP Next Hop Resolution Request
The Next Hop Resolution Request packet has a Type code of 1. The The NHRP Next Hop Resolution Request packet has a Type code of 1. The
Mandatory Part has the following format: Mandatory 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 |Q|A|P|B| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | | Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|P|B| Unused| Proto Length | Source Address Holding Time | | Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | | 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request ID Src Proto Len
A value which, when coupled with the address of the source, This field holds the length in octets of the Source Protocol
provides a unique identifier for the information contained in a Address.
Request and its associated Next Hop Resolution Reply, and any
subsequent Purge. This value can be used by the source to aid in
matching requests with replies. 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 Dst Proto Len
time a new NHRP request is transmitted. The same value MUST be This field holds the length in octets of the Destination Protocol
used when sending another request for the same destination when a Address.
previous 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 request when no cache entry is present, or a
previous cache entry was deleted for any reason.
Next Hop Resolution Request Flags NHRP Next Hop Resolution Request/Reply Flags
Q Q
Set if the requester is a router; clear if the requester is a Set if the station sending the Next Hop Resolution Request is a
host. router; clear if the it is a host.
A A
A response to an NHRP request may contain cached information. If A response to a Next Hop Resolution Request may contain cached
an authoritative answer is desired, then this bit information. If an authoritative answer is desired, then this bit
("Authoritative") should be set. If non-authoritative (cached) ("Authoritative") should be set. If non-authoritative (cached)
information is acceptable, this bit should be clear. information is acceptable, this bit should be clear.
P P
Unused (clear on transmit) Unused (clear on transmit)
B B
Unused (clear on transmit) Unused (clear on transmit)
Proto Length Request ID
The length in octets, of the internetwork layer protocol addresses A value which, when coupled with the address of the source,
appearing in this packet. If this length is not a multiple of 4, provides a unique identifier for the information contained in a
each internetwork layer address is zero-filled to the nearest 32- Next Hop Resolution Request and its associated Next Hop Resolution
bit boundary. 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).
Source Address Holding Time The value is taken from a 32 bit counter that is incremented each
The Source Address Holding Time field specifies the number of time a new Next Hop Resolution Request is transmitted. The same
seconds for which the source NBMA information is considered to be value MUST be used when sending another Next Hop Resolution Request
valid. Cached information SHALL be discarded when the holding time for the same destination when a previous Next Hop Resolution
expires. 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 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 Holding Time field specifies the number of seconds for which
the client NBMA information (the information of the client issuing
the Next Hop Resolution Request) is considered to be valid. The
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 initiated the request. It is zero-filled to the nearest 32- which is sending the Next Hop Resolution Request. If the field's
bit boundary. However, if its length as specified in ar$shtl is 0 length as specified in ar$shtl is 0 then no storage is allocated
then no storage is allocated for this address at all. for this address at 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 initiated the request. It is zero-filled to the station which is sending the Next Hop Resolution Request. If the
nearest 32- bit boundary. However, if its length as specified in field's length as specified in ar$sstl is 0 then no storage is
ar$sstl is 0 then no storage is allocated for this address at all. allocated for this address at all.
Source Protocol Addresses Source Protocol Address
This is the protocol address of the station which initially issued This is the protocol address of the station which is sending the
an NHRP Request packet. Next Hop Resolution Request.
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 for which the NBMA next
hop is desired. hop is desired.
(The NBMA address/subaddress form allows combined E.164/NSAPA form of (The NBMA address/subaddress form allows combined E.164/NSAPA form of
NBMA addressing. For NBMA technologies without a subaddress concept, NBMA addressing. For NBMA technologies without a subaddress concept,
the subaddress field is always ZERO length and ar$sstl = 0.) the subaddress field is always ZERO length and ar$sstl = 0.)
5.2.2 NHRP Next Hop Resolution Reply 5.2.2 NHRP Next Hop Resolution Reply
The NHRP Next Hop Resolution Reply packet has a type code of 2. The The NHRP Next Hop Resolution Reply packet has a type code of 2. The
Mandatory Part has the following format: Mandatory 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 |Q|A|P|B| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | | Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|P|B| Unused| Proto Length | Next Hop Holding Time | | Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH Addr T/L | NH SAddr T/L | Preference | unused | | NH Addr T/L | NH SAddr T/L | NH Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Address (variable length) | | Next Hop NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Subaddress (variable length) | | Next Hop NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request ID Src Proto Len
A value which, when coupled with the address of the source, This field holds the length in octets of the Source Protocol
provides a unique identifier for the information contained in a Address.
Request and its associated Next Hop Resolution Reply, and any
subsequent Purge. This value can be used by the source to aid in
matching requests with replies. 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 Dst Proto Len
time a new NHRP request is transmitted. The same value MUST be This field holds the length in octets of the Destination Protocol
used when sending another request for the same destination when a Address.
previous 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 request when no cache entry is present, or a
previous cache entry was deleted for any reason.
Next Hop Resolution Request Flags Next Hop Resolution Request/Reply Flags
Q Q
Copied from the Next Hop Resolution Request. Set if the Copied from the Next Hop Resolution Request. Set if the Next Hop
Requester is a router; clear if the requester 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 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 P
Set if the Next Hop Resolution Reply is positive; clear if the Set if the Next Hop Resolution Reply is positive; clear if the
Next Hop Resolution Reply is negative. Next Hop Resolution Reply is negative.
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 cacheing 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 reply to an Next Hop Resolution Request An NHS is not allowed to send a Next Hop Resolution Reply to an
for authoritative information with cached information, but may do Next Hop Resolution Request for authoritative information with
so for an NHRP Next Hop Resolution Request which indicates a cached information, but may do so for an NHRP Next Hop Resolution
request for non-authoritative information. An NHS may reply to an Request which indicates a request for non-authoritative
Next Hop Resolution Request for non-authoritative information information. An NHS may send an Next Hop Resolution Reply to an
with authoritative information. Next Hop Resolution Request for non-authoritative information with
authoritative information.
Proto Length Request ID
The length in octets, of the internetwork layer protocol addresses A value which, when coupled with the address of the source,
appearing in this packet. If this length is not a multiple of 4, provides a unique identifier for the information contained in a
each internetwork layer address is zero-filled to the nearest 32- Next Hop Resolution Request and its associated Next Hop Resolution
bit boundary. 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).
Next Hop Address Holding Time The value is taken from a 32 bit counter that is incremented each
The Next Hop Address Holding Time field specifies the number of time a new Next Hop Resolution Request is transmitted. The same
seconds for which the next hop NBMA information is considered to be value MUST be used when sending another Next Hop Resolution Request
valid. Cached information SHALL be discarded when the holding time for the same destination when a previous Next Hop Resolution
expires. Must be set to 0 on a NAK. 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 NH Addr T/L
Type & length of next hop NBMA address interpreted in the context Type & length of next hop NBMA address specified in the mandatory
of the 'hardware' (NBMA media) indicated by ar$afn (e.g., part of the packet. This field is interpreted in the context of the
ar$afn=0x0003 for ATM). When the address length is specified as 0 'address family number'[6] indicated by ar$afn (e.g., ar$afn=0x0003
no storage is allocated for the address. Set to 0 on a NAK. for ATM).
NH SAddr T/L NH SAddr T/L
Type & length of next hop NBMA subaddress interpreted in the Type & length of next hop NBMA subaddress specified in the
context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., mandatory part of the packet. This field is interpreted in the
ar$afn=0x0003 for ATM). When an NBMA technology has no concept of context of the 'address family number'[6] indicated by ar$afn
a subaddress the subaddress is always null with a length of 0. (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and the
When the address length is specified as 0 no storage is allocated subaddress an ATM Forum NSAP address). When an NBMA technology has
for the address. Set to 0 on a NAK. 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 Preference
This field specifies the preference of the Next Hop entry, relative This field specifies the preference of the Next Hop entry specified
to other Next Hop entries in this NHRP Next Hop Resolution Reply in the mandatory part of the packet. This preference value is
packet which may be in the Additional Next Hop Entries Extension relative to other Next Hop entries in this NHRP Next Hop Resolution
for the given internetworking protocol. Higher values indicate Reply packet which may be by the Additional Next Hop Entries
more preferable Next Hop entries. Action taken when multiple next Extension (see Section 5.3.9) for the given internetworking
hop entries have the highest preference value is a local matter. protocol. Higher values indicate higher preference. Action taken
Set to 0 on a NAK. when multiple next hop entries have the highest preference value is
a local matter. Set to 0 on a NAK.
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 initiated the request. It is zero-filled to the nearest 32- which sent the Next Hop Resolution Request. If the field's length
bit boundary. However, if its length as specified in ar$shtl is 0 as specified in ar$shtl is 0 then no storage is allocated for this
then no storage is allocated for this address at all. address at 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 initiated the request. It is zero-filled to the station which sent the Next Hop Resolution Request. If the field's
nearest 32- bit boundary. However, if its length as specified in length as specified in ar$sstl is 0 then no storage is allocated
ar$sstl is 0 then no storage is allocated for this address at all. for this address at all.
Source Protocol Addresses Source Protocol Address
This is the protocol address of the station which initially issued This is the protocol address of the station which sent the Next Hop
an NHRP Request packet. Resolution Request.
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 for which the NBMA next
hop is desired. hop is desired.
(The NBMA address/subaddress form allows combined E.164/NSAPA form (The NBMA address/subaddress form allows combined E.164/NSAPA form
of NBMA addressing. For NBMA technologies without a subaddress of NBMA addressing. For NBMA technologies without a subaddress
concept, the subaddress field is always ZERO length and ar$sstl = concept, the subaddress field is always ZERO length and ar$sstl =
0.) 0.)
Next Hop entry The following is the Next Hop entry as specified in the Mandatory
Part of the packet:
Next Hop Protocol Address
This internetworkin 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.
Next Hop NBMA Address Next Hop NBMA Address
This is the NBMA address of the station that is the next hop for This is the NBMA address of the station that is the next hop for
packets bound for the internetworking layer address specified. packets bound for the internetworking layer address specified.
The NBMA address field itself is zero-filled to the nearest 32-
bit boundary.
Next Hop NBMA SubAddress Next Hop NBMA SubAddress
This is the NBMA sub address of the station that is the next hop This is the NBMA sub address of the station that is the next hop
for packets bound for the internetworking layer address for packets bound for the internetworking layer address
specified. The NBMA subaddress field itself is zero-filled to specified.
the nearest 32-bit boundary.
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.
There may be multiple Next Hop entries returned in the Next Hop There may be multiple Next Hop entries returned in the Next Hop
Resolution Reply by including the Additional Next Hop Entries Resolution Reply by including the Additional Next Hop Entries
Extension. See Section 5.3.9 for use of these entries. The most Extension. See Section 5.3.9 for use of these entries. The most
preferable Next Hop must be specified in the mandatory part of the preferable Next Hop must be specified in the mandatory part of the
Next Hop Resolution Reply. Next Hop Resolution Reply.
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 packet, except for
the case of unrecognized non-Compulsory extensions. the case of unrecognized non-Compulsory extensions.
skipping to change at page 21, line 8 skipping to change at page 21, line 32
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. The Mandatory 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | | Src Proto Len | Dst Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | Proto Length | Register Holding Time | | Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | | unused | Register Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request ID Src Proto Len
A value which, when coupled with the address of the source, This field holds the length in octets of the Source Protocol
provides a unique identifier for the information contained in a Address.
Registration Request packet. This value is copied directly from a
Registration Request packet into the associated 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).
Proto Length Dst Proto Len
The length in octets, of the internetwork layer protocol addresses This field holds the length in octets of the Destination Protocol
appearing in this packet. If this length is not a multiple of 4, Address.
each internetwork layer address is zero-filled to the nearest 32-
bit boundary.
Source Protocol Address Request ID
The Protocol Address of the station wishing to register its NBMA A value which, when coupled with the address of the source,
address with an NHS. provides a unique identifier for the information contained in an
NHRP Registration Request packet. This value is copied directly
from an NHRP Registration Request packet into the associated
Registration Reply. This value could also be sent across a virtual
circuit (in SVC environments) to aid in matching the NHRP
transactions with virtual circuits (this use is for further study).
Register Holding Time Register Holding Time
The Register Holding Time field specifies the number of seconds for The Register Holding Time field specifies the number of seconds for
which the registered NBMA information is considered to be valid. which the registered NBMA information is considered to be valid.
Cached information SHALL be discarded when the holding time Cached information SHALL be discarded when the holding time
expires. expires.
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 initiated the request. It is zero-filled to the nearest 32- which is sending the NHRP Registration Request.
bit boundary. However, if its length as specified in ar$shtl is 0
then no storage is allocated for this address at 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 initiated the request. It is zero-filled to the station which is sending the NHRP Registration Request. If the
nearest 32- bit boundary. However, if its length as specified in field's length as specified in ar$sstl is 0 then no storage is
ar$sstl is 0 then no storage is allocated for this address at all. allocated for this address at all.
Source Protocol Addresses Source Protocol Address
This is the protocol address of the station which initially issued This is the protocol address of the station which is sending the
an NHRP Request packet. NHRP Registration Request.
Destination Protocol Address Destination Protocol Address
This is the protocol address of the NHS for which the source NBMA This is the protocol address of the NHS for which the source NBMA
next hop information is being reistered next hop information is being registered.
This packet is used to register a station's Protocol and NBMA This packet is used to register a station's Protocol and NBMA
addresses with its NHSs, as configured or known through conventional addresses with its NHSs, as configured or known through conventional
routing means. This allows static configuration information to be routing means. This allows static configuration information to be
reduced; the NHSs need not be configured with the identities of all reduced; the NHSs need not be configured with the identities of all
of the stations that they serve. 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 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.
In order to keep the registration entry from being discarded, the In order to keep the registration entry from being discarded, the
station MUST resend the NHRP Registration Request packet often enough station MUST re-send the NHRP Registration Request packet often
to refresh the registration, even in the face of occasional packet enough to refresh the registration, even in the face of occasional
loss. It is recommended that the Registration Request packet be sent packet loss. It is recommended that the NHRP Registration Request
at an interval equal to one-third of the Holding Time specified packet be sent at an interval equal to one-third of the Holding Time
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 Registration Request. If the NAK Code field has to that client's NHRP Registration Request. If the NAK Code field has
anything other than 0 zero in it then the Registration Reply is a NAK anything other than 0 zero in it then the NHRP Registration Reply is
otherwise the reply is an ACK. The Registration Reply has a Type a NAK otherwise the reply is an ACK. The NHRP Registration Reply has
code of 4. Its mandatory part has the following format: a Type code of 4. Its mandatory 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | | Src Proto Len | Dst Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK Code | Proto Length | Register Holding Time | | Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | | NAK Code | unused | Register Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 an
Registration Request packet. This value is copied directly from a NHRP Registration Reply packet. This value is copied directly from
Registration Request packet into the associated Registration Reply. an NHRP Registration Request packet into the associated NHRP
This value could also be sent across a virtual circuit (in SVC Registration Reply. This value could also be sent across a virtual
environments) to aid in matching NHRP transactions with virtual circuit (in SVC environments) to aid in matching NHRP transactions
circuits (this use is for further study). with virtual circuits (this use is for further study).
NAK Code NAK Code
If this field is set to zero then this packet contains a If this field is set to zero then this packet contains a positively
Registration Request Acknowledgement. If this field contains any acknowledged NHRP Registration Reply. If this field contains any
other value then this contains a Registration Request NAK. other value then this contains an NHRP Registration Reply NAK which
Currently defined NAK Codes are as follows: 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 attempt for An NHS may refuse an NHRP Registration Request attempt for
administrative reasons. If so, the NHS MUST reply with this administrative reasons. If so, the NHS MUST send an NHRP
NAK in the Registration Reply which contains a NAK code of 4. 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 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.
Proto Length
The length in octets, of the internetwork layer protocol addresses
appearing in this packet. If this length is not a multiple of 4,
each internetwork layer address is zero-filled to the nearest 32-
bit boundary.
Source Protocol Address
The Protocol Address of the client that sent a Registration
Request.
Register Holding Time Register Holding Time
The Register Holding Time field specifies the number of seconds for The Register Holding Time field specifies the number of seconds for
which the registered NBMA information is considered to be valid. which the registered NBMA information is considered to be valid.
Cached information SHALL be discarded when the holding time Cached information SHALL be discarded when the holding time
expires. expires.
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 initiated the request. It is zero-filled to the nearest 32- which sent the Next Hop Registration Request.
bit boundary. However, if its length as specified in ar$shtl is 0
then no storage is allocated for this address at all.
Source NBMA SubAddress Source NBMA SubAddress
The Source NBMA subaddress field is the subaddress of the source The Source NBMA subaddress field is the subaddress of the source
station which initiated the request. It is zero-filled to the station which sent the Next Hop Registration Request. If the
nearest 32-bit boundary. However, if its length as specified in field's length as specified in ar$sstl is 0 then no storage is
ar$sstl is 0 then no storage is allocated for this address at all. allocated for this address at all.
Source Protocol Addresses Source Protocol Address
This is the protocol address of the station which initially issued This is the protocol address of the station which sent the NHRP
an NHRP request packet. Registration Request.
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 NHS in which the client is
hop is desired. attempting to register the client's NBMA information.
This packet is used to register a station's Protocol and NBMA This packet is used to register a station's Protocol and NBMA
addresses with its neighboring NHSs, as configured or known through addresses with its neighboring NHSs, as configured or known through
conventional routing means. This allows static configuration conventional routing means. This allows static configuration
information to be reduced; the NHSs need not be configured with the information to be reduced; the NHSs need not be configured with the
identities of all of the stations that they serve. 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
It is possible that a misconfigured station will attempt to register serve and that packet has a Destination Protocol Address which is not
with the wrong NHS (i.e., one that cannot serve it due to policy the protocol address of the NHS that is currently inspecting the
constraints or routing state). If this is the case, the NHS MUST packet then the NHS inspecting the packet MUST forward the
reply with a NAK-ed Registration Reply of type Can't Serve This registration along the routed path to the Destination Protocol
Address. 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 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 NHRP Registration Reply of type Registration
Overflow. Overflow.
In order to keep the registration entry from being discarded, the In order to keep the client's registration entry in the client's NHS
station MUST resend the NHRP Registration Request packet often enough from being timed out, the station MUST re-send the NHRP Registration
to refresh the registration, even in the face of occasional packet Request packet often enough to refresh the registration entry, even
loss. It is recommended that the Registration Request packet be sent in the face of occasional packet loss. It is recommended that the
at an interval equal to one-third of the Holding Time specified NHRP Registration Request packet be sent at an interval equal to
therein. one-third of the Holding Time specified therein.
5.2.5 NHRP Purge 5.2.5 NHRP Purge Request
The NHRP Purge packet has a type code of 5. The Mandatory Part has The NHRP Purge Request packet is sent in order to invalidate cached
the following format: information in a station. The NHRP Purge Request packet has a type
code of 5. The Mandatory 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | | Src Proto Len | Dst Proto Len |Trgt Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Unused | Proto Length | unused | | Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | | 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 is sending the NHRP Purge Request.
Source NBMA SubAddress
The Source NBMA subaddress field is the address of the source
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
The address of the station which is sending the NHRP Purge Request.
Destination Protocol Address
The address of the station that will be receiving the NHRP Purge
Request.
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 either NHRP Purge Request 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 for the NHRP Purge Request even
if the station does not have a matching cache entry.
If the station wishes to reestablish communication with the
destination shortly after receiving an NHRP Purge Request, it should
make an authoritative Next Hop Resolution Request in order to avoid
any stale cache entries that might be present in intermediate NHSs
(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.6 NHRP Purge Reply
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
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
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 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Protocol Address (variable length) | | Target Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Src Proto Len
Clear if this is a purge request, set if this is an acknowledgment. This field holds the length in octets of the Source Protocol
Address.
Proto Length Dst Proto Len
The length in octets, of the internetwork layer protocol addresses This field holds the length in octets of the Destination Protocol
appearing in this packet. If this length is not a multiple of 4, Address.
each internetwork layer address is zero-filled to the nearest 32-
bit boundary. Trgt Proto Len
This field holds the length in octets of the Target Protocol
Address.
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 initiated the Purge. It is zero-filled to the nearest 32- which sent the NHRP Purge Request.
bit boundary. However, if its length as specified in ar$shtl is 0
then no storage is allocated for this address at 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 initiated the Purge. It is zero-filled to the station which sent the NHRP Purge Request. If its length as
nearest 32- bit boundary. However, if its length as specified in specified in ar$sstl is 0 then no storage is allocated for this
ar$sstl is 0 then no storage is allocated for this address at all. address at all.
Source Protocol Address Source Protocol Address
The address of the station which is sending the purge notification. The address of the station which sent the NHRP Purge Request.
Destination Protocol Address Destination Protocol Address
The address of the station that will be receiving the purge The address of the station which is sending the NHRP Purge Reply.
notification.
Target Protocol Address Target Protocol Address
The address which is to be purged from the receiver's database. 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 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 sent a registration packet to. with which the client had previously registered. This allows for a
This allows for a client to invalidate an NHRP registration before it client to invalidate it's registration with NHRP before it would
would otherwise expire. otherwise expire via the holding timer.
The station sending the NHRP Purge request MUST periodically The station sending the NHRP Purge Request MAY periodically
retransmit the request until it is acknowledged, or until the holding retransmit the NHRP Purge Request until it is acknowledged, or until
time of the information being purged has expired. Retransmission the holding time of the information being purged has expired.
strategies are for further investigation. Retransmission strategies are for further investigation.
When a station receives an NHRP Purge request, it MUST discard any When a station receives an NHRP Purge Request, it MUST discard any
previous cached information that matches the Target Protocol Address. previously cached information that matches the Target Protocol
Address.
An acknowledgment MUST be returned for the Purge request even if the An NHRP Purge Reply MUST be returned as a result of receiving an NHRP
station does not have a matching cache entry. The acknowledgment is Purge Request even if the station does not have a matching cache
constructed by setting the Acknowledgment (A) bit and returning the entry.
Purge request to the Source Protocol Address.
If the station wishes to reestablish communication with the If the station wishes to reestablish communication with the
destination shortly after receiving a Purge request, it should make destination shortly after receiving an NHRP Purge Request, it should
an authoritative request in order to avoid any stale cache entries make an authoritative Next Hop Resolution Request in order to avoid
that might be present in intermediate NHSs. (See section 6.2.2.) It any stale cache entries that might be present in intermediate NHSs.
is recommended that authoritative Next Hop Resolution Requests be (See section 6.2.2.) It is recommended that authoritative Next Hop
made for the duration of the holding time of the old information. Resolution Requests be made for the duration of the holding time of
the old information.
5.2.6 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 6. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error Offset | | Src Proto Len | Dst Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | Proto Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | | Error Code | Error Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of NHRP Packet in error (variable length) | | Contents of NHRP Packet in error (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.
Error Code Error Code
An error code indicating the type of error detected, chosen from An error code indicating the type of error detected, chosen from
the following list: the following list:
1 - Unrecognized Extension 1 - Unrecognized Extension
When the Compulsory bit of an extension is set, the NHRP When the Compulsory bit of an extension in NHRP packet is set,
request cannot be satisfied unless the extension is processed. the NHRP packet cannot be processed unless the extension has
The responder MUST return an Error Indication of type been processed. The responder MUST return an NHRP Error
Unrecognized Extension if it is incapable of processing the Indication of type Unrecognized Extension if it is incapable of
extension. However, if a transit NHS (one which is not going processing the extension. However, if a transit NHS (one which
to generate a reply) detects an unrecognized extension, it is not going to generate a reply) detects an unrecognized
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.
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 maximum SDU size
of the NBMA network, this error is returned. of the NBMA network, this error is returned.
9 - Invalid Extension 9 - Invalid Extension
skipping to change at page 28, line 31 skipping to change at page 31, line 26
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.
Error Offset Error Offset
The offset in octets into the original NHRP packet, starting at the The offset in octets into the NHRP packet, starting at the NHRP
NHRP Fixed Header, at which the error was detected. Fixed Header, at which the error was detected.
Proto Length
The length in octets, of the internetwork layer protocol addresses
appearing in this packet. If this length is not a multiple of 4,
each internetwork layer address is zero-filled to the nearest 32-
bit boundary.
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 station which
which observed the error. It is zero-filled to the nearest 32- bit observed the error.
boundary. However, if its length as specified in ar$shtl is 0 then
no storage is allocated for this address at 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 station
station which observed the error. It is zero-filled to the nearest which observed the error. If the field's length as specified in
32- bit boundary. However, if its length as specified in ar$sstl is ar$sstl is 0 then no storage is allocated for this address at all.
0 then no storage is allocated for this address at all.
Source Protocol Addresses Source Protocol Address
This is the protocol address of the station which issued the Error This is the protocol address of the station which issued the Error
packet. packet.
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 which sent the packet
hop is desired. However, if its length as specified in Proto Length which was found to be in error.
is set to 0 then no storage is allocated for this address at all.
An Error Indication packet SHALL NEVER be generated in response to An NHRP Error Indication packet SHALL NEVER be generated in response
another Error Indication packet. When an Error Indication packet is to another NHRP Error Indication packet. When an NHRP Error
generated, the offending NHRP packet SHALL be discarded. In no case Indication packet is generated, the offending NHRP packet SHALL be
should more than one Error Indication packet be generated for a discarded. In no case should more than one NHRP Error Indication
single NHRP packet. packet be generated for a single NHRP packet.
If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA
and Source Protocol address fields of a transiting NHRP Error
Indication packet then the NHS will quietly drop the packet and do
nothing (this scenario would occur when the NHRP Error Indication
packet was itself in a loop).
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; therefore, "reply" if they were present in the corresponding "request";
minimal NHRP station implementations that do not act as an NHS and do therefore, minimal NHRP station implementations that do not act as an
not transmit extensions need not be able to receive them. An NHS and do not transmit extensions need not be able to receive
implementation that is incapable of processing extensions SHALL extensions. An implementation that is incapable of processing
return an Error Indication of type Unrecognized Extension when it extensions SHALL return an NHRP Error Indication of type Unrecognized
receives an NHRP packet containing extensions. Extension when it receives an NHRP packet containing extensions.
Extensions are typically protocol-specific, as noted.
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C C
"Compulsory." If clear, and the NHS does not recognize the type "Compulsory." If clear, and the NHS does not recognize the type
code, the extension may safely be ignored. If set, and the NHS code, the extension may safely be ignored. If set, and the NHS
does not recognize the type code, the NHRP request is considered to does not recognize the type code, the NHRP "request" is considered
be in error. (See below for details.) to be in error. (See below for details.)
u u
Unused and must be set to zero. Unused and must be set to zero.
Type Type
The extension type code (see below). The extension type is not The extension type code (see below). The extension type is not
qualified by the Compulsory bit, but is orthogonal to it. qualified by the Compulsory bit, but is orthogonal to it.
Length Length
The length in octets of the value (not including the Type and The length in octets of the value (not including the Type and
Length fields; a null extension will have only an extension header Length fields; a null extension will have only an extension header
and a length of zero). and a length of zero).
Each extension is padded with zero octets to a 32 bit boundary. This When extensions exist, the extensions list is terminated by the Null
padding is not included in the Length field. TLV, having Type = 0 and Length = 0.
When extnsions exist, extensions list is terminated by the Null TLV,
having Type = 0 and Length = 0.
Extensions may occur in any order, but any particular extension type Extensions may occur in any order, but any particular extension type
(other than the vendor-private extension) may occur only once in an (except for the vendor-private extension) may occur only once in an
NHRP packet. The vendor-private extension may occur multiple times NHRP packet. The vendor-private extension may occur multiple times
in a packet, to allow for extensions which do not share the same in a packet in order to allow for extensions which do not share the
vendor ID to be represented. same vendor ID to be represented.
The Compulsory bit provides for a means to add to the extension set. The Compulsory bit provides for a means to add to the extension set.
If the bit is set, the NHRP request cannot be satisfied unless the If the bit is set, the NHRP message cannot be properly processed by
extension is processed, so the responder MUST return an Error the station responding to the message (e.g., the station that would
Indication of type Unrecognized Extension. If the bit is clear, the issue a Next Hop Resolution Reply in response to a Next Hop
extension can be safely ignored, though unrecognized extensions so Resolution Request) without processing the extension. As a result,
ignored that were received in an NHRP Request packet MUST be returned the responder MUST return an NHRP Error Indication of type
unchanged in the corresponding NHRP Reply. Unrecognized Extension. If the Compulsory bit is clear then the
extension can be safely ignored; however, if an ignored extension is
in a "request" then it MUST be returned, unchanged, in the
corresponding "reply" packet type.
If a transit NHS (one which is not going to generate a reply) detects If a transit NHS (one which is not going to generate a "reply")
an unrecognized extension, it SHALL ignore the extension. If the detects an unrecognized extension, it SHALL ignore the extension. If
Compulsory bit is set, the transit NHS MUST NOT cache the information the Compulsory bit is set, the transit NHS MUST NOT cache the
(in the case of a reply) and MUST NOT identify itself as an egress information contained in the packet and MUST NOT identify itself as
router (in the Forward Record or Reverse Record extensions). an egress router (in the Forward Record or Reverse Record
Effectively, this means that a transit NHS that encounters an extensions). Effectively, this means, if a transit NHS encounters an
extension that it cannot process and determines that the Compulsory extension which it cannot process and which has the Compulsory bit
bit is set MUST NOT participate in any way in the protocol exchange, set then that NHS MUST NOT participate in any way in the protocol
other than acting as a forwarding agent for the request. exchange other than acting as a forwarding agent.
5.3.1 Destination Prefix Extension 5.3.0 The End Of Extensions
Compulsory = 1
Type = 0
Length = 0
When extensions exist, the extensions list is terminated by the End
Of Extensions/Null TLV.
5.3.1 Destination Prefix Length
Compulsory = 0 Compulsory = 0
Type = 1 Type = 1
Length = 1 Length = 1
This extension is used to indicate that the information carried in an This extension is used to indicate that the information carried in an
NHRP Reply pertains to an equivalence class of destinations rather NHRP packet pertains to an equivalence class of internetwork layer
than just the destination Protocol address specified in the request. 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.
All addresses that match the destination Protocol address in the bit 0 1
positions for which the mask has a one bit are part of the 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
equivalence class. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 In the case of an Next Hop Resolution Request, if equivalence
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 information is desired from the Next Hop Resolution Reply then the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Prefix Length extension is included in the Next Hop
| Destination Mask (variable lenfth) | 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.
The size of the mask in number of octets is obtained through the In the case of an NHRP Registration Request, if equivalence
"Proto Length" in the Mandatory Part of packet. 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.
For example, in the case of IPv4, if an initiator would like to In the case of an Next Hop Purge Request, if equivalence information
receive this equivalence information, it SHALL add this extension to is desired then the Prefix Length value is set to the length of the
the NHRP Request with a value of 255.255.255.255. The responder prefix of the Target Protocol Address which represents the
SHALL copy the extension to the NHRP Reply and modify the mask equivalence information to be purged. In Next Hop Purge Reply, the
appropriately. 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 the subnetwork. This can be used as a validity check to ensure that an
request does not leave a particular NBMA subnetwork. The extension NHRP packet does not leave a particular NBMA subnetwork. The
is placed in an NHRP Request packet by the initiator with an ID value extension is placed in a "request" packet with an ID value of zero.
of zero; the first NHS fills in the field with the identifier(s) for The first NHS along the routed path fills in the field with the
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA Subnetwork ID | | NBMA Subnetwork ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
Each identifier consists of a 32 bit globally unique value assigned Each identifier consists of a 32 bit globally unique value assigned
to the NBMA subnetwork. This value should be chosen from the IP to the NBMA subnetwork. This value may be chosen from the
address space administered by the operators of the NBMA subnetwork. internetworking layer address space administered by the operators of
the NBMA subnetwork if such an address can fit into a 32 bit field.
This value is used for identification only, not for routing or any This value is used for identification only, not for routing or any
other purpose. other purpose.
Each NHS processing an NHRP Request SHALL verify these values. If Each NHS processing a "request" or "reply" SHALL verify these values.
none of the values matches the NHS's NBMA Subnetwork ID, the NHS If the value is not zero and none of the values matches the NHS's
SHALL return an Error Indication of type "Subnetwork ID Mismatch" and NBMA Subnetwork ID, the NHS SHALL return an NHRP Error Indication to
discard the NHRP Request. the entity identified in Source Protocol Address if the packet type
is a "request" and to the Destination Protocol Address if the packet
When an NHS is building an NHRP Reply and the NBMA Subnetwork ID type is a "reply". The error indicated in this case is "Subnetwork
extension is present in the NHRP Request, the NBMA Subnetwork ID ID Mismatch". The packet is discarded by the station sending the
extension SHALL be copied from the Request to the Reply, including NHRP Error Indication.
all values carried therein.
Each NHS processing an NHRP Reply SHALL verify the values carried in When an NHS is building a "reply" and the NBMA Subnetwork ID
the NBMA Subnetwork ID extension, if present. If none of the values extension is present in the correspond "request" then the NBMA
matches the NHSs NBMA Subnetwork ID, the NHS SHALL return an Error Subnetwork ID extension SHALL be copied from the "request" to the
Indication of type "Subnetwork ID Mismatch" and discard the NHRP "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 = 4
This extension is used to determine the Protocol address of the NHRP This extension is used to determine the address of the NHRP
Responder, that is, the entity that generates the NHRP Reply packet. responder; i.e., the entity that generates the appropriate "reply"
The intent is to identify the entity responding to the request, which packet for a given "request" packet. In the case of an Next Hop
may be different (in the case of cached replies) than the system Resolution Request, the station responding may be different (in the
identified in the Next Hop field of the reply, and to aid in case of cached replies) than the system identified in the Next Hop
detecting loops in the NHRP forwarding path. field of the Next Hop Resolution Reply. Further, this extension may
aid in detecting loops in the NHRP forwarding path.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder's Protocol Address | | unused | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res Addr T/L | Res SAddr T/L| Res Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The size of the Responder's Protocol Address in octets is obtained Holding Time
through the "Proto Length" in the Mandatory Part of packet. The Holding Time field specifies the number of seconds for which
the NBMA information is considered to be valid. Cached information
SHALL be discarded when the holding time expires.
If a requester desires this information, it SHALL include this Res Addr T/L
extension, with a value of zero, in the NHRP Request packet. Type & length of the responder NHS's NBMA address interpreted in
the context of the 'address family number'[6] indicated by ar$afn
(e.g., ar$afn=0x0003 for ATM). When the address length is
specified as 0 no storage is allocated for the address.
If an NHS is generating an NHRP Reply packet in response to a request Res SAddr T/L
containing this extension, it SHALL include this extension, Type & length of responder NHS's NBMA subaddress interpreted in the
containing its Protocol address, in the NHRP Reply. If an NHS has context of the 'address family number'[6] indicated by ar$afn
more than one Protocol address, it SHALL use the same Protocol (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and the
address consistently in all of the Responder Address, Forward NHS subaddress an ATM Forum NSAP address). When an NBMA technology has
Record, and Reverse NHS Record extensions. The choice of which of no concept of a subaddress, the subaddress is always null with a
several Protocol addresses to include in this extension is a local length of 0. When the address length is specified as 0 no storage
matter. is allocated for the address.
Res Proto Len
This field holds the length in octets of responding NHS's Protocol
Address.
Responder NBMA Address
This is the NBMA address of the responding NHS.
Responder NBMA SubAddress
This is the NBMA subaddress of the responding NHS.
Responder Protocol Address
This is the Protocol Address of responding NHS.
If a "requester" desires this information, the "requester" SHALL
include this extension with a value of zero. Note that this implies
that no storage is allocated for the Holding Time and Type/Length
fields until the "Value" portion of the extension is filled out.
If an NHS is generating a "reply" packet in response to a "request"
containing this extension, the NHS SHALL include this extension,
containing its protocol address in the "reply". If an NHS has more
than one protocol address, it SHALL use the same protocol address
consistently in all of the Responder Address, Forward NHS Record, and
Reverse NHS Record extensions. The choice of which of several
protocol address to include in this extension is a local matter.
If an NHRP Next Hop Resolution Reply packet being forwarded by an NHS If an NHRP Next Hop Resolution Reply packet being forwarded by an NHS
contains an Protocol address of that NHS in the Responder Address contains a protocol address of that NHS in the Responder Address
Extension, the NHS SHALL generate an Error Indication of type "NHRP Extension then that NHS SHALL generate an NHRP Error Indication of
Loop Detected" and discard the Next Hop Resolution Reply. type "NHRP Loop Detected" and discard the Next Hop Resolution Reply.
If an NHRP Next Hop Resolution Reply packet is being returned by an If an NHRP Next Hop Resolution Reply packet is being returned by an
intermediate NHS based on cached data, it SHALL place its own intermediate NHS based on cached data, it SHALL place its own address
address in this extension (differentiating it from the address in the in this extension (differentiating it from the address in the Next
Next Hop field). Hop field).
5.3.4 NHRP Forward NHS Record Extension 5.3.4 NHRP Forward Transit NHS Record Extension
Compulsory = 1 Compulsory = 1
Type = 4 Type = 4
Length = variable Length = variable
The NHRP forward NHS record is a list of NHSs through which an NHRP The NHRP Forward Transit NHS record contains a list of transit NHSs
request traverses. Each NHS SHALL append a Next Hop element through which a "request" has traversed. Each NHS SHALL append to
containing its Protocol address to this extension. the extension a Forward Transit NHS element (as specified below)
containing its Protocol address The extension length field and the
ar$chksum fields SHALL be adjusted appropriately.
The responding NHS, as described in Section 5.3.3, SHALL NOT update
this extension.
In addition, NHSs that are willing to act as egress routers for In addition, NHSs that are willing to act as egress routers for
packets from the source to the destination SHALL include information packets from the source to the destination SHALL include information
about their NBMA Address. about their NBMA Address.
The Forward Transit NHS element has the following form:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | Proto Length | Holding Time | | unused | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHS Addr T/L | NHS SAddr T/L| unused | | NHS Addr T/L | NHS SAddr T/L| NHS Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Address (variable length) | | NHS NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Address (variable length) | | NHS NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Subaddress (variable length) | | NHS Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Proto Length
The length in octets, of the internetwork layer protocol addresses
appearing in this packet. If this length is not a multiple of 4,
each internetwork layer address is zero-filled to the nearest 32-
bit boundary.
Holding Time Holding Time
The Holding Time field specifies the number of seconds for which The Holding Time field specifies the number of seconds for which
the NBMA information is considered to be valid. Cached information the NBMA information is considered to be valid. Cached information
SHALL be discarded when the holding time expires. Must be set to 0 SHALL be discarded when the holding time expires.
on a NAK.
NHS Addr T/L NHS Addr T/L
Type & length of transit NHS's NBMA address interpreted in the Type & length of the transit NHS's NBMA address interpreted in the
context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., context of the 'address family number'[6] indicated by ar$afn
ar$afn=0x0003 for ATM). When the address length is specified as 0 (e.g., ar$afn=0x0003 for ATM). When the address length is
no storage is allocated for the address. Set to 0 on a NAK. specified as 0 no storage is allocated for the address.
NHS SAddr T/L NHS SAddr T/L
Type & length of transit NHS's NBMA subaddress interpreted in the Type & length of the transit NHS's NBMA subaddress interpreted in
context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., the context of the 'address family number'[6] indicated by ar$afn
ar$afn=0x0003 for ATM). When an NBMA technology has no concept of (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and the
a subaddress the subaddress is always null with a length of 0. subaddress an ATM Forum NSAP address). When an NBMA technology has
When the address length is specified as 0 no storage is allocated no concept of a subaddress the subaddress is always null with a
for the address. Set to 0 on a NAK. length of 0. When the address length is specified as 0 no storage
is allocated for the address.
NHS Protocol Address NHS Proto Len
This internetworkin layer address specifies the transit NHS. This This field holds the length in octets of the transit NHS's Protocol
will be the address of the destination host if it is directly Address.
attached to the NBMA subnetwork, or the egress router if it is not
directly attached.
NHS NBMA Address NHS NBMA Address
This is the NBMA address of the station that is the transit NHS for This is the NBMA address of the transit NHS.
packets bound for the internetworking layer address specified. The
NBMA address field itself is zero-filled to the nearest 32-bit
boundary.
NHS NBMA SubAddress NHS NBMA SubAddress
This is the NBMA sub address of the station that is the transit NHS This is the NBMA subaddress of the transit NHS.
for packets bound for the internetworking layer address specified.
The NBMA subaddress field itself is zero-filled to the nearest 32-
bit boundary.
If a requester wishes to obtain this information, it SHALL include
this extension with a length of zero.
Each NHS SHALL append an appropriate Next Hop element to this NHS Protocol Address
extension when processing an NHRP Request. The extension length This is the Protocol Address of the transit NHS.
field and NHRP checksum SHALL be adjusted as necessary.
The last Hop NHS (the one that will be generating the NHRP Reply) If a "requester" wishes to obtain this information, it SHALL include
SHALL NOT update this extension (since this information will be in this extension with a length of zero. Note that this implies that no
the reply). storage is allocated for the Holding Time and Type/Length fields
until the "Value" portion of the extension is filled out.
If an NHS has more than one Protocol address, it SHALL use the same If an NHS has more than one Protocol address, it SHALL use the same
Protocol address consistently in all of the Responder Address, Protocol address consistently in all of the Responder Address,
Forward NHS Record, and Reverse NHS Record extensions. The choice of Forward NHS Record, and Reverse NHS Record extensions. The choice of
which of several Protocol addresses to include in this extension is a which of several Protocol addresses to include in this extension is a
local matter. local matter.
If an NHRP Request packet being forwarded by an NHS contains the If a "request" that is being forwarded by an NHS contains the
Protocol address of that NHS in the Forward NHS Record Extension, the Protocol Address of that NHS in one of the Forward Transit NHS
NHS SHALL generate an Error Indication of type "NHRP Loop Detected" elements then the NHS SHALL generate an NHRP Error Indication of type
and discard the Request. "NHRP Loop Detected" and discard the "request".
5.3.5 NHRP Reverse NHS Record Extension 5.3.5 NHRP Reverse Transit NHS Record Extension
Compulsory = 1 Compulsory = 1
Type = 5 Type = 5
Length = variable Length = variable
The NHRP reverse NHS record is a list of NHSs through which an NHRP The NHRP Reverse Transit NHS record contains a list of transit NHSs
reply traverses. Each NHS SHALL append a Next Hop element containing through which a "reply" has traversed. Each NHS SHALL append a
its Protocol address to this extension. Reverse Transit NHS element (as specified below) containing its
Protocol address to this extension. The extension length field and
ar$chksum SHALL be adjusted appropriately.
The responding NHS, as described in Section 5.3.3, SHALL NOT update
this extension.
In addition, NHSs that are willing to act as egress routers for In addition, NHSs that are willing to act as egress routers for
packets from the source to the destination SHALL include information packets from the source to the destination SHALL include information
about their NBMA Address. about their NBMA Address.
The Reverse Transit NHS element has the following form:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | Proto Length | Holding Time | | unused | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHS Addr T/L | NHS SAddr T/L| unused | | NHS Addr T/L | NHS SAddr T/L| NHS Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Address (variable length) | | NHS NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Address (variable length) | | NHS NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Subaddress (variable length) | | NHS Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Proto Length
The length in octets, of the internetwork layer protocol addresses
appearing in this packet. If this length is not a multiple of 4,
each internetwork layer address is zero-filled to the nearest 32-
bit boundary.
Holding Time Holding Time
The Holding Time field specifies the number of seconds for which The Holding Time field specifies the number of seconds for which
the NBMA information is considered to be valid. Cached information the NBMA information is considered to be valid. Cached information
SHALL be discarded when the holding time expires. Must be set to 0 SHALL be discarded when the holding time expires.
on a NAK.
NHS Addr T/L NHS Addr T/L
Type & length of transit NHS's NBMA address interpreted in the Type & length of the responding NHS's NBMA address interpreted in
context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., the context of the 'address family number'[6] indicated by ar$afn
ar$afn=0x0003 for ATM). When the address length is specified as 0 (e.g., ar$afn=0x0003 for ATM). When the address length is
no storage is allocated for the address. Set to 0 on a NAK. specified as 0 no storage is allocated for the address.
NHS SAddr T/L NHS SAddr T/L
Type & length of transit NHS's NBMA subaddress interpreted in the Type & length of the responding NHS's NBMA subaddress interpreted
context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., in the context of the 'address family number'[6] indicated by
ar$afn=0x0003 for ATM). When an NBMA technology has no concept of ar$afn (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and
a subaddress the subaddress is always null with a length of 0. the subaddress an ATM Forum NSAP address). When an NBMA technology
When the address length is specified as 0 no storage is allocated has no concept of a subaddress the subaddress is always null with a
for the address. Set to 0 on a NAK. length of 0. When the address length is specified as 0 no storage
is allocated for the address.
NHS Protocol Address NHS Proto Len
This internetworkin layer address specifies the transit NHS. This This field holds the length in octets of the transit NHS's Protocol
will be the address of the destination host if it is directly Address.
attached to the NBMA subnetwork, or the egress router if it is not
directly attached.
NHS NBMA Address NHS NBMA Address
This is the NBMA address of the station that is the transit NHS for This is the NBMA address of the transit NHS.
packets bound for the internetworking layer address specified. The
NBMA address field itself is zero-filled to the nearest 32-bit
boundary.
NHS NBMA SubAddress NHS NBMA SubAddress
This is the NBMA sub address of the station that is the transit NHS This is the NBMA subaddress of the transit NHS.
for packets bound for the internetworking layer address specified.
The NBMA subaddress field itself is zero-filled to the nearest 32-
bit boundary.
If a requester wishes to obtain this information, it SHALL include
this extension with a length of zero.
Each NHS SHALL append an appropriate Next Hop element to this NHS Protocol Address
extension when processing an NHRP Reply. The extension length field This is the Protocol Address of the transit NHS.
and NHRP checksum SHALL be adjusted as necessary.
The NHS generating the NHRP Reply SHALL NOT update this extension. If a "requester" wishes to obtain this information, it SHALL include
this extension with a length of zero. Note that this implies that no
storage is allocated for the Holding Time and Type/Length fields
until the "Value" portion of the extension is filled out.
If an NHS has more than one Protocol address, it SHALL use the same If an NHS has more than one Protocol address, it SHALL use the same
Protocol address consistently in all of the Responder Address, Protocol address consistently in all of the Responder Address,
Forward NHS Record, and Reverse NHS Record extensions. The choice of Forward NHS Record, and Reverse NHS Record extensions. The choice of
which of several Protocol addresses to include in this extension is a which of several Protocol addresses to include in this extension is a
local matter. local matter.
If an NHRP Reply packet being forwarded by an NHS contains the If a "reply" that is being forwarded by an NHS contains the Protocol
Protocol address of that NHS in the Reverse NHS Record Extension, the Address of that NHS in one of the Reverse Transit NHS elements then
NHS SHALL generate an Error Indication of type "NHRP Loop Detected" the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop
and discard the Reply. Detected" and discard the "reply".
Note that this information may be cached at intermediate NHSs; if Note that this information may be cached at intermediate NHSs; if
so, the cached value SHALL be used when generating a reply. Note so, the cached value SHALL be used when generating a reply.
that the Responder Address extension may be used to disambiguate the
set of NHSs that actually processed the reply.
5.3.6 NHRP QoS Extension 5.3.6 NHRP QoS Extension
Compulsory = 0 Compulsory = 0
Type = 6 Type = 6
Length = variable Length = variable
The NHRP QoS Extension is carried in NHRP Request packets to indicate The NHRP QoS Extension is carried in Next Hop Resolution Request
the desired QoS of the path to the indicated destination. This packets to indicate the desired QoS of the path to the indicated
information may be used to help select the appropriate NBMA next hop. destination. This information may be used to help select the
appropriate NBMA Next Hop.
It may also be carried in NHRP Register packets to indicate the QoS It may also be carried in NHRP Register Request packets to indicate
to which the registration applies. the QoS to which the registration applies.
The syntax and semantics of this extension are TBD; alignment with The syntax and semantics of this extension are TBD; alignment with
resource reservation may be useful. resource reservation may be useful.
5.3.7 NHRP Authentication Extension 5.3.7 NHRP Authentication Extension
Compulsory = 1 Compulsory = 1
Type = 7 Type = 7
Length = variable Length = variable
The NHRP Authentication Extension is carried in NHRP packets to The NHRP Authentication Extension is carried in NHRP packets to
convey authentication information between NHRP speakers. The convey authentication information between NHRP speakers. The
Authentication Extension may be included in any NHRP packet type. Authentication Extension may be included in any NHRP "request" or
"reply".
Authentication is done pairwise on an NHRP hop-by Hop basis; the Except in the case of an NHRP Registration Request/Reply
authentication extension is regenerated on each hop. If a received Authentication is done pairwise on an NHRP hop-by-hop basis; i.e.,
packet fails the authentication test, the NHS SHALL generate an Error the authentication extension is regenerated at each hop. In the case
of an NHRP Registration Request/Reply, the Authentication is checked
on an end-to-end basis rather than hop-by-hop. If a received packet
fails the authentication test, the station SHALL generate an Error
Indication of type "Authentication Failure" and discard the packet. Indication of type "Authentication Failure" and discard the packet.
In no case SHALL an Error Indication packet be generated on the Note that one possible authentication failure is the lack of an
receipt of an Error Indication packet, however. Note that one Authentication Extension; the presence or absence of the
possible authentication failure is the lack of an Authentication Authentication Extension is a local matter.
Extension; the presence or absence of the Authentication Extension
is a local matter.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Type | | Authentication Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 38, line 49 skipping to change at page 43, line 9
document. document.
5.3.8 NHRP Vendor-Private Extension 5.3.8 NHRP Vendor-Private Extension
Compulsory = 0 Compulsory = 0
Type = 8 Type = 8
Length = variable Length = variable
The NHRP Vendor-Private Extension is carried in NHRP packets to The NHRP Vendor-Private Extension is carried in NHRP packets to
convey vendor-private information or NHRP extensions between NHRP convey vendor-private information or NHRP extensions between NHRP
speakers. This extension may be used at any time; if the receiver speakers.
does not handle this extension, or does not match the vendor ID in
the extension, then the extension may be completely ignored by the 0 1 2 3
receiver. The first 24 bits of the extension's payload (following 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 length field) contains the 802 vendor ID as assigned by the IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[6]. The remaining octets in the payload are vendor-dependent. | Vendor ID | Data.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID
802 Vendor ID as assigned by the IEEE [6]
Data
The remaining octets after the Vendor ID in the payload are
vendor-dependent data.
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
receiver does not handle this extension, or does not match the Vendor
ID in the extension then the extension may be completely ignored by
the receiver. If a Vendor Private Extension is included in a
"request" then is must be copied in the corresponding "reply".
5.3.9 Additional Next Hop Entries Extension 5.3.9 Additional Next Hop Entries Extension
Compulsory = 0 Compulsory = 0
Type = 9 Type = 9
Length = variable Length = variable
This extension may be used to return multiple Next Hop entries in a This extension may be used to return multiple Next Hop entries in a
single NHRP Reply packet. This extension MUST only be used for single NHRP Reply packet. This extension MUST only be used for
positive replies. The preference values are used to specify the positive replies. The preference values are used to specify the
relative preference of the entries contained in the extension. The relative preference of the entries contained in the extension. The
same next Hop Protocol address may be associated with multiple NBMA same next Hop Protocol address may be associated with multiple NBMA
addresses. Load-splitting may be performed over the addresses, given addresses. Load-splitting may be performed over the addresses, given
equal preference values, and the alternative addresses may be used in equal preference values, and the alternative addresses may be used in
case of connectivity failure in the NBMA subnetwork (such as a failed case of connectivity failure in the NBMA subnetwork (such as a failed
call attempt in connection-oriented NBMA subnetworks). 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | Proto Length | Next Hop Holding Time | | Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH Addr T/L | NH SAddr T/L | Preference | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Protocol Address (variable length) | | NH Addr T/L | NH SAddr T/L | NH Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Address (variable length) | | Next Hop NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Subaddress (variable length) | | Next Hop NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..................... | Next Hop Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | Proto Length | Next Hop Holding Time | .....................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH Addr T/L | NH SAddr T/L | Preference | unused | | Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Protocol Address (variable length) | | NH Addr T/L | NH SAddr T/L | NH Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Address (variable length) | | Next Hop NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop NBMA Subaddress (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 An NHS is not allowed to reply to an NHRP request for authoritative
information with cached information, but may do so for an NHRP information with cached information, but may do so for an NHRP
Request which indicates a request for non-authoritative information. Request which indicates a request for non-authoritative information.
An NHS may reply to an NHRP request for non-authoritative information An NHS may reply to an NHRP request for non-authoritative information
with authoritative information. with authoritative information.
Proto Length Maximum Transmission Unit
The length in octets, of the internetwork layer protocol addresses This field gives the maximum transmission unit for the target
appearing in this packet. If this length is not a multiple of 4, station. If this value is 0 then either the default MTU is used or
each internetwork layer address is zero-filled to the nearest 32- the MTU negotiated via signaling is used if such negotiation is
bit boundary. possible for the given NBMA.
Next Hop Holding Time Holding Time
The Next Hop Address Holding Time field specifies the number of The Holding Time field specifies the number of seconds for which
seconds for which the next hop NBMA information is considered to be the Next Hop NBMA information specified in the Next Hop Entry is
valid. Cached information SHALL be discarded when the holding time considered to be valid. Cached information SHALL be discarded when
expires. Must be set to 0 on a NAK. the holding time expires. This field must be set to 0 on a NAK.
NH Addr T/L NH Addr T/L
Type & length of next hop NBMA address interpreted in the context Type & length of next hop NBMA address specified in the Next Hop
of the 'hardware' (NBMA media) indicated by ar$afn (e.g., Entry. This field is interpreted in the context of the 'address
ar$afn=0x0003 for ATM). When the address length is specified as 0 family number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for
no storage is allocated for the address. Set to 0 on a NAK. ATM).
NH SAddr T/L NH SAddr T/L
Type & length of next hop NBMA subaddress interpreted in the Type & length of next hop NBMA subaddress specified in the Next Hop
context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., Entry. This field is interpreted in the context of the 'address
ar$afn=0x0003 for ATM). When an NBMA technology has no concept of family number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM
a subaddress the subaddress is always null with a length of 0. makes the address an E.164 and the subaddress an ATM Forum NSAP
When the address length is specified as 0 no storage is allocated address). When an NBMA technology has no concept of a subaddress
for the address. Set to 0 on a NAK. 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.
Preference NH Proto Len
This field specifies the preference of the Next Hop entry, relative This field holds the length in octets of the Next Hop Protocol
to other Next Hop entries in this NHRP Reply packet which may be in Address specified in the Next Hop Entry.
the Additional Next Hop Entries Extension for the given
internetworking protocol. Higher values indicate more preferable
Next Hop entries. Action taken when multiple next hop entries have
the highest preference value is a local matter. Set to 0 on a NAK.
Next Hop Protocol Address Preference
This internetworkin layer address specifies the next hop. This This field specifies the preference of the specific Next Hop Entry
will be the address of the destination host if it is directly relative to other Next Hop entries in this Next Hop Resolution
attached to the NBMA subnetwork, or the egress router if it is not Reply mandatory part or in the Additional Next Hop Entries
directly attached. 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 Next Hop NBMA Address
This is the NBMA address of the station that is the next hop for This is the NBMA address of the station that is the next hop for
packets bound for the internetworking layer address specified. The packets bound for the internetworking layer address specified.
NBMA address field itself is zero-filled to the nearest 32-bit
boundary.
Next Hop NBMA SubAddress Next Hop NBMA SubAddress
This is the NBMA sub address of the station that is the next hop This is the NBMA subaddress of the station that is the next hop for
for packets bound for the internetworking layer address specified. packets bound for the internetworking layer address specified.
The NBMA subaddress field itself is zero-filled to the nearest 32-
bit boundary. 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 42, line 26 skipping to change at page 46, line 26
lies outside of the NBMA subnetwork, since such mechanisms will be lies outside of the NBMA subnetwork, since such mechanisms will be
more tightly coupled to the state of the routing system and will more tightly coupled to the state of the routing system and will
probably be less likely to create loops. probably be less likely to create loops.
6.2 Cache Management Issues 6.2 Cache Management Issues
The management of NHRP caches in the source station, the NHS serving The management of NHRP caches in the source station, the NHS serving
the destination, and any intermediate NHSs is dependent on a number the destination, and any intermediate NHSs is dependent on a number
of factors. of factors.
6.2.1 Cacheing Requirements 6.2.1 Caching Requirements
Source Stations Source Stations
Source stations MUST cache all received replies that they are Source stations MUST cache all received Next Hop Resolution Replies
actively using. They also must cache "incomplete" entries, i.e., that they are actively using. They also must cache "incomplete"
those for which a request has been sent but which a reply has not entries, i.e., those for which a Next Hop Resolution Request has
been received. This is necessary in order to preserve the Request been sent but which a Next Hop Resolution Reply has not been
ID for retries, and provides the state necessary to avoid received. This is necessary in order to preserve the Request ID
triggering requests for every data packet sent to the destination. for retries, and provides the state necessary to avoid triggering
Next Hop Resolution Requests for every data packet sent to the
destination.
Source stations MUST purge expired information from their caches. Source stations MUST purge expired information from their caches.
Source stations MUST purge the appropriate cached information upon Source stations MUST purge the appropriate cached information upon
receipt of an NHRP Purge request packet. receipt of an NHRP Purge Request packet.
Source stations that are also NHSs may return cached information When a station has a co-resident client and NHS, the station may
learned in response to its own Next Hop Resolution Request packets reply to Next Hop Resolution Requests with information which the
in reply to requests it receives, within the rules for Transit NHSs station cached as a result of the station making its own Next Hop
below. Resolution Requests and receiving its own Next Hop Resolution
Replies as long as the station follows the rules for Transit NHSs
as seen below.
Serving NHSs Serving NHSs
The NHS serving the destination (the one which responds The NHS serving the destination (the one which responds
authoritatively to Next Hop Resolution Requests) SHOULD cache authoritatively to Next Hop Resolution Requests) SHOULD cache
information about all requests to which it has responded if the information about all Next Hop Resolution Requests to which it has
information in the reply has the possibility of changing during its responded if the information in the Next Hop Resolution Reply has
lifetime (so that an NHRP Purge request packet can be sent). The the possibility of changing during its lifetime (so that an NHRP
NBMA information provided by the source station in the Next Hop Purge Request packet can be sent). The NBMA information provided
Resolution Request may be cached for the duration of its holding by the source station in the Next Hop Resolution Request may be
time. This information is considered to be stable, since it cached for the duration of its holding time. This information is
identifies a station directly attached to the NBMA subnetwork. An considered to be stable, since it identifies a station directly
example of unstable information is NBMA information derived from a attached to the NBMA subnetwork. An example of unstable
routing table, where that routing table information has not been information is NBMA information derived from a routing table, where
guaranteed to be stable through administrative means. that routing table information has not been guaranteed to be stable
through administrative means.
Transit NHSs Transit NHSs
A Transit NHS (lying along the NHRP path between the source station A Transit NHS (lying along the NHRP path between the source station
and the responding NHS) may cache information contained in Next Hop and the responding NHS) may cache information contained in Next Hop
Resolution Request packets that it forwards. A Transit NHS may Resolution Request packets that it forwards. A Transit NHS may
cache information contained in NHRP Reply packets that it forwards cache information contained in Next Hop Resolution Reply packets
only if that reply has the Stable (B) bit set. It MUST discard any that it forwards only if that Next Hop Resolution Reply has the
cached information whose holding time has expired. It may return Stable (B) bit set. It MUST discard any cached information whose
cached information in response to non-authoritative requests only. holding time has expired. It may return cached information in
response to non-authoritative Next Hop Resolution Requests only.
6.2.2 Dynamics of Cached Information 6.2.2 Dynamics of Cached Information
NBMA-Connected Destinations NBMA-Connected Destinations
NHRP's most basic function is that of simple NBMA address NHRP's most basic function is that of simple NBMA address
resolution of stations directly attached to the NBMA subnetwork. resolution of stations directly attached to the NBMA subnetwork.
These mappings are typically very static, and appropriately chosen These mappings are typically very static, and appropriately chosen
holding times will minimize problems in the event that the NBMA holding times will minimize problems in the event that the NBMA
address of a station must be changed. Stale information will cause address of a station must be changed. Stale information will cause
a loss of connectivity, which may be used to trigger an a loss of connectivity, which may be used to trigger an
authoritative Next Hop Resolution Request and bypass the old data. authoritative Next Hop Resolution Request and bypass the old data.
In the worst case, connectivity will fail until the cache entry In the worst case, connectivity will fail until the cache entry
times out. times out.
This applies equally to information marked in replies as being This applies equally to information marked in Next Hop Resolution
"stable" (via the "B" bit). Replies as being "stable" (via the "B" bit).
This also applies equally well to source stations that are routers This also applies equally well to source stations that are routers
as well as those which are hosts. as well as those which are hosts.
Note that the information carried in the Next Hop Resolution Note that the information carried in the Next Hop Resolution
Request packet is always considered "stable" because it represents Request packet is always considered "stable" because it represents
a station that is directly connected to the NBMA subnetwork. a station that is directly connected to the NBMA subnetwork.
Destinations Off of the NBMA Subnetwork Destinations Off of the NBMA Subnetwork
If the source of a request is a host and the destination is not If the source of a Next Hop Resolution Request is a host and the
directly attached to the NBMA subnetwork, and the route to that destination is not directly attached to the NBMA subnetwork, and
destination is not considered to be "stable," the destination the route to that destination is not considered to be "stable," the
mapping may be very dynamic (except in the case of a subnetwork destination mapping may be very dynamic (except in the case of a
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 Strategies for maintaining NHRP cache information in the presence
of dynamic routing changes will be discussed in a separate of dynamic routing changes will be discussed in a separate
document. document.
6.3 Use of the Destination Prefix Extension 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 Destination
Prefix Extension, in particular with regard to the prefix length Prefix Length Extension, in particular with regard to the prefix
advertised (and thus the size of the equivalence class specified by length advertised (and thus the size of the equivalence class
it). Assuming that the routers on the NBMA subnetwork are exchanging specified by it). Assuming that the routers on the NBMA subnetwork
routing information, it should not be possible for an NHS to create a are exchanging routing information, it should not be possible for an
black hole by advertising too large of a set of destinations, but NHS to create a black hole by advertising too large of a set of
suboptimal routing (e.g., extra internetwork layer hops through the destinations, but suboptimal routing (e.g., extra internetwork layer
NBMA) can result. To avoid this situation an NHS that wants to send hops through the NBMA) can result. To avoid this situation an NHS
the Destination Prefix Extension MUST obey the following rule: that wants to send the Destination Prefix Length Extension MUST obey
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 IP address in the the destination (as specified by the Destination internetwork layer
Next Hop Resolution Request), and extracts from this NLRI the address in the Next Hop Resolution Request), and extracts from this
shortest address prefix such that: (a) the Destination IP address NLRI the shortest address prefix such that: (a) the Destination
(from the Next Hop Resolution Request) is covered by the prefix, internetwork layer address (from the Next Hop Resolution Request)
(b) the NHS does not have any routes with NLRI that forms a subset is covered by the prefix, (b) the NHS does not have any routes with
of what is covered by the prefix. The prefix may then be used for NLRI that forms a subset of what is covered by the prefix. The
the Destination Prefix Extension. prefix may then be used for the Destination Prefix Length
Extension.
The NHRP Destination Prefix Extension should be used with restraint, The NHRP Destination Prefix Length Extension should be used with
in order to avoid NHRP stations choosing suboptimal transit paths restraint, in order to avoid NHRP stations choosing suboptimal
when overlapping prefixes are available. This extension SHOULD only transit paths when overlapping prefixes are available. This
be used in an NHRP Reply when either: extension SHOULD only be used in a Next Hop Resolution Reply when
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 For other cases, there may be no single optimal transit path for
destinations encompassed by the address prefix, and an NHRP station destinations encompassed by the address prefix, and an NHRP station
may fail to choose the optimal transit path simply because it is not 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 aware of all such paths. So for cases not covered by (a) and (b), an
NHRP Reply packet should not include the NHRP Destination Prefix Next Hop Resolution Reply packet should not include the NHRP
Extension. Destination Prefix Length Extension.
6.4 Domino Effect 6.4 Domino Effect
One could easy 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.
skipping to change at page 45, line 40 skipping to change at page 49, line 48
Possibly the most straightforward solution for suppressing the domino Possibly the most straightforward solution for suppressing the domino
effect would be to require transit routers to be preconfigured not to effect would be to require transit routers to be preconfigured not to
originate Next Hop Resolution Requests for data traffic which is originate Next Hop Resolution Requests for data traffic which is
simply being forwarded (not originated). In this case the routers simply being forwarded (not originated). In this case the routers
avoid the domino effect through an administrative policy. avoid the domino effect through an administrative policy.
A second possible solution would be to require that when a router A second possible solution would be to require that when a router
forwards an Next Hop Resolution Request, the router instantiates a forwards an Next Hop Resolution Request, the router instantiates a
(short-lived) state. This state consists of the route that was used (short-lived) state. This state consists of the route that was used
to forward the request. If the router receives a data packet, and to forward the Next Hop Resolution Request. If the router receives a
the packet triggers an Next Hop Resolution Request generation by the data packet, and the packet triggers an Next Hop Resolution Request
router, the router checks whether the route to forward the request generation by the router, the router checks whether the route to
was recently used to forward some other Next Hop Resolution Request. forward the Next Hop Resolution Request was recently used to forward
If so, then the router suppresses generation of the new request (but 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 still forwards the data packet). This solution also requires that
when a station attempts to originate an Next Hop Resolution Request when a station attempts to originate an Next Hop Resolution Request
the station should send the Next Hop Resolution Request before the the station should send the Next Hop Resolution Request before the
data packet that triggered the origination of the request. data packet that triggered the origination of the Next Hop Resolution
Otherwise, unnecessary Next Hop Resolution Requests may still be Request. Otherwise, unnecessary Next Hop Resolution Requests may
generated. still be generated.
A third possible strategy would be to configure a router in such a A third possible strategy would be to configure a router in such a
way that Next Hop Resolution Request generation by the router would way that Next Hop Resolution Request generation by the router would
be driven only by the traffic the router receives over its non-NBMA be driven only by the traffic the router receives over its non-NBMA
interfaces (interfaces that are not attached to an NBMA subnetwork). interfaces (interfaces that are not attached to an NBMA subnetwork).
Traffic received by the router over its NBMA-attached interfaces Traffic received by the router over its NBMA-attached interfaces
would not trigger NHRP Next Hop Resolution Requests. Just as in the would not trigger NHRP Next Hop Resolution Requests. Just as in the
first case, such a router avoids the NHRP domino effect through first case, such a router avoids the NHRP domino effect through
administrative means. administrative means.
Lastly, rate limiting of Next Hop Resolution Requests may help to Lastly, rate limiting of Next Hop Resolution Requests may help to
avoid the NHRP domino effect. Intermediate routers which would avoid the NHRP domino effect. Intermediate routers which would
otherwise generate unnecessary Next Hop Resolution Requests may otherwise generate unnecessary Next Hop Resolution Requests may
instead suppress such requests due to the measured request rate instead suppress such Next Hop Resolution Requests due to the
exceeding a certain threshold. Of course, such rate limiting would measured Next Hop Resolution Request rate exceeding a certain
have to be very aggressive in order to completely avoid the domino threshold. Of course, such rate limiting would have to be very
effect. Further work is needed to analyze this solution. aggressive in order to completely avoid the domino effect. Further
work is needed to analyze this solution.
7. Security Considerations 7. 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
skipping to change at page 46, line 43 skipping to change at page 51, line 5
attacks. attacks.
Detailed security analysis of this protocol is for further study. Detailed security analysis of this protocol is for further study.
8. Discussion 8. 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 NHRP replies always return the NBMA address of the destination the Next Hop Resolution Replies always return the NBMA address of the
station itself rather than the NBMA address of some egress router. destination station itself rather than the NBMA address of some
On the other hand, if the routed path exits the NBMA subnetwork, NHRP egress router. On the other hand, if the routed path exits the NBMA
will be unable to resolve the NBMA address of the destination, but subnetwork, NHRP will be unable to resolve the NBMA address of the
rather will return the address of the egress router. For destination, but rather will return the address of the egress router.
destinations outside the NBMA subnetwork, egress routers and routers For destinations outside the NBMA subnetwork, egress routers and
in the other subnetworks should exchange routing information so that routers in the other subnetworks should exchange routing information
the optimal egress router may be found. so that the optimal egress router may be found.
In addition to NHSs, an NBMA station could also be associated with In addition to NHSs, an NBMA station could also be associated with
one or more regular routers that could act as "connectionless one or more regular routers that could act as "connectionless
servers" for the station. The station could then choose to resolve servers" for the station. The station could then choose to resolve
the NBMA next hop or just send the IP 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
IP 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, draft-ietf-rolc-nbma-arp-00.txt.
[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.
 End of changes. 249 change blocks. 
850 lines changed or deleted 1084 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/