ROLC Working Group Derya H. Cansever INTERNET DRAFT GTE Laboratories, Inc. March 1995 Expiration Date September 1995 NHRP Protocol Applicability Statement Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract As required by the Routing Protocol Criteria [RFC 1264], this draft report discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25. The final form of this draft report is a prerequisite to advancing NHRP on the standards track. 1. Protocol Documents The NHRP protocol description is defined in [1] in its draft form. The NHRP protocol analysis is documented in TBD [2] The NHRP MIB description is defined in TBD [3]. 2. Introduction This document summarizes the key features of NHRP and discusses the environments for which the protocol is well suited. For the purposes of description, NHRP can be considered a generalization of Classical IP and ARP over ATM which is defined in [4] and of the Transmission of IP Datagrams over the SMDS Service, defined in [5]. This generalization occurs in 2 distinct directions. Firstly, NHRP avoids the need to go through extra hops of routers when the Source and Destination belong to different Logical Internet Subnets (LIS). Of course, [4] and [5] are defined for stations on an LIS and the respective protocols specify that when the source and destination belong to different LISs, the source station must forward data packets to a router that is a member of multiple LISs, even though the source and destination stations may be on the same logical NBMA network. If the source and destination stations belong to the same logical NBMA network, NHRP provides the source station with an inter-LIS address resolution mechanism at the end of which both stations can exchange packets without having to use the services of intermediate routers. If the destination station is not part of the logical NBMA network, NHRP provides the source with the NBMA address of the egress router towards the destination. The second generalization is that NHRP is not specific to a particular NBMA technology. Of course, [4] assumes an ATM network and [5] assumes an SMDS network at their respective link layers. NHRP focuses on the routing of IP over large clouds of NBMA networks. However, NHRP is applicable to other network layer protocols without major modifications in the NHRP protocol specification. 3. Key Features The most prominent feature of NHRP is that it avoids extra hops in an NBMA with multiple LISs, as discussed in the previous section. It provides the source with the NBMA address of the destination, if the destination is directly attached to the NBMA. If the destination station is not attached to the NBMA, then NHRP provides with the NMBA address of the exit router. As a result of inter-LIS address resolution capability, NHRP allows the communicating parties to establish a means to exchange packets according to the rules of the underlying NBMA network. This, in turn, permits the stations to make use of NBMA specific features. A primary example of an NBMA specific feature is perhaps the Quality of Service (QoS) guarantees when the NBMA is an ATM network. To accommodate this, NHRP has a QoS option where NHRP request packets indicate the desired QoS of the path to the indicated destination. The syntax and the semantics of this option were TBD at the time this report was written. Related to the above feature, stations may choose to utilize NHRP to resolve the NBMA address of the destination and establish an NBMA specific means of communication, e.g., VCs in ATM networks, or utilize the connectionless services of an IP router. This choice is based on the nature of the underlying application. Of course, NHRP and IP routing capabilities may be integrated on the same hardware device. NHRP has also several options which may be very useful for particular classes of applications. The options include: o Destination Mask (IPv4). This option pertains to the case where the destination is associated with an IP Subnet Mask. o NBMA Network ID. This option is used to identify the particular NBMA network that NHRP is associated with. o Responder Address Option (IPv4). This option is useful in detecting loops. o NHRP Forward and Reverse Next Hop Server Record Options (IPv4). These options keep track of NHRP Server addresses. They are used in updating cache tables and in detecting loops. o NHRP Authentication Option. This option is used to enhance the security of the address resolution process. o NHRP Vendor-Private Option. This option is to convey vendor specific information between NHRP entities. 4. Protocol Scalability NHRP supports two modes of deployment, server mode and the fabric mode. The deployment mode has an important impact on the scalability of NHRP. In either case, stations should be configured with the IP and MBMA addresses of the NHRP capable router(s), termed as Next Hop Servers (NHS). Conversely, the NHSs are configured with the IP address prefixes of the stations they serve and they acquire the corresponding NBMA addresses via register packets or manual configuration. Although there are physical bounds such as memory size and processing time, an NHS can in principle serve a "large" number of stations. This is because the size of the lookup table grows linearly in the number of stations and the search operation can be made very efficient by making use of well established methods such as hashing. When NHSs are deployed using the server mode, the number of NHSs in an NBMA is a primary candidate to limit the scalability of NHRP. This is because each NHS should be statically configured to include each others' addresses and the destinations each one serves and possibly other information such as authentication and NMBA identification. Therefore, the addition of an NHS would result in a manual configuration requirement not only in the NHS to be added, but also in all of the existing NHSs of the logical NMBA. In the fabric mode, NHSs find out about other NHSs and the destinations that they serve by means of intra-domain and inter-domain routing protocol exchange. Thus, unlike the server mode of deployment, manual configuration of the information pertaining to other NHSs is not required. In this mode of deployment, NHRP is in the same order of magnitude as the established routing exchange protocols in terms of scalability. It is expected that NHRP will initially be deployed in the server mode. As it becomes widespread, NHRP will transition into the fabric mode. At the time this report is written, it appears that NHRP is moving in a direction of being also adopted in industry forums that pertain to NMBA technologies. Thus, it is reasonable to expect that NHRP will be widely deployed in the fabric mode so that scalability issues will be gracefully resolved. 5. Discussion NHRP is well suited for IP networks where hosts are routers are interconnected via an NBMA network, especially if they are organized in terms of multiple LISs. In a Router-to-Router operation, under certain conditions, a routing loop may occur. It is recommended that during Router-to-Router operation, options that help to detect loops be invoked and NHRP requests be reissued periodically. For the purpose loop prevention, it is advisable avoid the non-NBMA paths between the routers where NHRP is being run. If this option is not practical and the loops persist, then NHRP is not well suited for such environments. References [1] NMBA Next Hop Resolution Protocol (NHRP), Dave Katz and David Piscitello, draft-ietf-rolc-nhrp-03.txt. [2] TBD [3] TBD [4] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. [5] Transmission of IP datagrams over the SMDS service, J. Lawrance and D. Piscitello, RFC 1209. Acknowledgements TBD Author's Address Derya H. Cansever GTE Laboratories Inc. 40 Sylvan Rd. MS 51 Waltham MA 02254 Phone: +1 617 466 4086 Email: dhc2@gte.com Expiration Date September 1995