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