RFC2332 - NBMA Next Hop Resolution Protocol (NHRP)

Network Working Group J. LUCiani
Request for Comments: 2332 Bay Networks
Category: Standards Track D. Katz
cisco Systems
D. Piscitello
Core Competence, Inc.
B. Cole
Juniper Networks
N. Doraswamy
Bay Networks
April 1998
NBMA Next Hop Resolution Protocol (NHRP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document describes the NBMA Next Hop Resolution Protocol (NHRP).
NHRP can be used by a source station (host or router) connected to a
Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
internetworking layer address and NBMA subnetwork addresses of the
"NBMA next hop" towards a destination station. If the destination is
connected to the NBMA subnetwork, then the NBMA next hop is the
destination station itself. Otherwise, the NBMA next hop is the
egress router from the NBMA subnetwork that is "nearest" to the
destination station. NHRP is intended for use in a multiprotocol
internetworking layer environment over NBMA subnetworks.
Note that while this protocol was developed for use with NBMA
subnetworks, it is possible, if not likely, that it will be applied
to BMA subnetworks as well. However, this usage of NHRP is for
further study.
This document is intended to be a functional superset of the NBMA
Address Resolution Protocol (NARP) documented in [1].
Operation of NHRP as a means of establishing a transit path across an
NBMA subnetwork between two routers will be addressed in a separate
document (see [13]).
1. Introduction
The keyWords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [15].
The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
(a host or router), wishing to communicate over a Non-Broadcast,
Multi-Access (NBMA) subnetwork, to determine the internetworking
layer addresses and NBMA addresses of suitable "NBMA next hops"
toward a destination station. A subnetwork can be non-broadcast
either because it technically doesn"t support broadcasting (e.g., an
X.25 subnetwork) or because broadcasting is not feasible for one
reason or another (e.g., an SMDS multicast group or an extended
Ethernet would be too large). If the destination is connected to the
NBMA subnetwork, then the NBMA next hop is the destination station
itself. Otherwise, the NBMA next hop is the egress router from the
NBMA subnetwork that is "nearest" to the destination station.
One way to model an NBMA network is by using the notion of logically
independent IP subnets (LISs). LISs, as defined in [3] and [4], have
the following properties:
1) All members of a LIS have the same IP network/subnet number
and address mask.
2) All members of a LIS are directly connected to the same
NBMA subnetwork.
3) All hosts and routers outside of the LIS are accessed via
a router.
4) All members of a LIS access each other directly (without
routers).
Address resolution as described in [3] and [4] only resolves the next
hop address if the destination station is a member of the same LIS as
the source station; otherwise, the source station must forward
packets to a router that is a member of multiple LIS"s. In multi-LIS
configurations, hop-by-hop address resolution may not be sufficient
to resolve the "NBMA next hop" toward the destination station, and IP
packets may have multiple IP hops through the NBMA subnetwork.
Another way to model NBMA is by using the notion of Local Address
Groups (LAGs) [10]. The essential difference between the LIS and the
LAG models is that while with the LIS model the outcome of the
"local/remote" forwarding decision is driven purely by addressing
information, with the LAG model the outcome of this decision is
decoupled from the addressing information and is coupled with the
Quality of Service and/or traffic characteristics. With the LAG
model any two entities on a common NBMA network could establish a
direct communication with each other, irrespective of the entities"
addresses.
Support for the LAG model assumes the existence of a mechanism that
allows any entity (i.e., host or router) connected to an NBMA network
to resolve an internetworking layer address to an NBMA address for
any other entity connected to the same NBMA network. This resolution
would take place regardless of the address assignments to these
entities. Within the parameters described in this document, NHRP
describes such a mechanism. For example, when the internetworking
layer address is of type IP, once the NBMA next hop has been
resolved, the source may either start sending IP packets to the
destination (in a connectionless NBMA subnetwork such as SMDS) or may
first establish a connection to the destination with the desired
bandwidth (in a connection-oriented NBMA subnetwork such as ATM).
Use of NHRP may be sufficient for hosts doing address resolution when
those hosts are directly connected to an NBMA subnetwork, allowing
for straightforward implementations in NBMA stations. NHRP also has
the capability of determining the egress point from an NBMA
subnetwork when the destination is not directly connected to the NBMA
subnetwork and the identity of the egress router is not learned by
other methods (such as routing protocols). Optional extensions to
NHRP provide additional robustness and diagnosability.
Address resolution techniques such as those described in [3] and [4]
may be in use when NHRP is deployed. ARP servers and services over
NBMA subnetworks may be required to support hosts that are not
capable of dealing with any model for communication other than the
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
is intended to reduce or eliminate the extra router hops required by
the LIS model, and can be deployed in a non-interfering manner with
existing ARP services [14].
The operation of NHRP to establish transit paths across NBMA
subnetworks between two routers requires additional mechanisms to
avoid stable routing loops, and will be described in a separate
document (see [13]).
2. Overview
2.1 Terminology
The term "network" is highly overloaded, and is especially confusing
in the context of NHRP. We use the following terms:
Internetwork layer--the media-independent layer (IP in the case of
TCP/IP networks).
Subnetwork layer--the media-dependent layer underlying the
internetwork layer, including the NBMA technology (ATM, X.25, SMDS,
etc.)
The term "server", unless eXPlicitly stated to the contrary, refers
to a Next Hop Server (NHS). An NHS is an entity performing the
Next Hop Resolution Protocol service within the NBMA cloud. An NHS
is always tightly coupled with a routing entity (router, route
server or edge device) although the converse is not yet guaranteed
until ubiquitous deployment of this functionality occurs. Note
that the presence of intermediate routers that are not coupled with
an NHS entity may preclude the use of NHRP when source and
destination stations on different sides of such routers and thus
such routers may partition NHRP reachability within an NBMA
network.
The term "client", unless explicitly stated to the contrary, refers
to a Next Hop Resolution Protocol client (NHC). An NHC is an
entity which initiates NHRP requests of various types in order to
oBTain access to the NHRP service.
The term "station" generally refers to a host or router which
contains an NHRP entity. Occasionally, the term station will
describe a "user" of the NHRP client or service functionality; the
difference in usage is largely semantic.
2.2 Protocol Overview
In this section, we briefly describe how a source S (which
potentially can be either a router or a host) uses NHRP to determine
the "NBMA next hop" to destination D.
For administrative and policy reasons, a physical NBMA subnetwork may
be partitioned into several, disjoint "Logical NBMA subnetworks". A
Logical NBMA subnetwork is defined as a collection of hosts and
routers that share unfiltered subnetwork connectivity over an NBMA
subnetwork. "Unfiltered subnetwork connectivity" refers to the
absence of closed user groups, address screening or similar features
that may be used to prevent direct communication between stations
connected to the same NBMA subnetwork. (Hereafter, unless otherwise
specified, we use the term "NBMA subnetwork" to mean *logical* NBMA
subnetwork.)
Placed within the NBMA subnetwork are one or more entities that
implement the NHRP protocol. Such stations which are capable of
answering NHRP Resolution Requests are known as "Next Hop Servers"
(NHSs). Each NHS serves a set of destination hosts, which may or may
not be directly connected to the NBMA subnetwork. NHSs cooperatively
resolve the NBMA next hop within their logical NBMA subnetwork. In
addition to NHRP, NHSs may support "classical" ARP service; however,
this will be the subject of a separate document [14].
An NHS maintains a cache which contains protocol layer address to
NBMA subnetwork layer address resolution information. This cache can
be constructed from information obtained from NHRP Register packets
(see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply
packets, or through mechanisms outside the scope of this document
(examples of such mechanisms might include ARP[3] and pre-configured
tables). Section 6.2 further describes cache management issues.
For a station within a given LIS to avoid providing NHS
functionality, there must be one or more NHSs within the NBMA
subnetwork which are providing authoritative address resolution
information on its behalf. Such an NHS is said to be "serving" the
station. A station on a LIS that lacks NHS functionality and is a
client of the NHRP service is known as NHRP Client or just NHCs. If
a serving NHS is to be able to supply the address resolution
information for an NHC then NHSs must exist at each hop along all
routed paths between the NHC making the resolution request and the
destination NHC. The last NHRP entity along the routed path is the
serving NHS; that is, NHRP Resolution Requests are not forwarded to
destination NHCs but rather are processed by the serving NHS.
An NHC also maintains a cache of protocol address to NBMA address
resolution information. This cache is populated through information
obtained from NHRP Resolution Reply packets, from manual
configuration, or through mechanisms outside the scope of this
document.
The protocol proceeds as follows. An event occurs triggering station
S to want to resolve the NBMA address of a path to D. This is most
likely to be when a data packet addressed to station D is to be
emitted from station S (either because station S is a host, or
station S is a transit router), but the address resolution could also
be triggered by other means (a routing protocol update packet, for
example). Station S first determines the next hop to station D
through normal routing processes (for a host, the next hop may simply
be the default router; for routers, this is the "next hop" to the
destination internetwork layer address). If the destination"s
address resolution information is already available in S"s cache then
that information is used to forward the packet. Otherwise, if the
next hop is reachable through one of its NBMA interfaces, S
constructs an NHRP Resolution Request packet (see Section 5.2.1)
containing station D"s internetwork layer address as the (target)
destination address, S"s own internetwork layer address as the source
address (Next Hop Resolution Request initiator), and station S"s NBMA
addressing information. Station S may also indicate that it prefers
an authoritative NHRP Resolution Reply (i.e., station S only wishes
to receive an NHRP Resolution Reply from an NHS serving the
destination NHC). Station S emits the NHRP Resolution Request packet
towards the destination.
If the NHRP Resolution Request is triggered by a data packet then S
may, while awaiting an NHRP Resolution Reply, choose to dispose of
the data packet in one of the following ways:
(a) Drop the packet
(b) Retain the packet until the NHRP Resolution Reply arrives
and a more optimal path is available
(c) Forward the packet along the routed path toward D
The choice of which of the above to perform is a local policy matter,
though option (c) is the recommended default, since it may allow data
to flow to the destination while the NBMA address is being resolved.
Note that an NHRP Resolution Request for a given destination MUST NOT
be triggered on every packet.
When the NHS receives an NHRP Resolution Request, a check is made to
see if it serves station D. If the NHS does not serve D, the NHS
forwards the NHRP Resolution Request to another NHS. Mechanisms for
determining how to forward the NHRP Resolution Request are discussed
in Section 3.
If this NHS serves D, the NHS resolves station D"s NBMA address
information, and generates a positive NHRP Resolution Reply on D"s
behalf. NHRP Resolution Replies in this scenario are always marked
as "authoritative". The NHRP Resolution Reply packet contains the
address resolution information for station D which is to be sent back
to S. Note that if station D is not on the NBMA subnetwork, the next
hop internetwork layer address will be that of the egress router
through which packets for station D are forwarded.
A transit NHS receiving an NHRP Resolution Reply may cache the
address resolution information contained therein. To a subsequent
NHRP Resolution Request, this NHS may respond with the cached, "non-
authoritative" address resolution information if the NHS is permitted
to do so (see Sections 5.2.2 and 6.2 for more information on non-
authoritative versus authoritative NHRP Resolution Replies). Non-
authoritative NHRP Resolution Replies are distinguished from
authoritative NHRP Resolution Replies so that if a communication
attempt based on non-authoritative information fails, a source
station can choose to send an authoritative NHRP Resolution Request.
NHSs MUST NOT respond to authoritative NHRP Resolution Requests with
cached information.
If the determination is made that no NHS in the NBMA subnetwork can
reply to the NHRP Resolution Request for D then a negative NHRP
Resolution Reply (NAK) is returned. This occurs when (a) no next-hop
resolution information is available for station D from any NHS, or
(b) an NHS is unable to forward the NHRP Resolution Request (e.g.,
connectivity is lost).
NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies,
and NHRP Error Indications follow a routed path in the same fashion
that NHRP Resolution Requests and NHRP Resolution Replies do.
Specifically, "requests" and "indications" follow the routed path
from Source Protocol Address (which is the address of the station
initiating the communication) to the Destination Protocol Address.
"Replies", on the other hand, follow the routed path from the
Destination Protocol Address back to the Source Protocol Address with
the following exceptions: in the case of a NHRP Registration Reply
and in the case of an NHC initiated NHRP Purge Request, the packet is
always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if
one does not exists then one MUST be created.
NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA
subnetwork however further study is being done in this area (see
Section 7). Thus, the internetwork layer data traffic out of and
into an NBMA subnetwork always traverses an internetwork layer router
at its border.
NHRP optionally provides a mechanism to send a NHRP Resolution Reply
which contains aggregated address resolution information. For
example, suppose that router X is the next hop from station S to
station D and that X is an egress router for all stations sharing an
internetwork layer address prefix with station D. When an NHRP
Resolution Reply is generated in response to a NHRP Resolution
Request, the responder may augment the internetwork layer address of
station D with a prefix length (see Section 5.2.0.1). A subsequent
(non-authoritative) NHRP Resolution Request for some destination that
shares an internetwork layer address prefix (for the number of bits
specified in the prefix length) with D may be satisfied with this
cached information. See section 6.2 regarding caching issues.
To dynamically detect subnetwork-layer filtering in NBMA subnetworks
(e.g., X.25 closed user group facility, or SMDS address screens), to
trace the routed path that an NHRP packet takes, or to provide loop
detection and diagnostic capabilities, a "Route Record" may be
included in NHRP packets (see Sections 5.3.2 and 5.3.3). The Route
Record extensions are the NHRP Forward Transit NHS Record Extension
and the NHRP Reverse Transit NHS Record Extension. They contain the
internetwork (and subnetwork layer) addresses of all intermediate
NHSs between source and destination and between destination and
source respectively. When a source station is unable to communicate
with the responder (e.g., an attempt to open an SVC fails), it may
attempt to do so successively with other subnetwork layer addresses
in the NHRP Forward Transit NHS Record Extension until it succeeds
(if authentication policy permits such action). This approach can
find a suitable egress point in the presence of subnetwork-layer
filtering (which may be source/destination sensitive, for instance,
without necessarily creating separate logical NBMA subnetworks) or
subnetwork-layer congestion (especially in connection-oriented
media).
3. Deployment
NHRP Resolution Requests traverse one or more hops within an NBMA
subnetwork before reaching the station that is expected to generate a
response. Each station, including the source station, chooses a
neighboring NHS to which it will forward the NHRP Resolution Request.
The NHS selection procedure typically involves applying a destination
protocol layer address to the protocol layer routing table which
causes a routing decision to be returned. This routing decision is
then used to forward the NHRP Resolution Request to the downstream
NHS. The destination protocol layer address previously mentioned is
carried within the NHRP Resolution Request packet. Note that even
though a protocol layer address was used to acquire a routing
decision, NHRP packets are not encapsulated within a protocol layer
header but rather are carried at the NBMA layer using the
encapsulation described in Section 5.
Each NHS/router examines the NHRP Resolution Request packet on its
way toward the destination. Each NHS which the NHRP packet traverses
on the way to the packet"s destination might modify the packet (e.g.,
updating the Forward Record extension). Ignoring error situations,
the NHRP Resolution Request eventually arrives at a station that is
to generate an NHRP Resolution Reply. This responding station
"serves" the destination. The responding station generates an NHRP
Resolution Reply using the source protocol address from within the
NHRP packet to determine where the NHRP Resolution Reply should be
sent.
Rather than use routing to determine the next hop for an NHRP packet,
an NHS may use other applicable means (such as static configuration
information ) in order to determine to which neighboring NHSs to
forward the NHRP Resolution Request packet as long as such other
means would not cause the NHRP packet to arrive at an NHS which is
not along the routed path. The use of static configuration
information for this purpose is beyond the scope of this document.
The NHS serving a particular destination must lie along the routed
path to that destination. In practice, this means that all egress
routers must double as NHSs serving the destinations beyond them, and
that hosts on the NBMA subnetwork are served by routers that double
as NHSs. Also, this implies that forwarding of NHRP packets within
an NBMA subnetwork requires a contiguous deployment of NHRP capable
routers. It is important that, in a given LIS/LAG which is using
NHRP, all NHSs within the LIS/LAG have at least some portion of their
resolution databases synchronized so that a packet arriving at one
router/NHS in a given LIS/LAG will be forwarded in the same fashion
as a packet arriving at a different router/NHS for the given LIS/LAG.
One method, among others, is to use the Server Cache Synchronization
Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used
when a LIS/LAG contains two or more router/NHSs.
During migration to NHRP, it cannot be expected that all routers
within the NBMA subnetwork are NHRP capable. Thus, NHRP traffic
which would otherwise need to be forwarded through such routers can
be expected to be dropped due to the NHRP packet not being
recognized. In this case, NHRP will be unable to establish any
transit paths whose discovery requires the traversal of the non-NHRP
speaking routers. If the client has tried and failed to acquire a
cut through path then the client should use the network layer routed
path as a default.
If an NBMA technology offers a group, an anycast, or a multicast
addressing feature then the NHC may be configured with such an
address (appropriate to the routing realm it participates in) which
would be assigned to all NHS serving that routing realm. This
address can then be used for establishing an initial connection to an
NHS to transmit a registration request. This address may not be used
for sending NHRP requests. The resulting VC may be used for NHRP
requests if and only if the registration response is received over
that VC, thereby indicating that one happens to have anycast
connected to an NHS serving the LIS/LAG. In the case of non-
connection oriented networks, or of multicast (rather than anycast)
addresses, the addres MUST NOT be used for sending NHRP resolution
requests.
When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined
for the NHC directly to the NHC. That is, the NHRP message MUST NOT
transit through any NHS which is not serving the NHC when the NHRP
message is currently at an NHS which does serve the NHC (this, of
course, assumes the NHRP message is destined for the NHC). Further,
an NHS which serves an NHC SHOULD have a direct NBMA level connection
to that NHC (see Section 5.2.3 and 5.2.4 for examples).
With the exception of NHRP Registration Requests (see Section 5.2.3
and 5.2.4 for details of the NHRP Registration Request case), an NHC
MUST send NHRP messages over a direct NBMA level connection between
the serving NHS and the served NHC.
It may not be desirable to maintain semi-permanent NBMA level
connectivity between the NHC and the NHS. In this case, when NBMA
level connectivity is initially setup between the NHS and the NHC (as
described in Section 5.2.4), the NBMA address of the NHS should be
obtained through the NBMA level signaling technology. This address
should be stored for future use in setting up subsequent NBMA level
connections. A somewhat more information rich technique to obtain
the address information (and more) of the serving NHS would be for
the NHC to include the Responder Address extension (see Section
5.3.1) in the NHRP Registration Request and to store the information
returned to the NHC in the Responder Address extension which is
subsequently included in the NHRP Registration Reply. Note also
that, in practice, a client"s default router should also be its NHS;
thus a client may be able to know the NBMA address of its NHS from
the configuration which was already required for the client to be
able to communicate. Further, as mentioned in Section 4, NHCs may be
configured with the addressing information of one or more NHSs.
4. Configuration
Next Hop Clients
An NHC connected to an NBMA subnetwork MAY be configured with the
Protocol address(es) and NBMA address(es) of its NHS(s). The
NHS(s) will likely also represent the NHC"s default or peer
routers, so their NBMA addresses may be obtained from the NHC"s
existing configuration. If the NHC is attached to several
subnetworks (including logical NBMA subnetworks), the NHC should
also be configured to receive routing information from its NHS(s)
and peer routers so that it can determine which internetwork layer
networks are reachable through which subnetworks.
Next Hop Servers
An NHS is configured with knowledge of its own internetwork layer
and NBMA addresses. An NHS MAY also be configured with a set of
internetwork layer address prefixes that correspond to the
internetwork layer addresses of the stations it serves. The NBMA
addresses of the stations served by the NHS may be learned via NHRP
Registration packets.
If a served NHC is attached to several subnetworks, the
router/route-server coresident with the serving NHS may also need
to be configured to advertise routing information to such NHCs.
If an NHS acts as an egress router for stations connected to other
subnetworks than the NBMA subnetwork, the NHS must, in addition to
the above, be configured to exchange routing information between
the NBMA subnetwork and these other subnetworks.
In all cases, routing information is exchanged using conventional
intra-domain and/or inter-domain routing protocols.
5. NHRP Packet Formats
This section describes the format of NHRP packets. In the following,
unless otherwise stated explicitly, the unqualified term "request"
refers generically to any of the NHRP packet types which are
"requests". Further, unless otherwise stated explicitly, the
unqualified term "reply" refers generically to any of the NHRP packet
types which are "replies".
An NHRP packet consists of a Fixed Part, a Mandatory Part, and an
Extensions Part. The Fixed Part is common to all NHRP packet types.
The Mandatory Part MUST be present, but varies depending on packet
type. The Extensions Part also varies depending on packet type, and
need not be present.
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
offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part
length is equal to total packet length (ar$pktsz) minus 20 otherwise
the mandatory part length is equal to ar$extoff minus 20. The length
of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs
may increase the size of an NHRP packet as a result of extension
processing, but not beyond the offered maximum packet size of the
NBMA network.
NHRP packets are actually members of a wider class of address mapping
and management protocols being developed by the IETF. A specific
encapsulation, based on the native formats used on the particular
NBMA network over which NHRP is carried, indicates the generic IETF
mapping and management protocol. For example, SMDS networks always
use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet
is preceded by the following LLC/SNAP encapsulation:
[0xAA-AA-03] [0x00-00-5E] [0x00-03]
The first three octets are LLC, indicating that SNAP follows. The
SNAP OUI portion is the IANA"s OUI, and the SNAP PID portion
identifies the mapping and management protocol. A field in the Fixed
Header following the encapsulation indicates that it is NHRP.
ATM uses either LLC/SNAP encapsulation of each packet (including
NHRP), or uses no encapsulation on VCs dedicated to a single protocol
(see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or
identification of NHRP, using a NLPID of 0x0080 and the same SNAP
contents as above (see [8], [9]).
Fields marked "unused" MUST be set to zero on transmission, and
ignored on receipt.
Most packet types (ar$op.type) have both internetwork layer
protocol-independent fields and protocol-specific fields. The
protocol type/snap fields (ar$pro.type/snap) qualify the format of
the protocol-specific fields.
5.1 NHRP Fixed Header
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
of packet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$afn ar$pro.type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$pro.snap
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$pro.snap ar$hopcnt ar$pktsz
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$chksum ar$extoff
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$op.version ar$op.type ar$shtl ar$sstl
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$afn
Defines the type of "link layer" addresses being carried. This
number is taken from the "address family number" list specified in
[6]. This field has implications to the coding of ar$shtl and
ar$sstl as described below.
ar$pro.type
field is a 16 bit unsigned integer representing the following
number space:
0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs.
0x0100 to 0x03FF Reserved for future use by the IETF.
0x0400 to 0x04FF Allocated for use by the ATM Forum.
0x0500 to 0x05FF Experimental/Local use.
0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes.
(based on the observations that valid Ethertypes are never smaller
than 0x600, and NLPIDs never larger than 0xFF.)
ar$pro.snap
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
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
zero on transmit and ignored on receive. The ar$pro.type field
itself identifies the protocol being referred to. This is termed
the "short form" protocol ID.
In all cases, where a protocol has an assigned number in the
ar$pro.type space (excluding 0x0080) the short form MUST be used
when transmitting NHRP messages; i.e., if Ethertype or NLPID
codings exist then they are used on transmit rather than the
ethertype. If both Ethertype and NLPID codings exist then when
transmitting NHRP messages, the Ethertype coding MUST be used (this
is consistent with RFC1483 coding). So, for example, the
following codings exist for IP:
SNAP: ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00
NLPID: ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00
Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00
and thus, since the Ethertype coding exists, it is used in
preference.
ar$hopcnt
The Hop count indicates the maximum number of NHSs that an NHRP
packet is allowed to traverse before being discarded. This field
is used in a similar fashion to the way that a TTL is used in an IP
packet and should be set accordingly. Each NHS decrements the TTL
as the NHRP packet transits the NHS on the way to the next hop
along the routed path to the destination. If an NHS receives an
NHRP packet which it would normally forward to a next hop and that
packet contains an ar$hopcnt set to zero then the NHS sends an
error indication message back to the source protocol address
stating that the hop count has been exceeded (see Section 5.2.7)
and the NHS drops the packet in error; however, an error
indication is never sent as a result of receiving an error
indication. When a responding NHS replies to an NHRP request, that
NHS places a value in ar$hopcnt as if it were sending a request of
its own.
ar$pktsz
The total length of the NHRP packet, in octets (excluding link
layer encapsulation).
ar$chksum
The standard IP checksum over the entire NHRP packet starting at
the fixed header. If the packet is an odd number of bytes in
length then this calculation is performed as if a byte set to 0x00
is appended to the end of the packet.
ar$extoff
This field identifies the existence and location of NHRP
extensions. If this field is 0 then no extensions exist otherwise
this field represents the offset from the beginning of the NHRP
packet (i.e., starting from the ar$afn field) of the first
extension.
ar$op.version
This field indicates what version of generic address mapping and
management protocol is represented by this message.
0 MARS protocol [11].
1 NHRP as defined in this document.
0x02 - 0xEF Reserved for future use by the IETF.
0xF0 - 0xFE Allocated for use by the ATM Forum.
0xFF Experimental/Local use.
ar$op.type
When ar$op.version == 1, this is the NHRP packet type: NHRP
Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration
Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP
Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet
Types in the range 128 to 255 are reserved for research or use in
other protocol development and will be administered by IANA as
described in Section 9.
ar$shtl
Type & length of source NBMA address interpreted in the context of
the "address family number"[6] indicated by ar$afn. See below for
more details.
ar$sstl
Type & length of source NBMA subaddress interpreted in the context
of the "address family number"[6] indicated by ar$afn. When an
NBMA technology has no concept of a subaddress, the subaddress
length is always coded ar$sstl = 0 and no storage is allocated for
the subaddress in the appropriate mandatory part. See below for
more details.
Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
T/L) and subnetwork layer subaddresses type/length fields (e.g.,
ar$sstl, Cli SAddr T/L) are coded as follows:
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
0x length
+-+-+-+-+-+-+-+-+
The most significant bit is reserved and MUST be set to zero. The
second most significant bit (x) is a flag indicating whether the
address being referred to is in:
- NSAP format (x = 0).
- Native E.164 format (x = 1).
For NBMA technologies that use neither NSAP nor E.164 format
addresses, x = 0 SHALL be used to indicate the native form for the
particular NBMA technology.
If the NBMA network is ATM and a subaddress (e.g., Source NBMA
SubAddress, Client NBMA SubAddress) is to be included in any part of
the NHRP packet then ar$afn MUST be set to 0x000F; further, the
subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
T/L) and subnetwork layer subaddress type/length fields (e.g.,
ar$sstl, Cli SAddr T/L) MUST be coded as in [11]. If the NBMA
network is ATM and no subaddress field is to be included in any part
of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008
(E.164) accordingly.
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
flag x is ignored.
5.2.0 Mandatory Part
The Mandatory Part of the NHRP packet contains the operation specific
information (e.g., NHRP Resolution Request/Reply, etc.) and variable
length data which is pertinent to the packet type.
5.2.0.1 Mandatory Part Format
Sections 5.2.1 through 5.2.6 have a very similar mandatory part.
This mandatory part includes a common header and zero or more Client
Information Entries (CIEs). Section 5.2.7 has a different format
which is specified in that section.
The common header looks like the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src Proto Len Dst Proto Len Flags
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source NBMA Address (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source NBMA Subaddress (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Protocol Address (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination Protocol Address (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
And the CIEs have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code Prefix Length unused
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Transmission Unit Holding Time
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cli Addr T/L Cli SAddr T/L Cli Proto Len Preference
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Client NBMA Address (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Client NBMA Subaddress (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Client Protocol Address (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code Prefix Length unused
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Transmission Unit Holding Time
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cli Addr T/L Cli SAddr T/L Cli Proto Len Preference
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Client NBMA Address (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Client NBMA Subaddress (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Client Protocol Address (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meanings of the fields are as follows:
Src Proto Len
This field holds the length in octets of the Source Protocol
Address.
Dst Proto Len
This field holds the length in octets of the Destination Protocol
Address.
Flags
These flags are specific to the given message type and they are
explained in each section.
Request ID
A value which, when coupled with the address of the source,
provides a unique identifier for the information contained in a
"request" packet. This value is copied directly from an "request"
packet into the associated "reply". When a sender of a "request"
receives "reply", it will compare the Request ID and source address
information in the received "reply" against that found in its
outstanding "request" list. When a match is found then the
"request" is considered to be acknowledged.
The value is taken from a 32 bit counter that is incremented each
time a new "request" is transmitted. The same value MUST be used
when resending a "request", i.e., when a "reply" has not been
received for a "request" and a retry is sent after an appropriate
interval.
It is RECOMMENDED that the initial value for this number be 0. A
node MAY reuse a sequence number if and only if the reuse of the
sequence number is not precluded by use of a particular method of
synchronization (e.g., as described in Appendix A).
The NBMA address/subaddress form specified below allows combined
E.164/NSAPA form of NBMA addressing. For NBMA technologies without a
subaddress concept, the subaddress field is always ZERO length and
ar$sstl = 0.
Source NBMA Address
The Source NBMA address field is the address of the source station
which is sending the "request". If the field"s length as specified
in ar$shtl is 0 then no storage is allocated for this address at
all.
Source NBMA SubAddress
The Source NBMA subaddress field is the address of the source
station which is sending the "request". If the field"s length as
specified in ar$sstl is 0 then no storage is allocated for this
address at all.
For those NBMA technologies which have a notion of "Calling Party
Addresses", the Source NBMA Addresses above are the addresses used
when signaling for an SVC.
"Requests" and "indications" follow the routed path from Source
Protocol Address to the Destination Protocol Address. "Replies", on
the other hand, follow the routed path from the Destination Protocol
Address back to the Source Protocol Address with the following
exceptions: in the case of a NHRP Registration Reply and in the case
of an NHC initiated NHRP Purge Request, the packet is always returned
via a direct VC (see Sections 5.2.4 and 5.2.5).
Source Protocol Address
This is the protocol address of the station which is sending the
"request". This is also the protocol address of the station toward
which a "reply" packet is sent.
Destination Protocol Address
This is the protocol address of the station toward which a
"request" packet is sent.
Code
This field is message specific. See the relevant message sections
below. In general, this field is a NAK code; i.e., when the field
is 0 in a reply then the packet is acknowledging a request and if
it contains any other value the packet contains a negative
acknowledgment.
Prefix Length
This field is message specific. See the relevant message sections
below. In general, however, this fields is used to indicate that
the information carried in an NHRP message pertains to an
equivalence class of internetwork layer addresses rather than just
a single internetwork layer address specified. All internetwork
layer addresses that match the first "Prefix Length" bit positions
for the specific internetwork layer address are included in the
equivalence class. If this field is set to 0x00 then this field
MUST be ignored and no equivalence information is assumed (note
that 0x00 is thus equivalent to 0xFF).
Maximum Transmission Unit
This field gives the maximum transmission unit for the relevant
client station. If this value is 0 then either the default MTU is
used or the MTU negotiated via signaling is used if such
negotiation is possible for the given NBMA.
Holding Time
The Holding Time field specifies the number of seconds for which
the Next Hop NBMA information specified in the CIE is considered to
be valid. Cached information SHALL be discarded when the holding
time expires. This field must be set to 0 on a NAK.
Cli Addr T/L
Type & length of next hop NBMA address specified in the CIE. This
field is interpreted in the context of the "address family
number"[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM).
Cli SAddr T/L
Type & length of next hop NBMA subaddress specified in the CIE.
This field is interpreted in the context of the "address family
number"[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes
the address an E.164 and the subaddress an ATM Forum NSAP address).
When an NBMA technology has no concept of a subaddress, the
subaddress is always null with a length of 0. When the address
length is specified as 0 no storage is allocated for the address.
Cli Proto Len
This field holds the length in octets of the Client Protocol
Address specified in the CIE.
Preference
This field specifies the preference for use of the specific CIE
relative to other CIEs. Higher values indicate higher preference.
Action taken when multiple CIEs have equal or highest preference
value is a local matter.
Client NBMA Address
This is the client"s NBMA address.
Client NBMA SubAddress
This is the client"s NBMA subaddress.
Client Protocol Address
This is the client"s internetworking layer address specified.
Note that an NHS may cache source address binding information from an
NHRP Resolution Request if and only if the conditions described in
Section 6.2 are met for the NHS. In all other cases, source address
binding information appearing in an NHRP message MUST NOT be cached.
5.2.1 NHRP Resolution Request
The NHRP Resolution Request packet has a Type code of 1. Its
mandatory part is coded as described in Section 5.2.0.1 and the
message specific meanings of the fields are as follows:
Flags - The flags field is coded as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
QADUS unused
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q
Set if the station sending the NHRP Resolution Request is a
router; clear if the it is a host.
A
This bit is set in a NHRP Resolution Request if only
authoritative next hop information is desired and is clear
otherwise. See the NHRP Resolution Reply section below for
further details on the "A" bit and its usage.
D
Unused (clear on transmit)
U
This is the Uniqueness bit. This bit aids in duplicate address
detection. When this bit is set in an NHRP Resolution Request
and one or more entries exist in the NHS cache which meet the
requirements of the NHRP Resolution Request then only the CIE in
the NHS"s cache with this bit set will be returned. Note that
even if this bit was set at registration time, there may still be
multiple CIEs that might fulfill the NHRP Resolution Request
because an entire subnet can be registered through use of the
Prefix Length in the CIE and the address of interest might be
within such a subnet. If the "uniqueness" bit is set and the
responding NHS has one or more cache entries which match the
request but no such cache entry has the "uniqueness" bit set,
then the NHRP Resolution Reply returns with a NAK code of "13 -
Binding Exists But Is Not Unique" and no CIE is included. If a
client wishes to receive non- unique Next Hop Entries, then
the client must have the "uniqueness" bit set to zero in its NHRP
Resolution Request. Note that when this bit is set in an NHRP
Registration Request, only a single CIE may be specified in the
NHRP Registration Request and that CIE must have the Prefix
Length field set to 0xFF.
S
Set if the binding between the Source Protocol Address and the
Source NBMA information in the NHRP Resolution Request is
guaranteed to be stable and accurate (e.g., these addresses are
those of an ingress router which is connected to an ethernet stub
network or the NHC is an NBMA attached host).
Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP
Resolution Request. If one is specified then that entry carries the
pertinent information for the client sourcing the NHRP Resolution
Request. Usage of the CIE in the NHRP Resolution Request is
described below:
Prefix Length
If a CIE is specified in the NHRP Resolution Request then the
Prefix Length field may be used to qualify the widest acceptable
prefix which may be used to satisfy the NHRP Resolution Request.
In the case of NHRP Resolution Request/Reply, the Prefix Length
specifies the equivalence class of addresses which match the
first "Prefix Length" bit positions of the Destination Protocol
Address. If the "U" bit is set in the common header then this
field MUST be set to 0xFF.
Maximum Transmission Unit
This field gives the maximum transmission unit for the source
station. A possible use of this field in the NHRP Resolution
Request packet is for the NHRP Resolution Requester to ask for a
target MTU.
Holding Time
The Holding Time specified in the one CIE permitted to be
included in an NHRP Resolution Request is the amount of time
which the source address binding information in the NHRP
Resolution Request is permitted to cached by transit and
responding NHSs. Note that this field may only have a non-zero
value if the S bit is set.
All other fields in the CIE MUST be ignored and SHOULD be set to 0.
The Destination Protocol Address in the common header of the
Mandatory Part of this message contains the protocol address of the
station for which resolution is desired. An NHC MUST send the NHRP
Resolution Request directly to one of its serving NHSs (see Section 3
for more information).
5.2.2 NHRP Resolution Reply
The NHRP Resolution Reply packet has a Type code of 2. CIEs
correspond to Next Hop Entries in an NHS"s cache which match the
criteria in the NHRP Resolution Request. Its mandatory part is coded
as described in Section 5.2.0.1. The message specific meanings of
the fields are as follows:
Flags - The flags field is coded as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
QADUS unused
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q
Copied from the NHRP Resolution Request. Set if the NHRP
Resolution Requester is a router; clear if it is a host.
A
Set if the next hop CIE in the NHRP Resolution Reply is
authoritative; clear if the NHRP Resolution Reply is non-
authoritative.
When an NHS receives a NHRP Resolution Request for authoritative
information for which it is the authoritative source, it MUST
respond with a NHRP Resolution Reply containing all and only
those next hop CIEs which are contained in the NHS"s cache which
both match the criteria of the NHRP Resolution Request and are
authoritative cache entries. An NHS is an authoritative source
for a NHRP Resolution Request if the information in the NHS"s
cache matches the NHRP Resolution Request criteria and that
information was obtained through a NHRP Registration Request or
through synchronization with an NHS which obtained this
information through a NHRP Registration Request. An
authoritative cache entry is one which is obtained through a NHRP
Registration Request or through synchronization with an NHS which
obtained this information through a NHRP Registration Request.
An NHS obtains non-authoritative CIEs through promiscuous
listening to NHRP packets other than NHRP Registrations which are
directed at it. A NHRP Resolution Request which indicates a
request for non-authoritative information should cause a NHRP
Resolution Reply which contains all entries in the replying NHS"s
cache (i.e., both authoritative and non-authoritative) which
match the criteria specified in the request.
D
Set if the association between destination and the associate next
hop information included in all CIEs of the NHRP Resolution Reply
is guaranteed to be stable for the lifetime of the information
(the holding time). This is the case if the Next Hop protocol
address in a CIE identifies the destination (though it may be
different in value than the Destination address if the
destination system has multiple addresses) or if the destination
is not connected directly to the NBMA subnetwork but the egress
router to that destination is guaranteed to be stable (such as
when the destination is immediately adjacent to the egress router
through a non-NBMA interface).
U
This is the Uniqueness bit. See the NHRP Resolution Request
section above for details. When this bit is set, only one CIE is
included since only one unique binding should exist in an NHS"s
cache.
S
Copied from NHRP Resolution Request message.
One or more CIEs are specified in the NHRP Resolution Reply. Each CIE
contains NHRP next hop information which the responding NHS has
cached and which matches the parameters specified in the NHRP
Resolution Request. If no match is found by the NHS issuing the NHRP
Resolution Reply then a single CIE is enclosed with the a CIE Code
set appropriately (see below) and all other fields MUST be ignored
and SHOULD be set to 0. In order to facilitate the use of NHRP by
minimal client implementations, the first CIE MUST contain the next
hop with the highest preference value so that such an implementation
need parse only a single CIE.
Code
If this field is set to zero then this packet contains a
positively acknowledged NHRP Resolution Reply. If this field
contains any other value then this message contains an NHRP
Resolution Reply NAK which means that an appropriate
internetworking layer to NBMA address binding was not available
in the responding NHS"s cache. If NHRP Resolution Reply contains
a Client Information Entry with a NAK Code other than 0 then it
MUST NOT contain any other CIE. Currently defined NAK Codes are
as follows:
4 - Administratively Prohibited
An NHS may refuse an NHRP Resolution Request attempt for
administrative reasons (due to policy constraints or routing
state). If so, the NHS MUST send an NHRP Resolution Reply
which contains a NAK code of 4.
5 - Insufficient Resources
If an NHS cannot serve a station due to a lack of resources
(e.g., can"t store sufficient information to send a purge if
routing changes), the NHS MUST reply with a NAKed NHRP
Resolution Reply which contains a NAK code of 5.
12 - No Internetworking Layer Address to NBMA Address Binding
Exists
This code states that there were absolutely no internetworking
layer address to NBMA address bindings found in the responding
NHS"s cache.
13 - Binding Exists But Is Not Unique
This code states that there were one or more internetworking
layer address to NBMA address bindings found in the responding
NHS"s cache, however none of them had the uniqueness bit set.
Prefix Length
In the case of NHRP Resolution Reply, the Prefix Length specifies
the equivalence class of addresses which match the first "Prefix
Length" bit positions of the Destination Protocol Address.
Holding Time
The Holding Time specified in a CIE of an NHRP Resolution Reply
is the amount of time remaining before the expiration of the
client information which is cached at the replying NHS. It is
not the value which was registered by the client.
The remainder of the fields for the CIE for each next hop are
filled out as they were defined when the next hop was registered
with the responding NHS (or one of the responding NHS"s
synchronized servers) via the NHRP Registration Request.
Load-splitting may be performed when more than one Client Information
Entry is returned to a requester when equal preference values are
specified. Also, the alternative addresses may be used in case of
connectivity failure in the NBMA subnetwork (such as a failed call
attempt in connection-oriented NBMA subnetworks).
Any extensions present in the NHRP Resolution Request packet MUST be
present in the NHRP Resolution Reply even if the extension is non-
Compulsory.
If an unsolicited NHRP Resolution Reply packet is received, an Error
Indication of type Invalid NHRP Resolution Reply Received SHOULD be
sent in response.
When an NHS that serves a given NHC receives an NHRP Resolution Reply
destined for that NHC then the NHS must MUST send the NHRP Resolution
Reply directly to the NHC (see Section 3).
5.2.3 NHRP Registration Request
The NHRP Registration Request is sent from a station to an NHS to
notify the NHS of the station"s NBMA information. It has a Type code
of 3. Each CIE corresponds to Next Hop information which is to be
cached at an NHS. The mandatory part of an NHRP Registration Request
is coded as described in Section 5.2.0.1. The message specific
meanings of the fields are as follows:
Flags - The flags field is coded as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U unused
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U
This is the Uniqueness bit. When set in an NHRP Registration
Request, this bit indicates that the registration of the protocol
address is unique within the confines of the set of synchronized
NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC
cache. Any attempt to register a binding between the protocol
address and an NBMA address when this bit is set MUST be rejected
with a Code of "14 - Unique Internetworking Layer Address Already
Registered" if the replying NHS already has a cache entry for the
protocol address and the cache entry has the "uniqueness" bit
set. A registration of a CIE"s information is rejected when the
CIE is returned with the Code field set to anything other than
0x00. See the description of the uniqueness bit in NHRP
Resolution Request section above for further details. When this
bit is set only, only one CIE MAY be included in the NHRP
Registration Request.
Request ID
The request ID has the same meaning as described in Section
5.2.0.1. However, the request ID for NHRP Registrations which is
maintained at each client MUST be kept in non-volatile memory so
that when a client crashes and reregisters there will be no
inconsistency in the NHS"s database. In order to reduce the
overhead associated with updating non-volatile memory, the actual
updating need not be done with every increment of the Request ID
but could be done, for example, every 50 or 100 increments. In
this scenario, when a client crashes and reregisters it knows to
add 100 to the value of the Request ID in the non-volatile memory
before using the Request ID for subsequent registrations.
One or more CIEs are specified in the NHRP Registration Request.
Each CIE contains next hop information which a client is attempting
to register with its servers. Generally, all fields in CIEs enclosed
in NHRP Registration Requests are coded as described in Section
5.2.0.1. However, if a station is only registering itself with the
NHRP Registration Request then it MAY code the Cli Addr T/L, Cli
SAddr T/L, and Cli Proto Len as zero which signifies that the client
address information is to be taken from the source information in the
common header (see Section 5.2.0.1). Below, further clarification is
given for some fields in a CIE in the context of a NHRP Registration
Request.
Code
This field is set to 0x00 in NHRP Registration Requests.
Prefix Length
This field may be used in a NHRP Registration Request to register
equivalence information for the Client Protocol Address specified
in the CIE of an NHRP Registration Request In the case of NHRP
Registration Request, the Prefix Length specifies the equivalence
class of addresses which match the first "Prefix Length" bit
positions of the Client Protocol Address. If the "U" bit is set
in the common header then this field MUST be set to 0xFF.
The NHRP Registration Request is used to register an NHC"s NHRP
information with its NHSs. If an NHC is configured with the protocol
address of a serving NHS then the NHC may place the NHS"s protocol
address in the Destination Protocol Address field of the NHRP
Registration Request common header otherwise the NHC must place its
own protocol address in the Destination Protocol Address field.
When an NHS receives an NHRP Registration Request which has the
Destination Protocol Address field set to an address which belongs to
a LIS/LAG for which the NHS is serving then if the Destination
Protocol Address field is equal to the Source Protocol Address field
(which would happen if the NHC put its protocol address in the
Destination Protocol Address) or the Destination Protocol Address
field is equal to the protocol address of the NHS then the NHS
processes the NHRP Registration Request after doing appropriate error
checking (including any applicable policy checking).
When an NHS receives an NHRP Registration Request which has the
Destination Protocol Address field set to an address which does not
belong to a LIS/LAG for which the NHS is serving then the NHS
forwards the packet down the routed path toward the appropriate
LIS/LAG.
When an NHS receives an NHRP Registration Request which has the
Destination Protocol Address field set to an address which belongs to
a LIS/LAG for which the NHS is serving then if the Destination
Protocol Address field does not equal the Source Protocol Address
field and the Destination Protocol Address field does not equal the
protocol address of the NHS then the NHS forwards the message to the
appropriate NHS within the LIS/LAG as specified by Destination
Protocol Address field.
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
constraints or routing state). If this i