received. This is necessary in order to preserve the Request ID
for retries, and provides the state necessary to avoid triggering
NHRP Resolution Requests for every data packet sent to the
destination.
Source stations MUST purge expired information from their caches.
Source stations MUST purge the appropriate cached information upon
receipt of an NHRP Purge Request packet.
When a station has a co-resident NHC and NHS, the co-resident NHS
may reply to NHRP Resolution Requests from the co-resident NHC with
information which the station cached as a result of the co-resident
NHC making its own NHRP Resolution Requests as long as the co-
resident NHS follows the rules for Transit NHSs as seen below.
Serving NHSs
The NHS serving the destination (the one which responds
authoritatively to NHRP Resolution Requests) SHOULD cache protocol
address information from all NHRP Resolution Requests to which it
has responded if the information in the NHRP Resolution Reply has
the possibility of changing during its lifetime (so that an NHRP
Purge Request packet can be issued). The internetworking to NBMA
binding information provided by the source station in the NHRP
Resolution Request may also be cached if and only if the "S" bit is
set, the NHRP Resolution Request has included a CIE with the
Holding Time field set greater than zero (this is the valid Holding
Time for the source binding), and only for non-authoritative use
for a period not to exceed the Holding Time.
Transit NHSs
A Transit NHS (lying along the NHRP path between the source station
and the responding NHS) may cache source binding information
contained in NHRP Resolution Request packets that it forwards if
and only if the "S" bit is set, the NHRP Resolution Request has
included a CIE with the Holding Time field set greater than zero
(this is the valid Holding Time for the source binding), and only
for non-authoritative use for a period not to exceed the Holding
Time.
A Transit NHS may cache destination information contained in NHRP
Resolution Reply CIE if only if the D bit is set and then only for
non-authoritative use for a period not to exceed the Holding Time
value contained in the CIE. A Transit NHS MUST NOT cache source
binding information contained in an NHRP Resolution Reply.
Further, a transit NHS MUST discard any cached information when the
prescribed time has expired. It may return cached information in
response to non-authoritative NHRP Resolution Requests only.
6.2.2 Dynamics of Cached Information
NBMA-Connected Destinations
NHRP's most basic function is that of simple NBMA address
resolution of stations directly attached to the NBMA subnetwork.
These mappings are typically very static, and appropriately chosen
holding times will minimize problems in the event that the NBMA
address of a station must be changed. Stale information will cause
a loss of connectivity, which may be used to trigger an
authoritative NHRP Resolution Request and bypass the old data. In
the worst case, connectivity will fail until the cache entry times
out.
This applies equally to information marked in NHRP Resolution
Replies as being "stable" (via the "D" bit).
Destinations Off of the NBMA Subnetwork
If the source of an NHRP Resolution Request is a host and the
destination is not directly attached to the NBMA subnetwork, and
the route to that destination is not considered to be "stable," the
destination mapping may be very dynamic (except in the case of a
subnetwork where each destination is only singly homed to the NBMA
subnetwork). As such the cached information may very likely become
stale. The consequence of stale information in this case will be a
suboptimal path (unless the internetwork has partitioned or some
other routing failure has occurred).
6.3 Use of the Prefix Length field of a CIE
A certain amount of care needs to be taken when using the Prefix
Length field of a CIE, in particular with regard to the prefix length
advertised (and thus the size of the equivalence class specified by
it). Assuming that the routers on the NBMA subnetwork are exchanging
routing information, it should not be possible for an NHS to create a
black hole by advertising too large of a set of destinations, but
suboptimal routing (e.g., extra internetwork layer hops through the
NBMA) can result. To avoid this situation an NHS that wants to send
the Prefix Length MUST obey the following rule:
The NHS examines the Network Layer Reachability Information (NLRI)
associated with the route that the NHS would use to forward towards
the destination (as specified by the Destination internetwork layer
address in the NHRP Resolution Request), and extracts from this
NLRI the shortest address prefix such that: (a) the Destination
internetwork layer address (from the NHRP Resolution Request) is
covered by the prefix, (b) the NHS does not have any routes with
NLRI which form a subset of what is covered by the prefix. The
prefix may then be used in the CIE.
The Prefix Length field of the CIE should be used with restraint, in
order to avoid NHRP stations choosing suboptimal transit paths when
overlapping prefixes are available. This document specifies the use
of the prefix length only when all the destinations covered by the
prefix are "stable". That is, either:
(a) All destinations covered by the prefix are on the NBMA network,
or
(b) All destinations covered by the prefix are directly attached to
the NHRP responding station.
Use of the Prefix Length field of the CIE in other circumstances is
outside the scope of this document.
6.4 Domino Effect
One could easily imagine a situation where a router, acting as an
ingress station to the NBMA subnetwork, receives a data packet, such
that this packet triggers an NHRP Resolution Request. If the router
forwards this data packet without waiting for an NHRP transit path to
be established, then when the next router along the path receives the
packet, the next router may do exactly the same - originate its own
NHRP Resolution Request (as well as forward the packet). In fact
such a data packet may trigger NHRP Resolution Request generation at
every router along the path through an NBMA subnetwork. We refer to
this phenomena as the NHRP "domino" effect.
The NHRP domino effect is clearly undesirable. At best it may result
in excessive NHRP traffic. At worst it may result in an excessive
number of virtual circuits being established unnecessarily.
Therefore, it is important to take certain measures to avoid or
suppress this behavior. NHRP implementations for NHSs MUST provide a
mechanism to address this problem. One possible strategy to address
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
the traffic the router receives over its non-NBMA interfaces
(interfaces that are not attached to an NBMA subnetwork). Traffic
received by the router over its NBMA-attached interfaces would not
trigger NHRP Resolution Requests. Such a router avoids the NHRP
domino effect through administrative means.
7. NHRP over Legacy BMA Networks
There would appear to be no significant impediment to running NHRP
over legacy broadcast subnetworks. There may be issues around
running NHRP across multiple subnetworks. Running NHRP on broadcast
media has some interesting possibilities; especially when setting up
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
research.
8. Discussion
The result of an NHRP Resolution Request depends on how routing is
configured among the NHSs of an NBMA subnetwork. If the destination
station is directly connected to the NBMA subnetwork and the routed
path to it lies entirely within the NBMA subnetwork, the NHRP
Resolution Replies always return the NBMA address of the destination
station itself rather than the NBMA address of some egress router.
On the other hand, if the routed path exits the NBMA subnetwork, NHRP
will be unable to resolve the NBMA address of the destination, but
rather will return the address of the egress router. For
destinations outside the NBMA subnetwork, egress routers and routers
in the other subnetworks should exchange routing information so that
the optimal egress router may be found.
In addition to NHSs, an NBMA station could also be associated with
one or more regular routers that could act as "connectionless
servers" for the station. The station could then choose to resolve
the NBMA next hop or just send the packets to one of its
connectionless servers. The latter option may be desirable if
communication with the destination is short-lived and/or doesn't
require much network resources. The connectionless servers could, of
course, be physically integrated in the NHSs by augmenting them with
internetwork layer switching functionality.
9. IANA Considerations
IANA will take advice from the Area Director appointed designated
subject matter expert, in order to assign numbers from the various
number spaces described herein. In the event that the Area Director
appointed designated subject matter expert is unavailable, the
relevant IESG Area Director will appoint another expert. Any and all
requests for value assignment within a given number space will be
accepted when the usage of the value assignment documented. Possible
forms of documentantion include, but is not limited to, RFCs or the
product of another cooperative standards body (e.g., the MPOA and
LANE subworking group of the ATM Forum).
References
[1] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol
(NARP)", RFC1735, December 1994.
[2] Plummer, D., "Address Resolution Protocol", STD 37, RFC826,
November 1982.
[3] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC
2225, April 1998.
[4] Piscitello,, D., and J. Lawrence, "Transmission of IP datagrams
over the SMDS service", RFC1209, March 1991.
[5] Protocol Identification in the Network Layer, ISO/IEC TR
9577:1990.
[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC1483, July 1993.
[8] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", RFC1356, August
1992.
[9] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect
over Frame Relay", RFC1490, July 1993.
[10] Rekhter, Y., and D. Kandlur, ""Local/Remote" Forwarding Decision
in Switched Data Link Subnetworks", RFC1937, May 1996.
[11] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
Networks", RFC2022, November 1996.
[12] Luciani, J., Armitage, G., and J. Halpern, "Server Cache
Synchronization Protocol (SCSP) - NBMA", RFC2334, April 1998.
[13] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork",
Work In Progress.
[14] Luciani, J., et. al., "Classical IP and ARP over ATM to NHRP
Transition", Work In Progress.
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing
for Message Authentication", RFC2104, February 1997.
Acknowledgments
We would like to thank (in no particular order) Thomas Narten of IBM
for his comments in the role of Internet AD, Juha Heinenan of Telecom
Finland and Ramesh 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 IBM, John Burnett of Adaptive, Dennis Ferguson of
ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul
Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco,
and Grenville Armitage of Bellcore should also be acknowledged for
comments and suggestions that improved this work substantially. We
would also like to thank the members of the ION working group of the
IETF, whose review and discussion of this document have been
invaluable.
Authors' Addresses
James V. Luciani Dave Katz
Bay Networks cisco Systems
3 Federal Street 170 W. Tasman Dr.
Mail Stop: BL3-03 San Jose, CA 95134 USA
Billerica, MA 01821 Phone: +1 408 526 8284
Phone: +1 978 916 4734 EMail: dkatz@cisco.com
EMail: luciani@baynetworks.com
David Piscitello Bruce Cole
Core Competence Juniper Networks
1620 Tuckerstown Road 3260 Jay St.
Dresher, PA 19025 USA Santa Clara, CA 95054
Phone: +1 215 830 0692 Phone: +1 408 327 1900
EMail: dave@corecom.com EMail: bcole@jnx.com
Naganand Doraswamy
Bay Networks, Inc.
3 Federal Street
Mail Stop: Bl3-03
Billerica, MA 01801
Phone: +1 978 916 1323
EMail: naganand@baynetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.