draft-ietf-rolc-nhrp-10.txt   draft-ietf-rolc-nhrp-11.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-10.txt> Dave Katz <draft-ietf-rolc-nhrp-11.txt> Dave Katz
(cisco Systems) (cisco Systems)
David Piscitello David Piscitello
(Core Competence, Inc.) (Core Competence, Inc.)
Bruce Cole Bruce Cole
(cisco Systems) (Juniper Networks)
Expires September 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 7, line 16 skipping to change at page 7, line 18
authoritative" address resolution information if the NHS is permitted authoritative" address resolution information if the NHS is permitted
to do so (see Sections 5.2.2 and 6.2 for more information on non- to do so (see Sections 5.2.2 and 6.2 for more information on non-
authoritative versus authoritative NHRP Resolution Replies). Non- authoritative versus authoritative NHRP Resolution Replies). Non-
authoritative NHRP Resolution Replies are distinguished from authoritative NHRP Resolution Replies are distinguished from
authoritative NHRP Resolution Replies so that if a communication authoritative NHRP Resolution Replies so that if a communication
attempt based on non-authoritative information fails, a source attempt based on non-authoritative information fails, a source
station can choose to send an authoritative NHRP Resolution Request. station can choose to send an authoritative NHRP Resolution Request.
NHSs MUST NOT respond to authoritative NHRP Resolution Requests with NHSs MUST NOT respond to authoritative NHRP Resolution Requests with
cached information. cached information.
An NHRP Resolution Reply may be returned directly to the NHRP
Resolution Request initiator, without traversing the NHSs which
forwarded the NHRP Resolution Request, if each of the following
criteria are satisfied:
(a) Direct communication is available via datagram transfer
(e.g., SMDS) or the NHS has an existing virtual circuit
connection to the NHC which sent the NHRP Resolution Request
or NHS is permitted to open a connection the NHC.
(b) The NHRP Resolution Request initiator has not included the
NHRP Reverse NHS record Extension (see Section 5.3.3).
(c) The authentication policy in force permits direct
communication between the NHS and the NHRP Resolution
Request initiator.
The purpose of allowing an NHS to send a NHRP Resolution Reply
directly is to reduce response time. A consequence of allowing a
direct NHRP Resolution Reply is that NHSs that would under normal
circumstances be traversed by the NHRP Resolution Reply would not
cache next hop information contained therein. This feature may have
value when the serving NHS is an egress router for the destination
address which is off the NBMA cloud (this implies that NHC
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 a routed path in the same fashion and NHRP Error Indications follow a routed path in the same fashion
that NHRP Resolution Requests and NHRP Resolution Replies do. that NHRP Resolution Requests and NHRP Resolution Replies do.
skipping to change at page 8, line 14 skipping to change at page 7, line 40
initiating the communication) to the Destination Protocol Address. initiating the communication) to the Destination Protocol Address.
"Replies", on the other hand, follow the routed path from the "Replies", on the other hand, follow the routed path from the
Destination Protocol Address back to the Source Protocol Address with Destination Protocol Address back to the Source Protocol Address with
the following exceptions: in the case of a NHRP Registration Reply 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 and in the case of an NHC initiated NHRP Purge Request, the packet is
always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if
one does not exists then one MUST be created. 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 data traffic out of and
NBMA subnetwork always traverses an internetwork layer router at its into an NBMA subnetwork always traverses an internetwork layer router
border. Internetwork layer filtering can then be implemented at at its border.
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
example, suppose that router X is the next hop from station S to example, suppose that router X is the next hop from station S to
station D and that X is an egress router for all stations sharing an station D and that X is an egress router for all stations sharing an
internetwork layer address prefix with station D. When an NHRP internetwork layer address prefix with station D. When an NHRP
Resolution Reply is generated in response to a NHRP Resolution Resolution Reply is generated in response to a NHRP Resolution
Request, the responder may augment the internetwork layer address of Request, the responder may augment the internetwork layer address of
station D with a prefix length (see Section 5.2.0.1). A subsequent station D with a prefix length (see Section 5.2.0.1). A subsequent
(non-authoritative) NHRP Resolution Request for some destination that (non-authoritative) NHRP Resolution Request for some destination that
skipping to change at page 9, line 28 skipping to change at page 9, line 4
decision, NHRP packets are not encapsulated within a protocol layer decision, NHRP packets are not encapsulated within a protocol layer
header but rather are carried at the NBMA layer using the header but rather are carried at the NBMA layer using the
encapsulation described in Section 5. encapsulation described in Section 5.
Each NHS/router examines the NHRP Resolution Request packet on its Each NHS/router examines the NHRP Resolution Request packet on its
way toward the destination. Each NHS which the NHRP packet traverses way toward the destination. Each NHS which the NHRP packet traverses
on the way to the packet's destination might modify the packet (e.g., 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 an 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 other applicable means (such as static configuration an NHS may use other applicable means (such as static configuration
information ) in order to determine to which neighboring NHSs to information ) in order to determine to which neighboring NHSs to
forward the NHRP Resolution Request packet as long as such other 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 means would not cause the NHRP packet to arrive at an NHS which is
not along the routed path. The use of static configuration not along the routed path. The use of static configuration
skipping to change at page 14, line 24 skipping to change at page 14, line 18
SNAP: ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00 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 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 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 and thus, since the Ethertype coding exists, it is used in
preference. 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. This field
is used in a similar fashion to the way that a TTL is used in an IP
packet and should be set accordingly. Each NHS decrements the TTL
as the NHRP packet transits the NHS on the way to the next hop
along the routed path to the destination. If an NHS receives an
NHRP packet which it would normally forward to a next hop and that
packet contains an ar$hopcnt set to zero then the NHS sends an
error indication message back to the source protocol address
stating that the hop count has been exceeded (see Section 5.2.7)
and the NHS drops the packet in error; however, an error
indication is never sent as a result of receiving an error
indication. When a responding NHS replies to an NHRP request, that
NHS places a value in ar$hopcnt as if it were sending a request of
its own.
ar$pktsz 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
The standard IP checksum over the entire NHRP packet (starting with The standard IP checksum over the entire NHRP packet (starting with
the fixed header). If only the hop count field is changed, the the fixed header). If only the hop count field is changed, the
checksum is adjusted without full recomputation. The checksum is checksum is adjusted without full recomputation. The checksum is
completely recomputed when other header fields are changed. completely recomputed when other header fields are changed.
skipping to change at page 18, 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.
For those NBMA technologies which have a notion of "Calling Party
Addresses", the Source NBMA Addresses above are the addresses used
when signaling for an SVC.
"Requests" and "indications" follow the routed path from Source "Requests" and "indications" follow the routed path from Source
Protocol Address to the Destination Protocol Address. "Replies", on Protocol Address to the Destination Protocol Address. "Replies", on
the other hand, follow the routed path from the Destination Protocol the other hand, follow the routed path from the Destination Protocol
Address back to the Source Protocol Address with the following Address back to the Source Protocol Address with the following
exceptions: in the case of a NHRP Registration Reply and in the case 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 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). 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
skipping to change at page 20, line 20 skipping to change at page 20, line 24
Client NBMA Address Client NBMA Address
This is the client's NBMA address. This is the client's NBMA address.
Client NBMA SubAddress Client NBMA SubAddress
This is the client's NBMA subaddress. This is the client's NBMA subaddress.
Client Protocol Address Client Protocol Address
This is the client's internetworking layer address specified. This is the client's internetworking layer address specified.
Note that an NHS SHOULD NOT cache source information which is in an Note that an NHS may cache source address binding information from an
NHRP message because this information could be inappropriately used NHRP Resolution Request if and only if the conditions described in
to set up a cut-through without doing proper filtering along a routed Section 6.2 are met for the NHS. In all other cases, source address
path. Further, in the case where a distributed router exists in the binding information appearing in an NHRP message MUST NOT be cached.
network, incorrect or incomplete information may be included in the
source information.
5.2.1 NHRP Resolution Request 5.2.1 NHRP Resolution Request
The NHRP Resolution Request packet has a Type code of 1. Its The NHRP Resolution Request packet has a Type code of 1. Its
mandatory part is coded as described in Section 5.2.0.1 and the mandatory part is coded as described in Section 5.2.0.1 and the
message specific meanings of the fields are as follows: message specific meanings of the fields are as follows:
Flags - The flags field is coded as follows: Flags - The flags field is coded as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|B|U| unused | |Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q Q
Set if the station sending the NHRP Resolution Request is a Set if the station sending the NHRP Resolution Request is a
router; clear if the it is a host. router; clear if the it is a host.
A A
This bit is set in a NHRP Resolution Request if only This bit is set in a NHRP Resolution Request if only
authoritative next hop information is desired and is clear authoritative next hop information is desired and is clear
otherwise. See the NHRP Resolution Reply section below for otherwise. See the NHRP Resolution Reply section below for
further details on the "A" bit and its usage. further details on the "A" bit and its usage.
B D
Unused (clear on transmit) Unused (clear on transmit)
U U
This is the Uniqueness bit. This bit aids in duplicate address This is the Uniqueness bit. This bit aids in duplicate address
detection. When this bit is set in an NHRP Resolution Request detection. When this bit is set in an NHRP Resolution Request
and one or more entries exist in the NHS cache which meet the and one or more entries exist in the NHS cache which meet the
requirements of the NHRP Resolution Request then only the CIE in requirements of the NHRP Resolution Request then only the CIE in
the NHS's cache with this bit set will be returned. Note that the NHS's cache with this bit set will be returned. Note that
even if this bit was set at registration time, there may still be even if this bit was set at registration time, there may still be
multiple CIEs that might fulfill the NHRP Resolution Request multiple CIEs that might fulfill the NHRP Resolution Request
because an entire subnet can be registered through use of the because an entire subnet can be registered through use of the
Prefix Length in the CIE and the address of interest might be Prefix Length in the CIE and the address of interest might be
skipping to change at page 21, line 26 skipping to change at page 21, line 30
request but no such cache entry has the "uniqueness" bit set, request but no such cache entry has the "uniqueness" bit set,
then the NHRP Resolution Reply returns with a NAK code of "13 - then the NHRP Resolution Reply returns with a NAK code of "13 -
Binding Exists But Is Not Unique" and no CIE is included. If a Binding Exists But Is Not Unique" and no CIE is included. If a
client wishes to receive non- unique Next Hop Entries, then client wishes to receive non- unique Next Hop Entries, then
the client must have the "uniqueness" bit set to zero in its NHRP the client must have the "uniqueness" bit set to zero in its NHRP
Resolution Request. Note that when this bit is set in an NHRP Resolution Request. Note that when this bit is set in an NHRP
Registration Request, only a single CIE may be specified in the Registration Request, only a single CIE may be specified in the
NHRP Registration Request and that CIE must have the Prefix NHRP Registration Request and that CIE must have the Prefix
Length field set to 0xFF. Length field set to 0xFF.
S
Set if the binding between the Source Protocol Address and the
Source NBMA information in the NHRP Resolution Request is
guaranteed to be stable and accurate (e.g., these addresses are
those of an ingress router which is connected to an ethernet stub
network or the NHC is an NBMA attached host).
Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP
Resolution Request. If one is specified then that entry carries the Resolution Request. If one is specified then that entry carries the
pertinent information for the client sourcing the NHRP Resolution pertinent information for the client sourcing the NHRP Resolution
Request. Usage of the CIE in the NHRP Resolution Request is Request. Usage of the CIE in the NHRP Resolution Request is
described below: described below:
Prefix Length Prefix Length
If a CIE is specified in the NHRP Resolution Request then the If a CIE is specified in the NHRP Resolution Request then the
Prefix Length field may be used to qualify the widest acceptable Prefix Length field may be used to qualify the widest acceptable
prefix which may be used to satisfy the NHRP Resolution Request. prefix which may be used to satisfy the NHRP Resolution Request.
skipping to change at page 21, line 48 skipping to change at page 22, line 11
first "Prefix Length" bit positions of the Destination Protocol first "Prefix Length" bit positions of the Destination Protocol
Address. If the "U" bit is set in the common header then this Address. If the "U" bit is set in the common header then this
field MUST be set to 0xFF. field MUST be set to 0xFF.
Maximum Transmission Unit Maximum Transmission Unit
This field gives the maximum transmission unit for the source This field gives the maximum transmission unit for the source
station. A possible use of this field in the NHRP Resolution station. A possible use of this field in the NHRP Resolution
Request packet is for the NHRP Resolution Requester to ask for a Request packet is for the NHRP Resolution Requester to ask for a
target MTU. In lieu of that usage, the CIE must be omitted. target MTU. In lieu of that usage, the CIE must be omitted.
Holding Time
The Holding Time specified in the one CIE permitted to be
included in an NHRP Resolution Request is the amount of time
which the source address binding information in the NHRP
Resolution Request is permitted to cached by transit and
responding NHSs. Note that this field may only have a non-zero
value if the S bit is set.
All other fields in the CIE MUST be ignored and SHOULD be set to 0. All other fields in the CIE MUST be ignored and SHOULD be set to 0.
The Destination Protocol Address in the common header of the The Destination Protocol Address in the common header of the
Mandatory Part of this message contains the protocol address of the Mandatory Part of this message contains the protocol address of the
station for which resolution is desired. An NHC MUST send the NHRP station for which resolution is desired. An NHC MUST send the NHRP
Resolution Request directly to one of its serving NHSs (see Section 3 Resolution Request directly to one of its serving NHSs (see Section 3
for more information). for more information).
5.2.2 NHRP Resolution Reply 5.2.2 NHRP Resolution Reply
skipping to change at page 22, line 21 skipping to change at page 22, line 40
correspond to Next Hop Entries in an NHS's cache which match the correspond to Next Hop Entries in an NHS's cache which match the
criteria in the NHRP Resolution Request. Its mandatory part is coded criteria in the NHRP Resolution Request. Its mandatory part is coded
as described in Section 5.2.0.1. The message specific meanings of as described in Section 5.2.0.1. The message specific meanings of
the fields are as follows: the fields are as follows:
Flags - The flags field is coded as follows: Flags - The flags field is coded as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|B|U| unused | |Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q Q
Copied from the NHRP Resolution Request. Set if the NHRP Copied from the NHRP Resolution Request. Set if the NHRP
Resolution Requester is a router; clear if it is a host. Resolution Requester is a router; clear if it is a host.
A A
Set if the next hop CIE in the NHRP Resolution Reply is Set if the next hop CIE in the NHRP Resolution Reply is
authoritative; clear if the NHRP Resolution Reply is non- authoritative; clear if the NHRP Resolution Reply is non-
authoritative. authoritative.
skipping to change at page 23, line 9 skipping to change at page 23, line 28
obtained this information through a NHRP Registration Request. obtained this information through a NHRP Registration Request.
An NHS obtains non-authoritative 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 D
Set if the association between the destination and the next hop Set if the association between destination and the associate next
information is guaranteed to be stable for the lifetime of the hop information included in all CIEs of the NHRP Resolution Reply
information (the holding time). This is the case if the Next Hop is guaranteed to be stable for the lifetime of the information
protocol address identifies the destination (though it may be (the holding time). This is the case if the Next Hop protocol
address in a CIE identifies the destination (though it may be
different in value than the Destination address if the different in value than the Destination address if the
destination system has multiple addresses) or if the destination destination system has multiple addresses) or if the destination
is not connected directly to the NBMA subnetwork but the egress is not connected directly to the NBMA subnetwork but the egress
router to that destination is guaranteed to be stable (such as router to that destination is guaranteed to be stable (such as
when the destination is immediately adjacent to the egress router when the destination is immediately adjacent to the egress router
through a non-NBMA interface). This information affects caching through a non-NBMA interface).
strategies (see section 6.2).
U U
This is the Uniqueness bit. See the NHRP Resolution Request This is the Uniqueness bit. See the NHRP Resolution Request
section above for details. When this bit is set only, only one section above for details. When this bit is set only, only one
CIE is included since only one unique binding should exist in an CIE is included since only one unique binding should exist in an
NHS's cache. NHS's cache.
S
Copied from NHRP Resolution Request message.
One or more CIEs are specified in the NHRP Resolution Reply. Each CIE One or more CIEs are specified in the NHRP Resolution Reply. Each CIE
contains NHRP next hop information which the responding NHS has contains NHRP next hop information which the responding NHS has
cached and which matches the parameters specified in the NHRP cached and which matches the parameters specified in the NHRP
Resolution Request. If no match is found by the NHS issuing the NHRP Resolution Request. If no match is found by the NHS issuing the NHRP
Resolution Reply then a single CIE is enclosed with the a CIE Code Resolution Reply then a single CIE is enclosed with the a CIE Code
set appropriately (see below) and all other fields MUST be ignored set appropriately (see below) and all other fields MUST be ignored
and SHOULD be set to 0. In order to facilitate the use of NHRP by and SHOULD be set to 0. In order to facilitate the use of NHRP by
minimal client implementations, the first CIE MUST contain the next minimal client implementations, the first CIE MUST contain the next
hop with the highest preference value so that such an implementation hop with the highest preference value so that such an implementation
need parse only a single CIE. need parse only a single CIE.
skipping to change at page 23, line 50 skipping to change at page 24, line 23
If this field is set to zero then this packet contains a If this field is set to zero then this packet contains a
positively acknowledged NHRP Resolution Reply. If this field positively acknowledged NHRP Resolution Reply. If this field
contains any other value then this message contains an NHRP contains any other value then this message contains an NHRP
Resolution Reply NAK which means that an appropriate Resolution Reply NAK which means that an appropriate
internetworking layer to NBMA address binding was not available internetworking layer to NBMA address binding was not available
in the responding NHS's cache. If NHRP Resolution Reply contains in the responding NHS's cache. If NHRP Resolution Reply contains
a Client Information Entry with a NAK Code other than 0 then it a Client Information Entry with a NAK Code other than 0 then it
MUST NOT contain any other CIE. Currently defined NAK Codes are MUST NOT contain any other CIE. Currently defined NAK Codes are
as follows: as follows:
4 - Administratively Prohibited
An NHS may refuse an NHRP Resolution Request attempt for
administrative reasons (due to policy constraints or routing
state). If so, the NHS MUST send an NHRP Resolution Reply
which contains a NAK code of 4.
5 - Insufficient Resources
If an NHS cannot serve a station due to a lack of resources
(e.g., can't store sufficient information to send a purge if
routing changes), the NHS MUST reply with a NAKed NHRP
Resolution Reply which contains a NAK code of 5.
12 - No Internetworking Layer Address to NBMA Address Binding 12 - No Internetworking Layer Address to NBMA Address Binding
Exists Exists
This code states that there were absolutely no internetworking This code states that there were absolutely no internetworking
layer address to NBMA address bindings found in the responding layer address to NBMA address bindings found in the responding
NHS's cache. NHS's cache.
13 - Binding Exists But Is Not Unique 13 - Binding Exists But Is Not Unique
This code states that there were one or more internetworking This code states that there were one or more internetworking
layer address to NBMA address bindings found in the responding layer address to NBMA address bindings found in the responding
NHS's cache, however none of them had the uniqueness bit set. NHS's cache, however none of them had the uniqueness bit set.
skipping to change at page 28, line 4 skipping to change at page 28, line 43
Attempts to register the information in the CIEs of an NHRP Attempts to register the information in the CIEs of an NHRP
Registration Request may fail for various reasons. If this is the Registration Request may fail for various reasons. If this is the
case then each failed attempt to register the information in a CIE of case then each failed attempt to register the information in a CIE of
an NHRP Registration Request is logged in the associated NHRP an NHRP Registration Request is logged in the associated NHRP
Registration Reply by setting the CIE Code field to the appropriate Registration Reply by setting the CIE Code field to the appropriate
error code as shown below: error code as shown below:
CIE Code CIE Code
0 - Successful Registration 0 - Successful Registration
The information in the CIE was successfully registered with the The information in the CIE was successfully registered with the
NHS. NHS.
4 - Can't Serve This Address 4 - Administratively Prohibited
An NHS may refuse an NHRP Registration Request attempt for An NHS may refuse an NHRP Registration Request attempt for
administrative reasons (due to policy constraints or routing administrative reasons (due to policy constraints or routing
state). If so, the NHS MUST send an NHRP Registration Reply state). If so, the NHS MUST send an NHRP Registration Reply
which contains a NAK code of 4. which contains a NAK code of 4.
5 - Registration Overflow 5 - Insufficient Resources
If an NHS cannot serve a station due to a lack of resources, If an NHS cannot serve a station due to a lack of resources,
the NHS MUST reply with a NAKed NHRP Registration Reply which the NHS MUST reply with a NAKed NHRP Registration Reply which
contains a NAK code of 5. contains a NAK code of 5.
14 - Unique Internetworking Layer Address Already Registered 14 - Unique Internetworking Layer Address Already Registered
If a client tries to register a protocol address to NBMA If a client tries to register a protocol address to NBMA
address binding with the uniqueness bit on and the protocol address binding with the uniqueness bit on and the protocol
address already exists in the NHS's cache then if that cache address already exists in the NHS's cache then if that cache
entry also has the uniqueness bit on then this NAK Code is entry also has the uniqueness bit on then this NAK Code is
skipping to change at page 30, line 35 skipping to change at page 31, line 24
sourced by the NHS and not the NHC; that is, for each NHC that sourced by the NHS and not the NHC; that is, for each NHC that
previously sent a NHRP Resolution Request for the purged NHC NBMA previously sent a NHRP Resolution Request for the purged NHC NBMA
information, an NHRP Purge Request is sent which contains the Source information, an NHRP Purge Request is sent which contains the Source
Protocol/NBMA Addresses of the NHS and the Destination Protocol Protocol/NBMA Addresses of the NHS and the Destination Protocol
Address of the NHC which previously sent an NHRP Resolution Request Address of the NHC which previously sent an NHRP Resolution Request
prior to the purge. prior to the purge.
The station sending the NHRP Purge Request MAY periodically The station sending the NHRP Purge Request MAY periodically
retransmit the NHRP Purge Request until either NHRP Purge Request is retransmit the NHRP Purge Request until either NHRP Purge Request is
acknowledged or until the holding time of the information being acknowledged or until the holding time of the information being
purged has expired. Retransmission strategies for NHRP Purge purged has expired. Retransmission strategies for NHRP Purge Requests
Requests are a local matter. are a local matter.
When a station receives an NHRP Purge Request, it MUST discard any When a station receives an NHRP Purge Request, it MUST discard any
previously cached information that matches the information in the previously cached information that matches the information in the
CIEs. CIEs.
An NHRP Purge Reply MUST be returned for the NHRP Purge Request even An NHRP Purge Reply MUST be returned for the NHRP Purge Request even
if the station does not have a matching cache entry assuming that the if the station does not have a matching cache entry assuming that the
"N" bit is off in the NHRP Purge Request. "N" bit is off in the NHRP Purge Request.
If the station wishes to reestablish communication with the If the station wishes to reestablish communication with the
skipping to change at page 35, line 26 skipping to change at page 36, line 26
If a transit NHS (one which is not going to generate a "reply") If a transit NHS (one which is not going to generate a "reply")
detects an unrecognized extension, it SHALL ignore the extension. If detects an unrecognized extension, it SHALL ignore the extension. If
the Compulsory bit is set, the transit NHS MUST NOT cache the the Compulsory bit is set, the transit NHS MUST NOT cache the
information contained in the packet and MUST NOT identify itself as information contained in the packet and MUST NOT identify itself as
an egress router (in the Forward Record or Reverse Record an egress router (in the Forward Record or Reverse Record
extensions). Effectively, this means, if a transit NHS encounters an extensions). Effectively, this means, if a transit NHS encounters an
extension which it cannot process and which has the Compulsory bit extension which it cannot process and which has the Compulsory bit
set then that NHS MUST NOT participate in any way in the protocol set then that NHS MUST NOT participate in any way in the protocol
exchange other than acting as a forwarding agent. exchange other than acting as a forwarding agent.
Use of NHRP extension Types in the range 8192 to 16383 are reserved The NHRP extension Type space is subdivided to encourage use outside
for research or use in other protocol development and will be the IETF.
administered by IANA.
0x0000 - 0x0FFF Reserved for NHRP.
0x1000 - 0x11FF Allocated to the ATM Forum.
0x1200 - 0x37FF Reserved for the IETF.
0x3800 - 0x3FFF Experimental use.
IANA will administer the ranges reserved for the IETF. Values in the
'Experimental use' range have only local sigificance.
5.3.0 The End Of Extensions 5.3.0 The End Of Extensions
Compulsory = 1 Compulsory = 1
Type = 0 Type = 0
Length = 0 Length = 0
When extensions exist, the extensions list is terminated by the End When extensions exist, the extensions list is terminated by the End
Of Extensions/Null TLV. Of Extensions/Null TLV.
skipping to change at page 36, line 11 skipping to change at page 37, line 18
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 Prefix Length fields MUST be set to 0 and ignored. The Prefix Length fields MUST be set to 0 and ignored.
CIE Code CIE Code
16 - Insufficient Resources Exist To Setup Cut-Through 5 - Insufficient Resources
If the responder to an NHRP Resolution Request is an egress point 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 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 of the stations identified in the list of CIEs in an NHRP
Resolution Reply) and the Responder Address extension is included Resolution Reply) and the Responder Address extension is included
in the NHRP Resolution Request and insufficient resources to in the NHRP Resolution Request and insufficient resources to
setup a cut-through VC exist at the responder then the Code field 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 of the Responder Address Extension is set to 5 in order to tell
to tell the client that a VC setup attempt would in all the client that a VC setup attempt would in all likelihood be
likelihood be rejected; otherwise this field MUST be coded as a rejected; otherwise this field MUST be coded as a zero. NHCs MAY
zero. NHCs MAY use this field to influence whether they attempt use this field to influence whether they attempt to setup a cut-
to setup a cut-through to the egress router. 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 37, line 40 skipping to change at page 38, line 49
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 Prefix Length fields MUST be set to 0 and ignored. The Prefix Length fields MUST be set to 0 and ignored.
CIE Code CIE Code
16 - Insufficient Resources Exist To Setup Cut-Through 5 - Insufficient Resources
If an NHRP Resolution Request contains an NHRP Forward Transit If an NHRP Resolution Request contains an NHRP Forward Transit
NHS Record Extension and insufficient resources to setup a cut- NHS Record Extension and insufficient resources to setup a cut-
through VC exist at the current transit NHS then the CIE Code through VC exist at the current transit NHS then the CIE Code
field for NHRP Forward Transit NHS Record Extension is set to 16 field for NHRP Forward Transit NHS Record Extension is set to 5
decimal in order to tell the client that a VC setup attempt would in order to tell the client that a VC setup attempt would in all
in all likelihood be rejected; otherwise this field MUST be coded likelihood be rejected; otherwise this field MUST be coded as a
as a zero. NHCs MAY use this field to influence whether they zero. NHCs MAY use this field to influence whether they attempt
attempt to setup a cut-through as described in Section 2.2. Note to setup a cut-through as described in Section 2.2. Note that
that the NHRP Reverse Transit NHS Record Extension MUST always the NHRP Reverse Transit NHS Record Extension MUST always have
have this field set to zero. 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 42, line 36 skipping to change at page 43, line 45
6.2 Cache Management Issues 6.2 Cache Management Issues
The management of NHRP caches in the source station, the NHS serving The management of NHRP caches in the source station, the NHS serving
the destination, and any intermediate NHSs is dependent on a number the destination, and any intermediate NHSs is dependent on a number
of factors. of factors.
6.2.1 Caching Requirements 6.2.1 Caching Requirements
Source Stations Source Stations
Source stations MUST cache all received NHRP Resolution Replies that Source stations MUST cache all received NHRP Resolution Replies
they are actively using. They also must cache "incomplete" entries, that they are actively using. They also must cache "incomplete"
i.e., those for which a NHRP Resolution Request has been sent but entries, i.e., those for which a NHRP Resolution Request has been
which a NHRP Resolution Reply has not been received. This is sent but those for which an NHRP Resolution Reply has not been
necessary in order to preserve the Request ID for retries, and received. This is necessary in order to preserve the Request ID
provides the state necessary to avoid triggering NHRP Resolution for retries, and provides the state necessary to avoid triggering
Requests for every data packet sent to the destination. NHRP Resolution Requests for every data packet sent to the
destination.
Source stations MUST purge expired information from their caches. Source stations MUST purge expired information from their caches.
Source stations MUST purge the appropriate cached information upon Source stations MUST purge the appropriate cached information upon
receipt of an NHRP Purge Request packet. receipt of an NHRP Purge Request packet.
When a station has a co-resident client and NHS, the station may When a station has a co-resident NHC and NHS, the co-resident NHS
reply to NHRP Resolution Requests with information which the station may reply to NHRP Resolution Requests from the co-resident NHC with
cached as a result of the station making its own NHRP Resolution information which the station cached as a result of the co-resident
Requests and receiving its own NHRP Resolution Replies as long as the NHC making its own NHRP Resolution Requests as long as the co-
station follows the rules for Transit NHSs as seen below. resident NHS 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 protocol
about all NHRP Resolution Requests to which it has responded if the address information from all NHRP Resolution Requests to which it
information in the NHRP Resolution Reply has the possibility of has responded if the information in the NHRP Resolution Reply has
changing during its lifetime (so that an NHRP Purge Request packet the possibility of changing during its lifetime (so that an NHRP
can be issued). The NBMA information provided by the source station Purge Request packet can be issued). The internetworking to NBMA
in the NHRP Resolution Request may be cached for the duration of its binding information provided by the source station in the NHRP
holding time. This information is considered to be stable, since it Resolution Request may also be cached if and only if the "S" bit is
identifies a station directly attached to the NBMA subnetwork. An set, the NHRP Resolution Request has included a CIE with the
example of unstable information is NBMA information derived from a Holding Time field set greater than zero (this is the valid Holding
routing table, where that routing table information has not been Time for the source binding), and only for non-authoritative use
guaranteed to be stable through administrative means. for a period not to exceed the Holding Time.
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 source binding information
Resolution Request packets that it forwards. A Transit NHS may cache contained in NHRP Resolution Request packets that it forwards if
information contained in NHRP Resolution Reply packets that it and only if the "S" bit is set, the NHRP Resolution Request has
forwards only if that NHRP Resolution Reply has the Stable (B) bit included a CIE with the Holding Time field set greater than zero
set. It MUST discard any cached information whose holding time has (this is the valid Holding Time for the source binding), and only
expired. It may return cached information in response to non- for non-authoritative use for a period not to exceed the Holding
authoritative NHRP Resolution Requests only. 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 6.2.2 Dynamics of Cached Information
NBMA-Connected Destinations NBMA-Connected Destinations
NHRP's most basic function is that of simple NBMA address NHRP's most basic function is that of simple NBMA address
resolution of stations directly attached to the NBMA subnetwork. resolution of stations directly attached to the NBMA subnetwork.
These mappings are typically very static, and appropriately chosen These mappings are typically very static, and appropriately chosen
holding times will minimize problems in the event that the NBMA holding times will minimize problems in the event that the NBMA
address of a station must be changed. Stale information will cause address of a station must be changed. Stale information will cause
a loss of connectivity, which may be used to trigger an a loss of connectivity, which may be used to trigger an
authoritative NHRP Resolution Request and bypass the old data. In authoritative NHRP Resolution Request and bypass the old data. In
the worst case, connectivity will fail until the cache entry times the worst case, connectivity will fail until the cache entry times
out. out.
This applies equally to information marked in NHRP Resolution This applies equally to information marked in NHRP Resolution
Replies as being "stable" (via the "B" bit). Replies as being "stable" (via the "D" bit).
This also applies equally well to source stations that are routers
as well as those which are hosts.
Note that the information carried in the NHRP Resolution Request
packet is always considered "stable" because it represents a
station that is directly connected to the NBMA subnetwork.
Destinations Off of the NBMA Subnetwork Destinations Off of the NBMA Subnetwork
If the source of a NHRP Resolution Request is a host and the If the source of an NHRP Resolution Request is a host and the
destination is not directly attached to the NBMA subnetwork, and destination is not directly attached to the NBMA subnetwork, and
the route to that destination is not considered to be "stable," the the route to that destination is not considered to be "stable," the
destination mapping may be very dynamic (except in the case of a destination mapping may be very dynamic (except in the case of a
subnetwork where each destination is only singly homed to the NBMA subnetwork where each destination is only singly homed to the NBMA
subnetwork). As such the cached information may very likely become subnetwork). As such the cached information may very likely become
stale. The consequence of stale information in this case will be a stale. The consequence of stale information in this case will be a
suboptimal path (unless the internetwork has partitioned or some suboptimal path (unless the internetwork has partitioned or some
other routing failure has occurred). other routing failure has occurred).
6.3 Use of the Prefix Length field of a CIE 6.3 Use of the Prefix Length field of a CIE
skipping to change at page 44, line 37 skipping to change at page 46, line 8
NBMA) can result. To avoid this situation an NHS that wants to send NBMA) can result. To avoid this situation an NHS that wants to send
the Prefix Length MUST obey the following rule: the Prefix Length MUST obey the following rule:
The NHS examines the Network Layer Reachability Information (NLRI) The NHS examines the Network Layer Reachability Information (NLRI)
associated with the route that the NHS would use to forward towards associated with the route that the NHS would use to forward towards
the destination (as specified by the Destination internetwork layer the destination (as specified by the Destination internetwork layer
address in the NHRP Resolution Request), and extracts from this address in the NHRP Resolution Request), and extracts from this
NLRI the shortest address prefix such that: (a) the Destination NLRI the shortest address prefix such that: (a) the Destination
internetwork layer address (from the NHRP Resolution Request) is internetwork layer address (from the NHRP Resolution Request) is
covered by the prefix, (b) the NHS does not have any routes with covered by the prefix, (b) the NHS does not have any routes with
NLRI that forms a subset of what is covered by the prefix. The NLRI which form a subset of what is covered by the prefix. The
prefix may then be used in the CIE. prefix may then be used in the CIE.
The Prefix Length field of the CIE should be used with restraint, in The Prefix Length field of the CIE should be used with restraint, in
order to avoid NHRP stations choosing suboptimal transit paths when order to avoid NHRP stations choosing suboptimal transit paths when
overlapping prefixes are available. This document specifies the use overlapping prefixes are available. This document specifies the use
of the prefix length only when all the destinations covered by the of the prefix length only when all the destinations covered by the
prefix are "stable". That is, either: prefix are "stable". That is, either:
(a) All destinations covered by the prefix are on the NBMA network, or (a) All destinations covered by the prefix are on the NBMA network, or
skipping to change at page 47, line 32 skipping to change at page 49, line 7
[12] Server Cache Synchronization Protocol (SCSP) - NBMA, [12] Server Cache Synchronization Protocol (SCSP) - NBMA,
J. Luciani, G. Armitage, J. Halpern, Work In Progress. J. Luciani, G. Armitage, J. Halpern, Work In Progress.
[13] NHRP for Destinations off the NBMA Subnetwork, [13] NHRP for Destinations off the NBMA Subnetwork,
Y. Rekhter, Work In Progress. Y. Rekhter, Work In Progress.
[14] Classical IP to NHRP Transition, J. Luciani, et al., 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 (in no particular order) Juha Heinenan of
Govidan of ISI for their work on NBMA ARP and the original NHRP Telecom Finland and Ramesh Govidan of ISI for their work on NBMA ARP
draft, which served as the basis for this work. Russell Gardo of and the original NHRP draft, which served as the basis for this work.
IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Joel Halpern Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of
of Newbridge, Paul Francis of NTT, Tony Li and Yakov Rekhter of ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul
cisco, and Grenville Armitage of Bellcore should also be acknowledged Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco,
for comments and suggestions that improved this work substantially. and Grenville Armitage of Bellcore should also be acknowledged for
We would also like to thank the members of the ION working group of comments and suggestions that improved this work substantially. We
the IETF, whose review and discussion of this document have been 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. invaluable.
Authors' Addresses Authors' Addresses
James V. Luciani Dave Katz James V. Luciani Dave Katz
Bay Networks cisco Systems Bay Networks cisco Systems
3 Federal Street 170 W. Tasman Dr. 3 Federal Street 170 W. Tasman Dr.
Mail Stop: BL3-04 San Jose, CA 95134 USA Mail Stop: BL3-04 San Jose, CA 95134 USA
Billerica, MA 01821 Phone: +1 408 526 8284 Billerica, MA 01821 Phone: +1 408 526 8284
Phone: +1 508 439 4734 Email: dkatz@cisco.com Phone: +1 508 916 4734 Email: dkatz@cisco.com
Email: luciani@baynetworks.com Email: luciani@baynetworks.com
David Piscitello Bruce Cole David Piscitello Bruce Cole
Core Competence cisco Systems Core Competence Juniper Networks
1620 Tuckerstown Road 170 W. Tasman Dr. 1620 Tuckerstown Road 3260 Jay St.
Dresher, PA 19025 USA San Jose, CA 95134 USA Dresher, PA 19025 USA Santa Clara, CA 95054
Phone: +1 215 830 0692 Phone: +1 408 526 4000 Phone: +1 215 830 0692 Phone: +1 408 327 1900
Email: dave@corecom.com Email: bcole@cisco.com Email: dave@corecom.com Email: bcole@jnx.com
 End of changes. 39 change blocks. 
119 lines changed or deleted 159 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/