Applicability Statement

[[e-mail]]

Folks,

Attached is a revised draft of the Applicability Statement
for NHRP. I missed the deadline for Internet Drafts.
I called this version draft-ietf-rolc-nhrp-appl-II.txt.
It will become draft-ietf-rolc-nhrp-appl-02.txt when I
submit it to ietf Internet-Drafts.
I will briefly discuss it in Stockholm.

Derya

--------------------------------------------------------








ROLC Working Group                                Derya H. Cansever
INTERNET DRAFT                                    GTE Laboratories, Inc.
                                                  July 1995
Expiration Date January 1996




              NHRP Protocol Applicability Statement
               <draft-ietf-rolc-nhrp-appl-II.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. This feature is also referred to as 
   "cut through" routing. 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 subnetwork layers.

   NHRP is specific to the routing of IP datagrams over large clouds of 
   NBMA networks. In principle, NHRP should also be applicable to network 
   layer protocols other than IP without major modifications in its protocol 
   specification.

3. Key Features

   NHRP is not a routing protocol, but an inter-LIS address resolution
   mechanism that makes use of network layer routing in reaching the 
   destination whose address needs to be resolved. 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, also known as "cut through" routing.
   This feature is discussed in the previous section. NHRP 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 the source 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, in general, NHRP can produce 
   persistent routing loops. This is further discussed in Section 5. 
   A special case of router-router communication where loops will not
   occur is when the destination host is directly adjacent to the non-NBMA
   interface of the egress router. In this case, NHRP Reply may be 
   forwarded with the B bit set on, meaning that the information in
   the reply is believed to be stable for the duration of its holding
   time.
   
   In general, the use of NHRP in a router-router operation tends to 
   supress an existing hierarchical structure within the network of 
   routers. Such a hierarchy might be in place for various reasons, such 
   as load balancing. On the other hand, in an operation mode that 
   involves hosts at either end, "cut through" routing is not likely
   to have a considerable effect on the overall balance of the traffic
   load. In general, unlike a router, a particular host communicates with
   a limited number of stations over a given period of time.

   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, the semantics 
   and the operational details of this option were TBD at the time this 
   report was written.

   NHRP supports two modes of deployment, fabric mode and server mode.
   In the fabric mode, the address resolution is performed via internetwork
   layer routing, unless it is already cashed. In the server mode, address
   resolution is accomplished using the services of a group of address 
   servers wherein the address resolution information is administratively 
   configured. In the latter case, NHRP acts strictly as a look-up table 
   based address resolution protocol. In the fabric mode, after an NHRP 
   request has been sent, the end user has the option of sending the IP 
   datagram whose address needs to be resolved along the routed path 
   created by the NHRP request. This is a recommended mode of operation, 
   in that it reduces the network delay that would be incurred should the 
   NHRP requester choose to hold on to the packet, or to silently discard 
   it until the address has been resolved.

   The option of sending an IP packet along the path created by the 
   corresponding NHRP request raises the question of who should send an 
   NHRP request and, eventually, who should perform "cut-through" 
   routing. In principle, an NHRP request can be triggered in a variety 





   of situations, including the case of a transit router that receives 
   an IP packet with an unknown destination subnetwork address. Letting 
   the transit routers issue NHRP requests would end up with multiple 
   NHRP requests and eventually multiple "cut-through" routes to the same 
   destination. A reasonable operation rule is to authorize one of the 
   following entities, whichever applicable, to issue an NHRP request and 
   to perform "cut-through" routing.
    i) The host that originates the IP packet, if the host has an NBMA
       interface.
    ii) The first router along the routing path of the IP packet such that
        the next hop is reachable through the NBMA interface of that 
        particular router.

   Besides the topological position of the forwarding entity, another 
   criterion for sending an NHRP request and establishing a direct 
   connection is the nature and the requirements of the application. The 
   following discussion is specific to an NBMA technology with QoS choices, 
   such as ATM. The default mode of operation should be hop by hop forwarding, 
   as indicated by IP routing. However, the occurrence of an event may
   trigger the establishment of a "cut-through" connection, such as an ATM
   SVC with a particular QoS guarantee. Examples of events that may trigger
   a direct connection include the occurrence of an RSVP request, or the 
   initiation of an application which is equipped with a locally implemented
   means passing QoS information to the IP or ATM driver.
  

   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

   As previously discussed, NHRP supports server and fabric modes of
   deployment, respectively. The deployment mode has an important impact 
   on the scalability of NHRP.  In either case, stations are to be 
   configured with the IP and MBMA addresses of the 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 
   resolve the destination IP address into the corresponding NBMA address.
   Of course, the use of NHRP is subject to:
    i) The nature and the topological position of the forwarding device,
       e.g., if the forwarding device is a router, then, it should not be
       a transit router. 
    ii) The requirements of the application that IP routing supports. 
   Assuming that NHRP is applicable and the destination address has been
   resolved, packets are forwarded using the particular data forwarding 
   and path determination  mechanisms of the underlying NBMA network.
   Here, the sequence of events are such that route determination is 
   performed by IP routing, independent of NHRP. Then, NHRP is used
   to create a "cut-through" track upon the path determined by the IP 
   routing protocol. The advantage of this approach is that it "shortens" 
   the routed path. The disadvantage is that it is not strongly coupled 
   with the IP routing protocol. If a topological change occurs beyond 
   the boundaries of the NBMA network, then this new information cannot 
   be incorporated into NHRP. In spite of the change in topology, an 
   association between the destination and the "cut-through" track will 
   continue to exist. In the router to router operation, the "cut-through" 
   track representing stale information will be dispersed to other routers 
   in the network. Therefore this situation will introduce the possibility 
   of routing loops. Reference [6] presents further discussion on this 
   issue along with an example of a persistent routing loop.
   


References

   [1] NMBA Next Hop Resolution Protocol (NHRP), Dave Katz
       and David Piscitello, draft-ietf-rolc-nhrp-04.txt.

   [2] TBD

   [3] NHRP Management Information Base, M. Patrick, draft-ietf-rolc
       -nhrp-mib-01.txt

   [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.
   
   [6] IP over ATM: A Framework Document, R.G. Cole, D.H. Shur and 
       C. Villamizar, draft-ietf-ipatm-framework-doc-03.


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 January 1996