draft-ietf-rolc-nhrp-09.txt   draft-ietf-rolc-nhrp-10.txt 
Routing over Large Clouds Working Group James V. Luciani Routing over Large Clouds Working Group James V. Luciani
INTERNET-DRAFT (Bay Networks) INTERNET-DRAFT (Bay Networks)
<draft-ietf-rolc-nhrp-09.txt> Dave Katz <draft-ietf-rolc-nhrp-10.txt> Dave Katz
(cisco Systems) (cisco Systems)
David Piscitello David Piscitello
(Core Competence, Inc.) (Core Competence, Inc.)
Bruce Cole Bruce Cole
(cisco Systems) (cisco Systems)
Expires January 1997
NBMA Next Hop Resolution Protocol (NHRP) NBMA Next Hop Resolution Protocol (NHRP)
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 46 skipping to change at page 1, line 44
NHRP can be used by a source station (host or router) connected to a NHRP can be used by a source station (host or router) connected to a
Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
internetworking layer address and NBMA subnetwork addresses of the internetworking layer address and NBMA subnetwork addresses of the
"NBMA next hop" towards a destination station. If the destination is "NBMA next hop" towards a destination station. If the destination is
connected to the NBMA subnetwork, then the NBMA next hop is the connected to the NBMA subnetwork, then the NBMA next hop is the
destination station itself. Otherwise, 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 egress router from the NBMA subnetwork that is "nearest" to the
destination station. NHRP is intended for use in a multiprotocol destination station. NHRP is intended for use in a multiprotocol
internetworking layer environment over NBMA subnetworks. 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 This document is intended to be a functional superset of the NBMA
Address Resolution Protocol (NARP) documented in [1]. Address Resolution Protocol (NARP) documented in [1].
Operation of NHRP as a means of establishing a transit path across an Operation of NHRP as a means of establishing a transit path across an
NBMA subnetwork between two routers will be addressed in a separate NBMA subnetwork between two routers will be addressed in a separate
document. document (see [13]).
1. Introduction 1. Introduction
The NBMA Next Hop Resolution Protocol (NHRP) allows a source station The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
(a host or router), wishing to communicate over a Non-Broadcast, (a host or router), wishing to communicate over a Non-Broadcast,
Multi-Access (NBMA) subnetwork, to determine the internetworking Multi-Access (NBMA) subnetwork, to determine the internetworking
layer addresses and NBMA addresses of suitable "NBMA next hops" layer addresses and NBMA addresses of suitable "NBMA next hops"
toward a destination station. A subnetwork can be non-broadcast toward a destination station. A subnetwork can be non-broadcast
either because it technically doesn't support broadcasting (e.g., an either because it technically doesn't support broadcasting (e.g., an
X.25 subnetwork) or because broadcasting is not feasible for one X.25 subnetwork) or because broadcasting is not feasible for one
skipping to change at page 3, line 14 skipping to change at page 3, line 19
Quality of Service and/or traffic characteristics. With the LAG Quality of Service and/or traffic characteristics. With the LAG
model any two entities on a common NBMA network could establish a model any two entities on a common NBMA network could establish a
direct communication with each other, irrespective of the entities' direct communication with each other, irrespective of the entities'
addresses. addresses.
Support for the LAG model assumes the existence of a mechanism that 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 allows any entity (i.e., host or router) connected to an NBMA network
to resolve an internetworking layer address to an NBMA address for to resolve an internetworking layer address to an NBMA address for
any other entity connected to the same NBMA network. This resolution any other entity connected to the same NBMA network. This resolution
would take place regardless of the address assignments to these would take place regardless of the address assignments to these
entities. NHRP describes such a mechanism. For example, when the entities. Within the parameters described in this document, NHRP
internetworking layer address is of type IP, once the NBMA next hop describes such a mechanism. For example, when the internetworking
has been resolved, the source may either start sending IP packets to layer address is of type IP, once the NBMA next hop has been
the destination (in a connectionless NBMA subnetwork such as SMDS) or resolved, the source may either start sending IP packets to the
may first establish a connection to the destination with the desired 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). bandwidth (in a connection-oriented NBMA subnetwork such as ATM).
Use of NHRP may be sufficient for hosts doing address resolution when Use of NHRP may be sufficient for hosts doing address resolution when
those hosts are directly connected to an NBMA subnetwork, allowing those hosts are directly connected to an NBMA subnetwork, allowing
for straightforward implementations in NBMA stations. NHRP also has for straightforward implementations in NBMA stations. NHRP also has
the capability of determining the egress point from an NBMA the capability of determining the egress point from an NBMA
subnetwork when the destination is not directly connected to the NBMA subnetwork when the destination is not directly connected to the NBMA
subnetwork and the identity of the egress router is not learned by subnetwork and the identity of the egress router is not learned by
other methods (such as routing protocols). Optional extensions to other methods (such as routing protocols). Optional extensions to
NHRP provide additional robustness and diagnosability. NHRP provide additional robustness and diagnosability.
Address resolution techniques such as those described in [3] and [4] Address resolution techniques such as those described in [3] and [4]
may be in use when NHRP is deployed. ARP servers and services over may be in use when NHRP is deployed. ARP servers and services over
NBMA subnetworks may be required to support hosts that are not NBMA subnetworks may be required to support hosts that are not
capable of dealing with any model for communication other than the capable of dealing with any model for communication other than the
LIS model, and deployed hosts may not implement NHRP but may continue LIS model, and deployed hosts may not implement NHRP but may continue
to support ARP variants such as those described in [3] and [4]. NHRP to support ARP variants such as those described in [3] and [4]. NHRP
is intended to reduce or eliminate the extra router hops required by is intended to reduce or eliminate the extra router hops required by
the LIS model, and can be deployed in a non-interfering manner the LIS model, and can be deployed in a non-interfering manner with
alongside existing ARP services. existing ARP services [14].
The operation of NHRP to establish transit paths across NBMA The operation of NHRP to establish transit paths across NBMA
subnetworks between two routers requires additional mechanisms to subnetworks between two routers requires additional mechanisms to
avoid stable routing loops, and will be described in a separate avoid stable routing loops, and will be described in a separate
document. document (see [13]).
2. Overview 2. Overview
2.1 Terminology 2.1 Terminology
The term "network" is highly overloaded, and is especially confusing The term "network" is highly overloaded, and is especially confusing
in the context of NHRP. We use the following terms: in the context of NHRP. We use the following terms:
Internetwork layer--the media-independent layer (IP in the case of Internetwork layer--the media-independent layer (IP in the case of
TCP/IP networks). TCP/IP networks).
Subnetwork layer--the media-dependent layer underlying the Subnetwork layer--the media-dependent layer underlying the
internetwork layer, including the NBMA technology (ATM, X.25, SMDS, internetwork layer, including the NBMA technology (ATM, X.25, SMDS,
etc.) etc.)
The term "server", unless explicitly stated to the contrary, refers The term "server", unless explicitly stated to the contrary, refers
to an Next Hop Server (NHS). An NHS is an entity performing the to an Next Hop Server (NHS). An NHS is an entity performing the
Next Hop Resolution Protocol service within the NBMA cloud. An NHS Next Hop Resolution Protocol service within the NBMA cloud. An NHS
is always tightly coupled with a routing entity (router, route is always tightly coupled with a routing entity (router, route
server or edge device) although the converse is not yet guaranteed server or edge device) although the converse is not yet guaranteed
until ubiquitous deployment of this functionality occurs. 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 The term "client", unless explicitly stated to the contrary, refers
to an Next Hop Resolution Protocol client (NHC). An NHC is an to an Next Hop Resolution Protocol client (NHC). An NHC is an
entity which initiates NHRP requests of various types in order to entity which initiates NHRP requests of various types in order to
obtain access to the NHRP service. obtain access to the NHRP service.
The term "station" generally refers to a host or router which The term "station" generally refers to a host or router which
contains an NHRP entity. Occasionally, the term station will contains an NHRP entity. Occasionally, the term station will
describe a "user" of the NHRP client or service functionality; the describe a "user" of the NHRP client or service functionality; the
difference in usage is largely semantic. difference in usage is largely semantic.
skipping to change at page 5, line 4 skipping to change at page 5, line 16
specified, we use the term "NBMA subnetwork" to mean *logical* NBMA specified, we use the term "NBMA subnetwork" to mean *logical* NBMA
subnetwork.) subnetwork.)
Placed within the NBMA subnetwork are one or more entities that Placed within the NBMA subnetwork are one or more entities that
implement the NHRP protocol. Such stations which are capable of implement the NHRP protocol. Such stations which are capable of
answering NHRP Resolution Requests are known as "Next Hop Servers" answering NHRP Resolution Requests are known as "Next Hop Servers"
(NHSs). Each NHS serves a set of destination hosts, which may or may (NHSs). Each NHS serves a set of destination hosts, which may or may
not be directly connected to the NBMA subnetwork. NHSs cooperatively not be directly connected to the NBMA subnetwork. NHSs cooperatively
resolve the NBMA next hop within their logical NBMA subnetwork. In resolve the NBMA next hop within their logical NBMA subnetwork. In
addition to NHRP, NHSs may support "classical" ARP service; however, addition to NHRP, NHSs may support "classical" ARP service; however,
this will be the subject of a separate document. this will be the subject of a separate document [14].
An NHS maintains a cache which contains protocol layer address to An NHS maintains a cache which contains protocol layer address to
NBMA subnetwork layer address resolution information. This cache can NBMA subnetwork layer address resolution information. This cache can
be constructed from information obtained from NHRP Register packets be constructed from information obtained from NHRP Register packets
(see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply
packets, or through mechanisms outside the scope of this document packets, or through mechanisms outside the scope of this document
(examples of such mechanisms might include ARP[3] and pre-configured (examples of such mechanisms might include ARP[3] and pre-configured
tables). Section 6.2 further describes cache management issues. tables). Section 6.2 further describes cache management issues.
For a station within a given LIS to avoid providing NHS For a station within a given LIS to avoid providing NHS
skipping to change at page 7, line 37 skipping to change at page 7, line 48
functionality is coresident with the NHS). functionality is coresident with the NHS).
If the determination is made that no NHS in the NBMA subnetwork can 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 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 Reply (NAK) is returned. This occurs when (a) no next-hop
resolution information is available for station D from any NHS, or resolution information is available for station D from any NHS, or
(b) an NHS is unable to forward the NHRP Resolution Request (e.g., (b) an NHS is unable to forward the NHRP Resolution Request (e.g.,
connectivity is lost). connectivity is lost).
NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies,
and NHRP Error Indications follow the routed path from sender to and NHRP Error Indications follow a routed path in the same fashion
receiver in the same fashion that NHRP Resolution Requests and NHRP that NHRP Resolution Requests and NHRP Resolution Replies do.
Resolution Replies do. That is, "requests" and "indications" follow Specifically, "requests" and "indications" follow the routed path
the routed path from Source Protocol Address (which is the address of from Source Protocol Address (which is the address of the station
the station initiating the communication) to the Destination Protocol initiating the communication) to the Destination Protocol Address.
Address. "Replies", on the other hand, follow the routed path from "Replies", on the other hand, follow the routed path from the
the Destination Protocol Address back to the Source Protocol Address Destination Protocol Address back to the Source Protocol Address with
with the exceptions mentioned above where a direct VC may be created. the following exceptions: in the case of a NHRP Registration Reply
In the case of a NHRP Registration Reply and in the case of an NHC and in the case of an NHC initiated NHRP Purge Request, the packet is
initiated NHRP Purge Request, the packet is always returned via a always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if
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 NBMA NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA
subnetwork however further study is being done in this area (see subnetwork however further study is being done in this area (see
Section 7). Thus, the internetwork layer traffic out of and into an Section 7). Thus, the internetwork layer traffic out of and into an
NBMA subnetwork always traverses an internetwork layer router at its NBMA subnetwork always traverses an internetwork layer router at its
border. Internetwork layer filtering can then be implemented at border. Internetwork layer filtering can then be implemented at
these border routers. these border routers.
NHRP optionally provides a mechanism to send a NHRP Resolution Reply NHRP optionally provides a mechanism to send a NHRP Resolution Reply
which contains aggregated address resolution information. For which contains aggregated address resolution information. For
skipping to change at page 8, line 32 skipping to change at page 8, line 44
trace the routed path that an NHRP packet takes, or to provide loop trace the routed path that an NHRP packet takes, or to provide loop
detection and diagnostic capabilities, a "Route Record" may be detection and diagnostic capabilities, a "Route Record" may be
included in NHRP packets (see Sections 5.3.2 and 5.3.3). The Route 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 Record extensions are the NHRP Forward Transit NHS Record Extension
and the NHRP Reverse Transit NHS Record Extension. They contain the and the NHRP Reverse Transit NHS Record Extension. They contain the
internetwork (and subnetwork layer) addresses of all intermediate internetwork (and subnetwork layer) addresses of all intermediate
NHSs between source and destination and between destination and NHSs between source and destination and between destination and
source respectively. When a source station is unable to communicate source respectively. When a source station is unable to communicate
with the responder (e.g., an attempt to open an SVC fails), it may with the responder (e.g., an attempt to open an SVC fails), it may
attempt to do so successively with other subnetwork layer addresses attempt to do so successively with other subnetwork layer addresses
in these extensions until it succeeds (if authentication policy in the NHRP Forward Transit NHS Record Extension until it succeeds
permits such action). This approach can find a suitable egress point (if authentication policy permits such action). This approach can
in the presence of subnetwork-layer filtering (which may be find a suitable egress point in the presence of subnetwork-layer
source/destination sensitive, for instance, without necessarily filtering (which may be source/destination sensitive, for instance,
creating separate logical NBMA subnetworks) or subnetwork-layer without necessarily creating separate logical NBMA subnetworks) or
congestion (especially in connection-oriented media). subnetwork-layer congestion (especially in connection-oriented
media).
3. Deployment 3. Deployment
NHRP Resolution Requests traverse one or more hops within an NBMA NHRP Resolution Requests traverse one or more hops within an NBMA
subnetwork before reaching the station that is expected to generate a subnetwork before reaching the station that is expected to generate a
response. Each station, including the source station, chooses a response. Each station, including the source station, chooses a
neighboring NHS to which it will forward the NHRP Resolution Request. neighboring NHS to which it will forward the NHRP Resolution Request.
The NHS selection procedure typically involves applying a destination The NHS selection procedure typically involves applying a destination
protocol layer address to the protocol layer routing table which protocol layer address to the protocol layer routing table which
causes a routing decision to be returned. This routing decision is causes a routing decision to be returned. This routing decision is
skipping to change at page 9, line 21 skipping to change at page 9, line 34
on the way to the packet's destination might modify the packet (e.g., on the way to the packet's destination might modify the packet (e.g.,
updating the Forward Record extension). Ignoring error situations, updating the Forward Record extension). Ignoring error situations,
the NHRP Resolution Request eventually arrives at a station that is the NHRP Resolution Request eventually arrives at a station that is
to generate an NHRP Resolution Reply. This responding station to generate an NHRP Resolution Reply. This responding station
"serves" the destination. The responding station generates a NHRP "serves" the destination. The responding station generates a NHRP
Resolution Reply using the source protocol address from within the Resolution Reply using the source protocol address from within the
NHRP packet to determine where the NHRP Resolution Reply should be NHRP packet to determine where the NHRP Resolution Reply should be
sent. sent.
Rather than use routing to determine the next hop for an NHRP packet, Rather than use routing to determine the next hop for an NHRP packet,
an NHS may use static configuration information (or other applicable an NHS may use other applicable means (such as static configuration
means) in order to determine to which neighboring NHSs to forward the information ) in order to determine to which neighboring NHSs to
NHRP Resolution Request packet. The use of static configuration 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. information for this purpose is beyond the scope of this document.
The NHS serving a particular destination must lie along the routed The NHS serving a particular destination must lie along the routed
path to that destination. In practice, this means that all egress path to that destination. In practice, this means that all egress
routers must double as NHSs serving the destinations beyond them, and routers must double as NHSs serving the destinations beyond them, and
that hosts on the NBMA subnetwork are served by routers that double that hosts on the NBMA subnetwork are served by routers that double
as NHSs. Also, this implies that forwarding of NHRP packets within as NHSs. Also, this implies that forwarding of NHRP packets within
an NBMA subnetwork requires a contiguous deployment of NHRP capable an NBMA subnetwork requires a contiguous deployment of NHRP capable
routers. During migration to NHRP, it cannot be expected that all routers. It is important that, in a given LIS/LAG which is using
routers within the NBMA subnetwork are NHRP capable. Thus, NHRP NHRP, all NHSs within the LIS/LAG have at least some portion of their
traffic which would otherwise need to be forwarded through such resolution databases synchronized so that a packet arriving at one
routers can be expected to be dropped due to the NHRP packet not router/NHS in a given LIS/LAG will be forwarded in the same fashion
being recognized. In this case, NHRP will be unable to establish any as 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 transit paths whose discovery requires the traversal of the non-NHRP
speaking routers. If the client has tried and failed to acquire a speaking routers. If the client has tried and failed to acquire a
cut through path then the client should use the network layer routed cut through path then the client should use the network layer routed
path as a default. path as a default.
If an NBMA technology offers a group, an anycast, or a multicast If an NBMA technology offers a group, an anycast, or a multicast
addressing feature then the NHC may be configured with such an addressing feature then the NHC may be configured with such an
address which would be assigned to the appropriate NHSs. The NHC address which would be assigned to the appropriate NHSs. The NHC
might then submit NHRP Resolution Requests to such an address, might then submit NHRP Resolution Requests to such an address,
eliciting a response from one or more NHSs, depending on the response eliciting a response from one or more NHSs, depending on the response
skipping to change at page 11, line 45 skipping to change at page 12, line 23
The length of the Fixed Part is fixed at 20 octets. The length of The length of the Fixed Part is fixed at 20 octets. The length of
the Mandatory Part is determined by the contents of the extensions the Mandatory Part is determined by the contents of the extensions
offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part
length is equal to total packet length (ar$pktsz) minus 20 otherwise length is equal to total packet length (ar$pktsz) minus 20 otherwise
the mandatory part length is equal to ar$extoff minus 20. The length the mandatory part length is equal to ar$extoff minus 20. The length
of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs 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 may increase the size of an NHRP packet as a result of extension
processing, but not beyond the offered maximum SDU size of the NBMA processing, but not beyond the offered maximum SDU size of the NBMA
network. network.
NHRP packets are encapsulated using the native formats used on the NHRP packets are actually members of a wider class of address mapping
particular NBMA network over which NHRP is carried. For example, and management protocols being developed by the IETF. A specific
SMDS networks always use LLC/SNAP encapsulation at the NBMA layer, encapsulation, based on the native formats used on the particular
and an NHRP packet is preceded by the following LLC/SNAP NBMA network over which NHRP is carried, indicates the generic IETF
encapsulation: 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] [0xAA-AA-03] [0x00-00-5E] [0x00-03]
The first three octets are LLC, indicating that SNAP follows. The The first three octets are LLC, indicating that SNAP follows. The
SNAP OUI portion is the IANA's OUI, and the SNAP PID portion SNAP OUI portion is the IANA's OUI, and the SNAP PID portion
identifies NHRP (see [4]). 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 ATM uses either LLC/SNAP encapsulation of each packet (including
NHRP), or uses no encapsulation on VCs dedicated to a single protocol NHRP), or uses no encapsulation on VCs dedicated to a single protocol
(see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or
identification of NHRP, using a NLPID of 0x0080 and the same SNAP identification of NHRP, using a NLPID of 0x0080 and the same SNAP
contents as above (see [8], [9]). contents as above (see [8], [9]).
Fields marked "unused" MUST be set to zero on transmission, and Fields marked "unused" MUST be set to zero on transmission, and
ignored on receipt. ignored on receipt.
skipping to change at page 13, line 29 skipping to change at page 14, line 8
When ar$pro.type has a value of 0x0080, a SNAP encoded extension is When ar$pro.type has a value of 0x0080, a SNAP encoded extension is
being used to encode the protocol type. This snap extension is being used to encode the protocol type. This snap extension is
placed in the ar$pro.snap field. This is termed the 'long form' placed in the ar$pro.snap field. This is termed the 'long form'
protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be
zero on transmit and ignored on receive. The ar$pro.type field zero on transmit and ignored on receive. The ar$pro.type field
itself identifies the protocol being referred to. This is termed itself identifies the protocol being referred to. This is termed
the 'short form' protocol ID. the 'short form' protocol ID.
In all cases, where a protocol has an assigned number in the In all cases, where a protocol has an assigned number in the
ar$pro.type space (excluding 0x0080) the short form MUST be used ar$pro.type space (excluding 0x0080) the short form MUST be used
when transmitting NHRP messages. Additionally, where a protocol has when transmitting NHRP messages; i.e., if Ethertype or NLPID
valid short and long forms of identification, receivers MAY choose codings exist then they are used on transmit rather than the
to recognize the long form. ethertype. If both Ethertype and NLPID codings exist then when
transmitting NHRP messages, the Ethertype coding MUST be used (this
is consistent with RFC 1483 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 ar$hopcnt
The Hop count indicates the maximum number of NHSs that an NHRP The Hop count indicates the maximum number of NHSs that an NHRP
packet is allowed to traverse before being discarded. packet is allowed to traverse before being discarded.
ar$pktsz ar$pktsz
The total length of the NHRP packet, in octets (excluding link The total length of the NHRP packet, in octets (excluding link
layer encapsulation). layer encapsulation).
ar$chksum ar$chksum
skipping to change at page 14, line 6 skipping to change at page 14, line 44
completely recomputed when other header fields are changed. completely recomputed when other header fields are changed.
ar$extoff ar$extoff
This field identifies the existence and location of NHRP This field identifies the existence and location of NHRP
extensions. If this field is 0 then no extensions exist otherwise extensions. If this field is 0 then no extensions exist otherwise
this field represents the offset from the beginning of the NHRP this field represents the offset from the beginning of the NHRP
packet (i.e., starting from the ar$afn field) of the first packet (i.e., starting from the ar$afn field) of the first
extension. extension.
ar$op.version ar$op.version
This field is set to 0x01 for NHRP version 1. 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 ar$op.type
This is the NHRP packet type: NHRP Resolution Request(1), NHRP When ar$op.version == 1, this is the NHRP packet type: NHRP
Resolution Reply(2), NHRP Registration Request(3), NHRP Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration
Registration Reply(4), NHRP Purge Request(5), NHRP Purge Reply(6), Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP
or NHRP Error Indication(7). Use of NHRP packet Types in the range Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet
128 to 255 are reserved for research or use in other protocol Types in the range 128 to 255 are reserved for research or use in
development and will be administered by IANA. other protocol development and will be administered by IANA.
ar$shtl ar$shtl
Type & length of source NBMA address interpreted in the context of Type & length of source NBMA address interpreted in the context of
the 'address family number'[6] indicated by ar$afn (e.g., the 'address family number'[6] indicated by ar$afn. See below for
ar$afn=0x0003 for NSAP, ar$afn=8 for E.164). When ar$afn=0x000F more details.
(E.164 address plus NSAP subaddress) then both ar$shtl and ar$sstl
must be coded appropriately (see below).
ar$sstl ar$sstl
Type & length of source NBMA subaddress interpreted in the context Type & length of source NBMA subaddress interpreted in the context
of the 'address family number'[6] indicated by ar$afn (e.g., of the 'address family number'[6] indicated by ar$afn. When an
ar$afn=0x000F for NSAP). When an NBMA technology has no concept of NBMA technology has no concept of a subaddress, the subaddress
a subaddress, the subaddress length is always coded ar$sstl = 0 and length is always coded ar$sstl = 0 and no storage is allocated for
no storage is allocated for the subaddress in the appropriate the subaddress in the appropriate mandatory part. See below for
mandatory part. more details.
ar$shtl, ar$sstl, subnetwork layer addresses, and subnetwork layer Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
subaddresses fields are coded as follows: 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 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|x| length | |0|x| length |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The most significant bit is reserved and MUST be set to zero. The The most significant bit is reserved and MUST be set to zero. The
second most significant bit (x) is a flag indicating whether the second most significant bit (x) is a flag indicating whether the
address being referred to is in: address being referred to is in:
- NSAP format (x = 0). - NSAP format (x = 0).
- Native E.164 format (x = 1). - Native E.164 format (x = 1).
For NBMA technologies that use neither NSAP nor E.164 format For NBMA technologies that use neither NSAP nor E.164 format
addresses, x = 0 SHALL be used to indicate the native form for the addresses, x = 0 SHALL be used to indicate the native form for the
particular NBMA technology. particular NBMA technology.
In the case where the NBMA is ATM, if a subaddress is to be included If the NBMA network is ATM and a subaddress (e.g., Source NBMA
then ar$afn MUST be set to 0x000F which means that if a subaddress SubAddress, Client NBMA SubAddress) is to be included in any part of
exists then it is of type NSAP. 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 The bottom 6 bits is an unsigned integer value indicating the length
of the associated NBMA address in octets. If this value is zero the of the associated NBMA address in octets. If this value is zero the
flag x is ignored. flag x is ignored.
5.2.0 Mandatory Part 5.2.0 Mandatory Part
The Mandatory Part of the NHRP packet contains the operation specific The Mandatory Part of the NHRP packet contains the operation specific
information (e.g., NHRP Resolution Request/Reply, etc.) and variable information (e.g., NHRP Resolution Request/Reply, etc.) and variable
length data which is pertinent to the packet type. length data which is pertinent to the packet type.
skipping to change at page 17, line 33 skipping to change at page 18, line 33
which is sending the "request". If the field's length as specified 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 in ar$shtl is 0 then no storage is allocated for this address at
all. all.
Source NBMA SubAddress Source NBMA SubAddress
The Source NBMA subaddress field is the address of the source The Source NBMA subaddress field is the address of the source
station which is sending the "request". If the field's length as 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 specified in ar$sstl is 0 then no storage is allocated for this
address at all. address at all.
"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 Source Protocol Address
This is the protocol address of the station which is sending the This is the protocol address of the station which is sending the
"request". This is also the protocol address of the station toward "request". This is also the protocol address of the station toward
which a "reply" packet is sent. which a "reply" packet is sent.
Destination Protocol Address Destination Protocol Address
This is the protocol address of the station toward which a This is the protocol address of the station toward which a
"request" packet is sent. "request" packet is sent.
Code Code
skipping to change at page 21, line 41 skipping to change at page 22, line 48
authoritative cache entries. An NHS is an authoritative source authoritative cache entries. An NHS is an authoritative source
for a NHRP Resolution Request if the information in the NHS's for a NHRP Resolution Request if the information in the NHS's
cache matches the NHRP Resolution Request criteria and that cache matches the NHRP Resolution Request criteria and that
information was obtained through a NHRP Registration Request or information was obtained through a NHRP Registration Request or
through synchronization with an NHS which obtained this through synchronization with an NHS which obtained this
information through a NHRP Registration Request. An information through a NHRP Registration Request. An
authoritative cache entry is one which is obtained through a NHRP authoritative cache entry is one which is obtained through a NHRP
Registration Request or through synchronization with an NHS which Registration Request or through synchronization with an NHS which
obtained this information through a NHRP Registration Request. obtained this information through a NHRP Registration Request.
An NHS obtains non-authoriative CIEs through promiscuous An NHS obtains non-authoritative CIEs through promiscuous
listening to NHRP packets other than NHRP Registrations which are listening to NHRP packets other than NHRP Registrations which are
directed at it. A NHRP Resolution Request which indicates a directed at it. A NHRP Resolution Request which indicates a
request for non-authoritative information should cause a NHRP request for non-authoritative information should cause a NHRP
Resolution Reply which contains all entries in the replying NHS's Resolution Reply which contains all entries in the replying NHS's
cache (i.e., both authoritative and non-authoritative) which cache (i.e., both authoritative and non-authoritative) which
match the criteria specified in the request. match the criteria specified in the request.
B B
Set if the association between the destination and the next hop Set if the association between the destination and the next hop
information is guaranteed to be stable for the lifetime of the information is guaranteed to be stable for the lifetime of the
skipping to change at page 35, line 8 skipping to change at page 36, line 8
responder; i.e., the entity that generates the appropriate "reply" responder; i.e., the entity that generates the appropriate "reply"
packet for a given "request" packet. In the case of an NHRP packet for a given "request" packet. In the case of an NHRP
Resolution Request, the station responding may be different (in the Resolution Request, the station responding may be different (in the
case of cached replies) than the system identified in the Next Hop case of cached replies) than the system identified in the Next Hop
field of the NHRP Resolution Reply. Further, this extension may aid field of the NHRP Resolution Reply. Further, this extension may aid
in detecting loops in the NHRP forwarding path. in detecting loops in the NHRP forwarding path.
This extension uses a single CIE with the extension specific meanings This extension uses a single CIE with the extension specific meanings
of the fields set as follows: of the fields set as follows:
The Code and Prefix Length fields MUST be set to 0 and ignored. The Prefix Length fields MUST be set to 0 and ignored.
CIE Code
16 - Insufficient Resources Exist To Setup Cut-Through
If the responder to an NHRP Resolution Request is an egress point
for the target of the address resolution request (i.e., it is one
of the stations identified in the list of CIEs in an NHRP
Resolution Reply) and the Responder Address extension is included
in the NHRP Resolution Request and insufficient resources to
setup a cut-through VC exist at the responder then the Code field
of the Responder Address Extension is set to 16 decimal in order
to tell the client that a VC setup attempt would in all
likelihood be rejected; otherwise this field MUST be coded as a
zero. NHCs MAY use this field to influence whether they attempt
to setup a cut-through to the egress router.
Maximum Transmission Unit Maximum Transmission Unit
This field gives the maximum transmission unit preferred by the This field gives the maximum transmission unit preferred by the
responder. If this value is 0 then either the default MTU is used responder. If this value is 0 then either the default MTU is used
or the MTU negotiated via signaling is used if such negotiation is or the MTU negotiated via signaling is used if such negotiation is
possible for the given NBMA. possible for the given NBMA.
Holding Time Holding Time
The Holding Time field specifies the number of seconds for which The Holding Time field specifies the number of seconds for which
the NBMA information of the responser is considered to be valid. the NBMA information of the responser is considered to be valid.
skipping to change at page 36, line 23 skipping to change at page 37, line 37
The responding NHS, as described in Section 5.3.1, SHALL NOT update The responding NHS, as described in Section 5.3.1, SHALL NOT update
this extension. this extension.
In addition, NHSs that are willing to act as egress routers for In addition, NHSs that are willing to act as egress routers for
packets from the source to the destination SHALL include information packets from the source to the destination SHALL include information
about their NBMA Address. about their NBMA Address.
This extension uses a single CIE with the extension specific meanings This extension uses a single CIE with the extension specific meanings
of the fields set as follows: of the fields set as follows:
The Code and Prefix Length fields MUST be set to 0 and ignored. The Prefix Length fields MUST be set to 0 and ignored.
CIE Code
16 - Insufficient Resources Exist To Setup Cut-Through
If an NHRP Resolution Request contains an NHRP Forward Transit
NHS Record Extension and insufficient resources to setup a cut-
through VC exist at the current transit NHS then the CIE Code
field for NHRP Forward Transit NHS Record Extension is set to 16
decimal in order to tell the client that a VC setup attempt would
in all likelihood be rejected; otherwise this field MUST be coded
as a zero. NHCs MAY use this field to influence whether they
attempt to setup a cut-through as described in Section 2.2. Note
that the NHRP Reverse Transit NHS Record Extension MUST always
have this field set to zero.
Maximum Transmission Unit Maximum Transmission Unit
This field gives the maximum transmission unit preferred by the This field gives the maximum transmission unit preferred by the
transit NHS. If this value is 0 then either the default MTU is transit NHS. If this value is 0 then either the default MTU is
used or the MTU negotiated via signaling is used if such used or the MTU negotiated via signaling is used if such
negotiation is possible for the given NBMA. negotiation is possible for the given NBMA.
Holding Time Holding Time
The Holding Time field specifies the number of seconds for which The Holding Time field specifies the number of seconds for which
the NBMA information of the transit NHS is considered to be valid. the NBMA information of the transit NHS is considered to be valid.
skipping to change at page 37, line 32 skipping to change at page 39, line 9
The responding NHS, as described in Section 5.3.1, SHALL NOT update The responding NHS, as described in Section 5.3.1, SHALL NOT update
this extension. this extension.
In addition, NHSs that are willing to act as egress routers for In addition, NHSs that are willing to act as egress routers for
packets from the source to the destination SHALL include information packets from the source to the destination SHALL include information
about their NBMA Address. about their NBMA Address.
This extension uses a single CIE with the extension specific meanings This extension uses a single CIE with the extension specific meanings
of the fields set as follows: of the fields set as follows:
The Code and Prefix Length fields MUST be set to 0 and ignored. The CIE Code and Prefix Length fields MUST be set to 0 and ignored.
Maximum Transmission Unit Maximum Transmission Unit
This field gives the maximum transmission unit preferred by the This field gives the maximum transmission unit preferred by the
transit NHS. If this value is 0 then either the default MTU is transit NHS. If this value is 0 then either the default MTU is
used or the MTU negotiated via signaling is used if such used or the MTU negotiated via signaling is used if such
negotiation is possible for the given NBMA. negotiation is possible for the given NBMA.
Holding Time Holding Time
The Holding Time field specifies the number of seconds for which The Holding Time field specifies the number of seconds for which
the NBMA information of the transit NHS is considered to be valid. the NBMA information of the transit NHS is considered to be valid.
skipping to change at page 41, line 34 skipping to change at page 43, line 12
Requests and receiving its own NHRP Resolution Replies as long as the Requests and receiving its own NHRP Resolution Replies as long as the
station follows the rules for Transit NHSs as seen below. station follows the rules for Transit NHSs as seen below.
Serving NHSs Serving NHSs
The NHS serving the destination (the one which responds The NHS serving the destination (the one which responds
authoritatively to NHRP Resolution Requests) SHOULD cache information authoritatively to NHRP Resolution Requests) SHOULD cache information
about all NHRP Resolution Requests to which it has responded if the about all NHRP Resolution Requests to which it has responded if the
information in the NHRP Resolution Reply has the possibility of information in the NHRP Resolution Reply has the possibility of
changing during its lifetime (so that an NHRP Purge Request packet changing during its lifetime (so that an NHRP Purge Request packet
can be sent). The NBMA information provided by the source station in can be issued). The NBMA information provided by the source station
the NHRP Resolution Request may be cached for the duration of its in the NHRP Resolution Request may be cached for the duration of its
holding time. This information is considered to be stable, since it holding time. This information is considered to be stable, since it
identifies a station directly attached to the NBMA subnetwork. An identifies a station directly attached to the NBMA subnetwork. An
example of unstable information is NBMA information derived from a example of unstable information is NBMA information derived from a
routing table, where that routing table information has not been routing table, where that routing table information has not been
guaranteed to be stable through administrative means. guaranteed to be stable through administrative means.
Transit NHSs Transit NHSs
A Transit NHS (lying along the NHRP path between the source station A Transit NHS (lying along the NHRP path between the source station
and the responding NHS) may cache information contained in NHRP and the responding NHS) may cache information contained in NHRP
skipping to change at page 44, line 4 skipping to change at page 45, line 30
in excessive NHRP traffic. At worst it may result in an excessive in excessive NHRP traffic. At worst it may result in an excessive
number of virtual circuits being established unnecessarily. number of virtual circuits being established unnecessarily.
Therefore, it is important to take certain measures to avoid or Therefore, it is important to take certain measures to avoid or
suppress this behavior. NHRP implementations for NHSs MUST provide a suppress this behavior. NHRP implementations for NHSs MUST provide a
mechanism to address this problem. One possible strategy to address mechanism to address this problem. One possible strategy to address
this problem would be to configure a router in such a way that NHRP this problem would be to configure a router in such a way that NHRP
Resolution Request generation by the router would be driven only by Resolution Request generation by the router would be driven only by
the traffic the router receives over its non-NBMA interfaces the traffic the router receives over its non-NBMA interfaces
(interfaces that are not attached to an NBMA subnetwork). Traffic (interfaces that are not attached to an NBMA subnetwork). Traffic
received by the router over its NBMA-attached interfaces would not received by the router over its NBMA-attached interfaces would not
trigger NHRP NHRP Resolution Requests. Such a router avoids the NHRP trigger NHRP Resolution Requests. Such a router avoids the NHRP
domino effect through administrative means. domino effect through administrative means.
7. NHRP over Legacy BMA Networks 7. NHRP over Legacy BMA Networks
There would appear to be no significant impediment to running NHRP There would appear to be no significant impediment to running NHRP
over legacy broadcast subnetworks. There may be issues around over legacy broadcast subnetworks. There may be issues around
running NHRP across multiple subnetworks. Running NHRP on broadcast running NHRP across multiple subnetworks. Running NHRP on broadcast
media has some interesting possibilities; especially when setting up media has some interesting possibilities; especially when setting up
a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both
end stations are legacy attached. This use for NHRP requires further end stations are legacy attached. This use for NHRP requires further
skipping to change at page 45, line 41 skipping to change at page 47, line 19
[8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode,
A. Malis, D. Robinson, and R. Ullmann, RFC1356. A. Malis, D. Robinson, and R. Ullmann, RFC1356.
[9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and
A. Malis, RFC1490. A. Malis, RFC1490.
[10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks, [10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks,
Yakov Rekhter, Dilip Kandlur, RFC1937. Yakov Rekhter, Dilip Kandlur, RFC1937.
[11] Support for Multicast over UNI 3.0/3.1 based ATM Networks,
G. Armitage, Work In Progress.
[12] Server Cache Synchronization Protocol (SCSP) - NBMA,
J. Luciani, G. Armitage, J. Halpern, Work In Progress.
[13] NHRP for Destinations off the NBMA Subnetwork,
Y. Rekhter, Work In Progress.
[14] Classical IP to NHRP Transition, J. Luciani, et al., Work In Progress.
Acknowledgments Acknowledgments
We would like to thank Juha Heinenan of Telecom Finland and Ramesh We would like to thank Juha Heinenan of Telecom Finland and Ramesh
Govidan of ISI for their work on NBMA ARP and the original NHRP Govidan of ISI for their work on NBMA ARP and the original NHRP
draft, which served as the basis for this work. Russell Gardo of draft, which served as the basis for this work. Russell Gardo of
IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Joel Halpern IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Joel Halpern
of Newbridge, Paul Francis of NTT, Tony Li and Yakov Rekhter of of Newbridge, Paul Francis of NTT, Tony Li and Yakov Rekhter of
cisco, and Grenville Armitage of Bellcore should also be acknowledged cisco, and Grenville Armitage of Bellcore should also be acknowledged
for comments and suggestions that improved this work substantially. for comments and suggestions that improved this work substantially.
We would also like to thank the members of the ION working group of We would also like to thank the members of the ION working group of
 End of changes. 30 change blocks. 
76 lines changed or deleted 168 lines changed or added

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