Application Statement

[[e-mail]]

Attached is an updated version of the Application Statement
Draft. I thank those who took the time to read it and made
comments. See you in Danvers,

Derya
---------------------------------------------------








ROLC Working Group                                Derya H. Cansever
INTERNET DRAFT                                    GTE Laboratories, Inc.
                                                  March 1995
Expiration Date September 1995




              NHRP Protocol Applicability Statement
               <draft-ietf-rolc-nhrp-appl-01.txt>



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 [3] in its draft form.






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

   NHRP is not a routing protocol, but an inter-LIS address resolution
   protocol. This is further discussed in Section 5.

   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
   NBMA address of the exit router.






   NHRP can be used in host-host and host-router communications. When
   it is used in router-router communication, NHRP can produce persistent 
   routing loops.(At the time this draft is written, efforts to determine
   router-router operation contexts where NHRP can be safely used were
   under way.)

   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 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 within the NBMA network. Loops off the NBMA network cannot be
      detected by this option.
    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 within the NBMA
      network. Loops off the NBMA network cannot be detected by this
      option.
    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 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 staticly 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 does not replace existing routing protocols. In general, routing 
   protocols are used to determine the proper path from a source host or
   router, or intermediate router, to a particular destination. If the
   routing protocol indicates that the proper path is via an interface 
   to an NBMA network, then NHRP may be used at the NBMA interface to 
   allow IP datagrams to traverse the NBMA network in such a way that 
   the particular data forwarding and path determination  mechanisms of 
   the underlying NBMA network are utilized. This implies that, using 
   NHRP, IP datagrams will avoid redundant IP hops in the interior NBMA 
   network and can make use of NBMA network specific features. By the 
   same token, as NHRP is not a routing protocol, in the router-router
   operation mode, it may make decisions based on stale topology 
   information, thereby cause persistant routing loops.






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

   The author acknowledges valuable contributions and comments from 
   many participants of the ROLC Working Group, in particular from 
   Curtis Villamizar, Yakov Rekhter, Joel Halpern and Andy Malis.

Author's Address

   Derya H. Cansever
   GTE Laboratories Inc.
   40 Sylvan Rd. MS 51
   Waltham MA 02254

   Phone: [phone]
   Email: [e-mail]




Expiration Date September 1995