draft-ietf-rolc-nhrp-12.txt   draft-ietf-rolc-nhrp-13.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-12.txt> Dave Katz <draft-ietf-rolc-nhrp-13.txt> Dave Katz
(cisco Systems) (cisco Systems)
David Piscitello David Piscitello
(Core Competence, Inc.) (Core Competence, Inc.)
Bruce Cole Bruce Cole
(Juniper Networks) (Juniper Networks)
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [15]. document, are to be interpreted as described in [15].
Abstract Abstract
This document describes the NBMA Next Hop Resolution Protocol (NHRP). This document describes the NBMA Next Hop Resolution Protocol (NHRP).
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 Note that while this protocol was developed for use with NBMA
subnetworks, it is possible, if not likely, that it will be applied subnetworks, it is possible, if not likely, that it will be applied
to BMA subnetworks as well. However, this usage of NHRP is for to BMA subnetworks as well. However, this usage of NHRP is for
further study. 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].
skipping to change at page 9, line 51 skipping to change at page 9, line 51
which would otherwise need to be forwarded through such routers can which would otherwise need to be forwarded through such routers can
be expected to be dropped due to the NHRP packet not being be expected to be dropped due to the NHRP packet not being
recognized. In this case, NHRP will be unable to establish any 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 (appropriate to the routing realm it participates in) which
might then submit NHRP Resolution Requests to such an address, would be assigned to all NHS serving that routing realm. This
eliciting a response from one or more NHSs, depending on the response address can then be used for establishing an initial connection to an
strategy selected. Note that the constraints described in Section 2 NHS to transmit a registration request. This address may not be used
regarding directly sending NHRP Resolution Reply may apply. for sending NHRP requests. The resulting VC may be used for NHRP
requests if and only if the registration response is received over
that VC, thereby indicating that one happens to have anycast
connected to an NHS serving the LIS/LAG. In the case of non-
connection oriented networks, or of multicast (rather than anycast)
addresses, the addres MUST NOT be used for sending NHRP resolution
requests.
When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined
for the NHC directly to the NHC. That is, the NHRP message MUST NOT for the NHC directly to the NHC. That is, the NHRP message MUST NOT
transit through any NHS which is not serving the NHC when the NHRP transit through any NHS which is not serving the NHC when the NHRP
message is currently at an NHS which does serve the NHC (this, of message is currently at an NHS which does serve the NHC (this, of
course, assumes the NHRP message is destined for the NHC). Further, course, assumes the NHRP message is destined for the NHC). Further,
an NHS which serves an NHC SHOULD have a direct NBMA level connection an NHS which serves an NHC SHOULD have a direct NBMA level connection
to that NHC (see Section 5.2.3 and 5.2.4 for examples). to that NHC (see Section 5.2.3 and 5.2.4 for examples).
With the exception of NHRP Registration Requests (see Section 5.2.3 With the exception of NHRP Registration Requests (see Section 5.2.3
skipping to change at page 14, line 38 skipping to change at page 14, line 38
indication is never sent as a result of receiving an error indication is never sent as a result of receiving an error
indication. When a responding NHS replies to an NHRP request, that 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 NHS places a value in ar$hopcnt as if it were sending a request of
its own. 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 SCSP packet starting at The standard IP checksum over the entire NHRP packet starting at
the fixed header. If the packet is an odd number of bytes in the fixed header. If the packet is an odd number of bytes in
length then this calculation is performed as if a byte set to 0x00 length then this calculation is performed as if a byte set to 0x00
is appended to the end of the packet. is appended to the end of the packet.
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.
skipping to change at page 15, line 18 skipping to change at page 15, line 18
0x02 - 0xEF Reserved for future use by the IETF. 0x02 - 0xEF Reserved for future use by the IETF.
0xF0 - 0xFE Allocated for use by the ATM Forum. 0xF0 - 0xFE Allocated for use by the ATM Forum.
0xFF Experimental/Local use. 0xFF Experimental/Local use.
ar$op.type ar$op.type
When ar$op.version == 1, this is the NHRP packet type: NHRP When ar$op.version == 1, this is the NHRP packet type: NHRP
Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration
Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP
Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet
Types in the range 128 to 255 are reserved for research or use in Types in the range 128 to 255 are reserved for research or use in
other protocol development and will be administered by IANA (see other protocol development and will be administered by IANA as
Section 9). described in Section 9.
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. See below for the 'address family number'[6] indicated by ar$afn. See below for
more details. more details.
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. When an of the 'address family number'[6] indicated by ar$afn. When an
NBMA technology has no concept of a subaddress, the subaddress NBMA technology has no concept of a subaddress, the subaddress
skipping to change at page 36, line 34 skipping to change at page 36, line 34
exchange other than acting as a forwarding agent. exchange other than acting as a forwarding agent.
The NHRP extension Type space is subdivided to encourage use outside The NHRP extension Type space is subdivided to encourage use outside
the IETF. the IETF.
0x0000 - 0x0FFF Reserved for NHRP. 0x0000 - 0x0FFF Reserved for NHRP.
0x1000 - 0x11FF Allocated to the ATM Forum. 0x1000 - 0x11FF Allocated to the ATM Forum.
0x1200 - 0x37FF Reserved for the IETF. 0x1200 - 0x37FF Reserved for the IETF.
0x3800 - 0x3FFF Experimental use. 0x3800 - 0x3FFF Experimental use.
IANA will administer the ranges reserved for the IETF (see Section IANA will administer the ranges reserved for the IETF as described in
9). Values in the 'Experimental use' range have only local Section 9. Values in the 'Experimental use' range have only local
significance. significance.
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 42, line 29 skipping to change at page 42, line 29
Management protocol. Manual keying MUST be supported. The following Management protocol. Manual keying MUST be supported. The following
parameters are associated with the tuple <SPI, src>- lifetime, parameters are associated with the tuple <SPI, src>- lifetime,
Algorithm, Key. Lifetime indicates the duration in seconds for which Algorithm, Key. Lifetime indicates the duration in seconds for which
the key is valid. In case of manual keying, this duration can be the key is valid. In case of manual keying, this duration can be
infinite. Also, in order to better support manual keying, there may infinite. Also, in order to better support manual keying, there may
be multiple tuples active at the same time (Dst being the same). be multiple tuples active at the same time (Dst being the same).
Algorithm specifies the hash algorithm agreed upon by the two Algorithm specifies the hash algorithm agreed upon by the two
entities. HMAC-MD5-128 [16] is the default algorithm. Other entities. HMAC-MD5-128 [16] is the default algorithm. Other
algorithms MAY be supported by defining new values. IANA will assign algorithms MAY be supported by defining new values. IANA will assign
the numbers to identify the algorithm being used (see Section 9). the numbers to identify the algorithm being used as described in
Section 9.
Any Internet standard key management protocol MAY so be used to Any Internet standard key management protocol MAY so be used to
negotiate the SPI and parameters. negotiate the SPI and parameters.
5.3.4.3 Message Processing 5.3.4.3 Message Processing
At the time of adding the authentication extension header, src looks At the time of adding the authentication extension header, src looks
up in a table to fetch the SPI and the security parameters based on up in a table to fetch the SPI and the security parameters based on
the outgoing interface address. If there are no entries in the table the outgoing interface address. If there are no entries in the table
and if there is support for key management, the src initiates the key and if there is support for key management, the src initiates the key
skipping to change at page 48, line 41 skipping to change at page 48, line 41
one or more regular routers that could act as "connectionless one or more regular routers that could act as "connectionless
servers" for the station. The station could then choose to resolve servers" for the station. The station could then choose to resolve
the NBMA next hop or just send the packets to one of its the NBMA next hop or just send the packets to one of its
connectionless servers. The latter option may be desirable if connectionless servers. The latter option may be desirable if
communication with the destination is short-lived and/or doesn't communication with the destination is short-lived and/or doesn't
require much network resources. The connectionless servers could, of require much network resources. The connectionless servers could, of
course, be physically integrated in the NHSs by augmenting them with course, be physically integrated in the NHSs by augmenting them with
internetwork layer switching functionality. internetwork layer switching functionality.
9. IANA Considerations 9. IANA Considerations
IANA will redirect requests for numbers in the various number spaces
described herein to the working group chairs. Currently, these IANA will take advice from James Luciani (see author information
chairs are Andy Malis (malis@ascend.com) and George Swallow below for contact information), who is the Area Director appointed
(swallow@cisco.com). The working group chair(s) will accept any and designated subject matter expert, in order to assign numbers from the
all requests for value assignment as long as the client/server various number spaces described herein. In the event that the Area
protocol specific document exists (i.e., the protocol specific Director appointed designated subject matter expert is unavailable,
document has been published as an internet draft or informational the relevant IESG Area Director will appoint another expert. Any and
RFC). 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 References
[1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh
Govindan, RFC1735. Govindan, RFC1735.
[2] Address Resolution Protocol, David C. Plummer, RFC 826. [2] Address Resolution Protocol, David C. Plummer, RFC 826.
[3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577.
skipping to change at page 50, line 7 skipping to change at page 50, line 8
[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.
[15] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, [15] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
RFC 2119. RFC 2119.
[16] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare, [16] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare,
Canetti, RFC 2104. Canetti, RFC 2104.
Acknowledgments Acknowledgments
We would like to thank (in no particular order) Naganand Doraswami of We would like to thank (in no particular order) Naganand Doraswamy of
Bay Networks for the entirety of the security section, Thomas Narton Bay Networks for the entirety of the security section, Thomas Narton
of IBM for his comments in the role of Internet AD, Juha Heinenan of 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 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. and the original NHRP draft, which served as the basis for this work.
Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of
ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul
Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco, Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco,
and Grenville Armitage of Bellcore should also be acknowledged for and Grenville Armitage of Bellcore should also be acknowledged for
comments and suggestions that improved this work substantially. We comments and suggestions that improved this work substantially. We
would also like to thank the members of the ION working group of the would also like to thank the members of the ION working group of the
 End of changes. 10 change blocks. 
23 lines changed or deleted 34 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/