[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 06 07 08 09 10 11 12 13 14 RFC 2332

Routing over Large Clouds Working Group                        Dave Katz
INTERNET-DRAFT                                           (cisco Systems)
<draft-ietf-rolc-nhrp-06.txt>                           David Piscitello
                                                 (Core Competence, Inc.)
                                                              Bruce Cole
                                                         (cisco Systems)
                                                        James V. Luciani
                                                          (Ascom Nexion)
                                                           November 1995


                NBMA Next Hop Resolution Protocol (NHRP)


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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

Abstract

   This document describes the NBMA Next Hop Resolution Protocol (NHRP).
   NHRP can be used by a source station (host or router) connected to a
   Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the IP and
   NBMA subnetwork addresses of the "NBMA next hop" towards a
   destination station.  If the destination is connected to the NBMA
   subnetwork, then 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 destination station.  Although
   this document focuses on NHRP in the context of IP, the technique is
   applicable to other internetwork layer protocols (e.g., IPX, CLNP,
   Appletalk) as well.

   This document is intended to be a functional superset of the NBMA
   Address Resolution Protocol (NARP) documented in [1].



Katz, Piscitello, Cole, Luciani                                 [Page 1]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   Operation of NHRP as a means of establishing a transit path across an
   NBMA subnetwork between two routers will be addressed in a separate
   document.


1. Introduction

   The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
   (a host or router), wishing to communicate over a Non-Broadcast,
   Multi-Access (NBMA) subnetwork, to determine the IP and NBMA
   addresses of the "NBMA next hop" toward a destination station.  A
   subnetwork can be non-broadcast either because it technically doesn't
   support broadcasting (e.g., an X.25 subnetwork) or because
   broadcasting is not feasible for one reason or another (e.g., an SMDS
   multicast group or an extended Ethernet would be too large).  If the
   destination is connected to the NBMA subnetwork, then 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 destination station.

   An NBMA subnetwork may, in general, consist of multiple logically
   independent IP subnets (LISs), defined in [3] and [4] as having the
   following properties:

      1)  All members of a LIS have the same IP network/subnet number
          and address mask.

      2)  All members within a LIS are directly connected to the same
          NBMA subnetwork.

      3)  All members outside of the LIS are accessed via a router.

   IP routing described in [3] and [4] only resolves the next hop
   address if the destination station is a member of the same LIS as the
   source station; otherwise, the source station must forward packets to
   a router that is a member of multiple LIS's.  In multi-LIS
   configurations, hop-by-hop IP routing may not be sufficient to
   resolve the "NBMA next hop" toward the destination station, and IP
   packets may traverse the NBMA subnetwork more than once.

   NHRP describes a routing method that relaxes the forwarding
   restrictions of the LIS model.  With NHRP, once the NBMA next hop has
   been resolved, the source may either start sending IP packets to the
   destination (in a connectionless NBMA subnetwork such as SMDS) or may
   first establish a connection to the destination with the desired
   bandwidth and QOS characteristics (in a connection-oriented NBMA
   subnetwork such as ATM).




Katz, Piscitello, Cole, Luciani                                 [Page 2]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   NHRP in its most basic form provides a simple IP-to-NBMA-address
   binding service.  This may be sufficient for hosts which are directly
   connected to an NBMA subnetwork, allowing for straightforward
   implementations in NBMA stations.  NHRP also has the capability of
   determining the egress point from an NBMA subnetwork when the
   destination is not directly connected to the NBMA subnetwork and the
   identity of the egress router is not learned by other methods (such
   as routing protocols).  Optional extensions to NHRP provide
   additional robustness and diagnosability.

   Address resolution techniques such as those described in [3] and [4]
   may be in use when NHRP is deployed.  ARP servers and services over
   NBMA subnetworks may be required to support hosts that are not
   capable of dealing with any model for communication other than the
   LIS model, and deployed hosts may not implement NHRP but may continue
   to support ARP variants such as those described in [3] and [4].  NHRP
   is intended to reduce or eliminate the extra router hops required by
   the LIS model, and can be deployed in a non-interfering manner
   alongside existing ARP services.

   The operation of NHRP to establish transit paths across NBMA
   subnetworks between two routers requires additional mechanisms to
   avoid stable routing loops, and will be described in a separate
   document.


2. Overview

2.1 Terminology

   The term "network" is highly overloaded, and is especially confusing
   in the context of NHRP.  We use the following terms:

     Internetwork layer--the media-independent layer (IP in the case of
     TCP/IP networks).

     Subnetwork layer--the media-dependent layer underlying the
     internetwork layer, including the NBMA technology (ATM, X.25, SMDS,
     etc.)


2.2 Protocol Overview

   In this section, we briefly describe how a source S (which
   potentially can be either a router or a host) uses NHRP to determine
   the "NBMA next hop" to destination D.

   For administrative and policy reasons, a physical NBMA subnetwork may



Katz, Piscitello, Cole, Luciani                                 [Page 3]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   be partitioned into several, disjoint "Logical NBMA subnetworks".  A
   Logical NBMA subnetwork is defined as a collection of hosts and
   routers that share unfiltered subnetwork connectivity over an NBMA
   subnetwork.  "Unfiltered subnetwork connectivity" refers to the
   absence of closed user groups, address screening or similar features
   that may be used to prevent direct communication between stations
   connected to the same NBMA subnetwork.  (Hereafter, unless otherwise
   specified, we use the term "NBMA subnetwork" to mean *logical* NBMA
   subnetwork.)

   Placed within the NBMA subnetwork are one or more entities that
   implement the NHRP protocol.  Such stations which are capable of
   answering Next Hop Resolution Requests are known as "Next Hop
   Servers" (NHSs).  Each NHS serves a set of destination hosts, which
   may or may not be directly connected to the NBMA subnetwork.  NHSs
   cooperatively resolve the NBMA next hop within their logical NBMA
   subnetwork.  In addition to NHRP, NHSs may participate in protocols
   used to disseminate routing information across (and beyond the
   boundaries of) the NBMA subnetwork, and may support "classical" ARP
   service as well.

   An NHS maintains a "next-hop resolution" cache, which is a table of
   address mappings (IP-to-NBMA address).  This table can be constructed
   from information gleaned from NHRP Register packets (see Section
   5.2.3 and 5.2.4), extracted from Next Hop Resolution Requests or
   replies that traverse the NHS as they are forwarded, or through
   mechanisms outside the scope of this document (examples of such
   mechanisms include ARP [2, 3, 4] and pre-configured tables).  Section
   6.2 further describes cache management issues.

   A host or router that is not an NHRP server must be configured with
   the identity of the NHS which serves it (see Configuration, Section
   4).

   [Note: for NBMA subnetworks that offer group or multicast addressing
   features, it may be desirable to configure stations with a group
   identity for NHSs, i.e., addressing information that would solicit a
   response from "all NHSs".  The means whereby a group of NHSs divide
   responsibilities for next hop resolution are not described here.]

   Whether or not a particular station within the NBMA subnetwork which
   is making use of the NHRP protocol needs to be able to act as an NHS
   is a local matter.  For a station to avoid providing NHS
   functionality, there must be one or more NHSs within the NBMA
   subnetwork which are providing authoritative NBMA information on its
   behalf.  If NHRP is to be able to resolve the NBMA address for
   stations that lack NHS functionality, these serving NHSs must exist
   along all routed paths between Next Hop Resolution Requesters and the



Katz, Piscitello, Cole, Luciani                                 [Page 4]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   station which cannot answer Next Hop Resolution Requests.

   The protocol proceeds as follows.  An event occurs triggering station
   S to want to resolve the NBMA address of a path to D.  This is most
   likely to be when a data packet addressed to station D is to be
   emitted from station S (either because station S is a host, or
   station S is a transit router), but the address resolution could also
   be triggered by other means (a routing protocol update packet, for
   example).  Station S first determines the next hop to station D
   through normal routing processes (for a host, the next hop may simply
   be the default router; for routers, this is the "next hop" to the
   destination IP address).  If the next hop is reachable through its
   NBMA interface, S constructs an Next Hop Resolution Request packet
   (see Section 5.2.1) containing station D's IP address as the (target)
   destination address, S's own IP address as the source address (Next
   Hop Resolution Request initiator), and station S's NBMA addressing
   information.  Station S may also indicate that it prefers an
   authoritative reply (i.e., station S only wishes to receive a reply
   from the NHS-speaker that maintains the NBMA-to-IP address mapping
   for this destination).  Station S emits the Next Hop Resolution
   Request packet towards the destination, using the NBMA address of the
   next routed hop.

   If the Next Hop Resolution Request is triggered by a data packet,
   station S may choose to dispose of the data packet while awaiting an
   NHRP reply in one of the following ways:

     (a)  Drop the packet
     (b)  Retain the packet until the reply arrives and a more optimal
          path is available
     (c)  Forward the packet along the routed path toward D

   The choice of which of the above to perform is a local policy matter,
   though option (c) is the recommended default, since it may allow data
   to flow to the destination while the NBMA address is being resolved.
   Note that an Next Hop Resolution Request for a given destination MUST
   NOT be triggered on every packet, though periodically retrying a Next
   Hop Resolution Request is permitted.

   When the NHS receives an Next Hop Resolution Request, a check is made
   to see if it "serves" station D, i.e., the NHS checks to see if there
   is a "next hop" entry for D in its next-hop resolution cache.  If the
   NHS does not serve D, the NHS forwards the Next Hop Resolution
   Request to another NHS.  (Mechanisms for determining how to forward
   the Next Hop Resolution Request are discussed in Section 3,
   Deployment.) Note that because NHRP packets are encapsulated with the
   NBMA address of neighboring stations (see encapsulation discussion,
   section 5), NHSs must be next hops to one another in order for



Katz, Piscitello, Cole, Luciani                                 [Page 5]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   forwarding of these packets to be possible.

   If this NHS serves D, the NHS resolves station D's NBMA address, and
   generates a positive NHRP reply on D's behalf.  (NHRP replies in this
   scenario are always marked as "authoritative".)  The NHRP reply
   packet contains the next hop IP and NBMA address for station D and is
   sent back to S.  (Note that if station D is not on the NBMA
   subnetwork, the next hop IP address will be that of the egress router
   through which packets for station D are forwarded.)

   An NHS receiving an NHRP reply may cache the NBMA next hop
   information contained therein.  To a subsequent Next Hop Resolution
   Request, this NHS may respond with the cached, non-authoritative,
   NBMA next hop information or with cached negative information, if the
   NHS is allowed to do so, see section 6.2.  Non-authoritative NHRP
   replies are distinguished from authoritative replies so that if a
   communication attempt based on non-authoritative information fails, a
   source station can choose to send an authoritative Next Hop
   Resolution Request.  NHSs MUST NOT respond to authoritative Next Hop
   Resolution Requests with cached information.

     [Note: An NHRP reply can be returned directly to the Next Hop
     Resolution Request initiator, i.e., without traversing the list of
     NHSs that forwarded the request, if all 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 Next Hop Resolution Request initiator or is permitted
           to open one.
       (b) The Next Hop Resolution Request initiator has not included the NHRP
           Reverse NHS record Extension (see Section 5.3.5).
       (c) The authentication policy in force permits direct
           communication between the NHS and the Next Hop Resolution Request
           initiator.

     The purpose of allowing an NHS to reply directly is to reduce
     response time.  A consequence of allowing a direct reply is that
     NHSs that would under normal circumstances be traversed by the
     reply would not cache next hop information contained therein.]

   The process of forwarding the Next Hop Resolution Request is repeated
   until the request is satisfied, or an error occurs (e.g., no NHS in
   the NBMA subnetwork can resolve the request.) If the determination is
   made that station D's next hop cannot be resolved, a negative reply
   is returned.  This occurs when (a) no next-hop resolution information
   is available for station D from any NHS, or (b) an NHS is unable to
   forward the Next Hop Resolution Request (e.g., connectivity is lost).



Katz, Piscitello, Cole, Luciani                                 [Page 6]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   Next Hop Resolution Requests and replies MUST NOT cross the borders
   of a logical NBMA subnetwork (an explicit NBMA subnetwork identifier
   may be included as an extension in the Next Hop Resolution Request,
   see section 5.3.2).  Thus, IP traffic out of and into a logical NBMA
   subnetwork always traverses an IP router at its border.  Internetwork
   layer filtering can then be implemented at these border routers.

   NHRP optionally provides a mechanism to reply with aggregated NBMA
   next hop information.  Suppose that router X is the NBMA next hop
   from station S to station D.  Suppose further that X is an egress
   router for all stations sharing an IP address prefix with station D.
   When an NHRP reply is generated in response to a request, the
   responder may augment the IP address of station D with a mask
   defining this prefix (see Section 5.3.1).  A subsequent (non-
   authoritative) Next Hop Resolution Request for some destination that
   shares an IP address prefix with D may be satisfied with this cached
   information.  See section 6.2 regarding caching issues.

   To dynamically detect subnetwork-layer filtering in NBMA subnetworks
   (e.g., X.25 closed user group facility, or SMDS address screens), as
   well as to provide loop detection and diagnostic capabilities, NHRP
   optionally incorporates a "Route Record" in requests and replies (see
   Sections 5.3.4 and 5.3.5).  The Route Record extensions contain the
   internetwork (and subnetwork layer) addresses of all intermediate
   NHSs between source and destination (in the forward direction) and
   between destination and source (in the reverse direction).  When a
   source station is unable to communicate with the responder (e.g., an
   attempt to open an SVC fails), it may attempt to do so successively
   with other subnetwork layer addresses in the Route Record until it
   succeeds (if authentication policy permits such action).  This
   approach can find a suitable egress point in the presence of
   subnetwork-layer filtering (which may be source/destination
   sensitive, for instance, without necessarily creating separate
   logical NBMA subnetworks) or subnetwork-layer congestion (especially
   in connection-oriented media).

   NHRP messages, with the exception of Purge packets, are sent using a
   best effort delivery service.  Next Hop Resolution Requests should be
   retransmitted periodically until either a Reply or an Error packet is
   received.



3. Deployment

   Next Hop Resolution Requests traverse one or more hops within an NBMA
   subnetwork before reaching the station that is expected to generate a
   response.  Each station, including the source station, chooses a



Katz, Piscitello, Cole, Luciani                                 [Page 7]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   neighboring NHS to forward the request on to.  The NHS selection
   procedure typically involves performing a routing decision based upon
   the network layer destination address of the Next Hop Resolution
   Request.  Ignoring error situations, the Next Hop Resolution Request
   eventually arrives at a station that is to generate an NHRP reply.
   This responding station either serves the destination, or is the
   destination itself if both NHRP client and server functionality are
   co-resident in the same station.  The responding station generates a
   reply using the source address from within the NHRP packet to
   determine where the reply should be sent.

   The Next Hop Resolution Request packet is carried at the NBMA layer,
   with a destination NBMA address set to that of the locally determined
   NHS.  If the addressed NHS does not serve the destination address
   specified in the Next Hop Resolution Request, the request packet is
   routed at the network layer based upon the request's destination
   address, and forwarded to the neighboring NHS determined by the
   routing decision.  Alternately, the NHS may use static configuration
   information in order to determine which neighboring NHSs to forward
   the request packet to.  Each NHS/router examines the NHRP request
   packet on its way toward the destination, optionally modifying it on
   the way (such as updating the Forward Record extension), and
   continues to forward it until it reaches the NHS that serves the
   destination network layer address.

   In order to forward NHRP packets to a neighboring NHS, NHRP clients
   must nominally be configured with the NBMA address of at least one
   NHS.  In practice, a client's default router should also be its NHS.
   A client may be able to derive the NBMA address of its NHS from the
   configuration that was already required for the client to be able to
   communicate with its next hop router.

   Forwarding of NHRP packets within an NBMA subnetwork requires a
   contiguous deployment of NHRP capable stations.  During migration to
   NHRP, it cannot be expected that all stations within the NBMA
   subnetwork are NHRP capable.  NHRP traffic which would otherwise need
   to be forwarded through such stations can be expected to be dropped
   due to the NHRP packet being unrecognized.  In this case, NHRP will
   be unable to establish any transit paths whose discovery requires the
   traversal of the non-NHRP speaking stations.  In such a scenario,
   NHRP is still able to provide basic address resolution functionality
   between stations which do support NHRP.

   The path taken by Next Hop Resolution Requests will normally be the
   same as the path taken by data packets which are routed at the
   network layer to the desired destination.  (The paths may be
   different in situations where NHSs have been statically configured to
   forward traffic by other means.  For example, an Next Hop Resolution



Katz, Piscitello, Cole, Luciani                                 [Page 8]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   Request may be forwarded to a group multicast address.)

   NHSs should acquire knowledge about destinations other NHSs serve as
   a direct consequence of participating in intradomain and interdomain
   routing protocol exchange.  In this case, the NHS serving a
   particular destination must lie along the routed path to that
   destination.  In practice, this means that all egress routers must
   double as NHSs serving the destinations beyond them, and that hosts
   on the NBMA subnetwork are served by routers that double as NHSs.

   NHSs (and end stations) may alternately be statically configured with
   the NBMA addresses of their neighbors, the identities of the
   destinations that each of them serves, and optionally a logical NBMA
   subnetwork identifier.  Such static configurations may be necessary
   in cases where NHSs do not contain network layer routing protocol
   implementations.

   If the NBMA subnetwork offers a group addressing or multicast
   feature, the client (station) may be configured with a group address
   assigned to the group of next-hop servers.  The client might then
   submit Next Hop Resolution Requests to the group address, eliciting a
   response from one or more NHSs, depending on the response strategy
   selected.  Note that the constraints described in Section 2 regarding
   direct replies may apply.

   NHSs may also be deployed with the group or multicast address of
   their peers, and an NHS might use this as a means of forwarding Next
   Hop Resolution Requests it cannot satisfy to its peers.  This might
   elicit a response (to the NHS) from one or more NHSs, depending on
   the response strategy.  The NHS would then forward the NHRP reply to
   the Next Hop Resolution Request originator.  The purpose of using
   group addressing or a similar multicast mechanism in this scenario
   would be to eliminate the need to preconfigure each NHS in a logical
   NBMA subnetwork with both the individual identities of other NHSs as
   well as the destinations they serve.  It reduces the number of NHSs
   that might be traversed to process an Next Hop Resolution Request (in
   those configurations where NHSs either respond or forward via the
   multicast, only two NHSs would be traversed), and allows the NHS that
   serves the Next Hop Resolution Request originator to cache next hop
   information associated with the reply (again, within the constraints
   described in Section 2).

4. Configuration

   Stations

     To participate in NHRP, a station connected to an NBMA subnetwork
     should be configured with the NBMA address(es) of its NHS(s)



Katz, Piscitello, Cole, Luciani                                 [Page 9]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


     (alternatively, it should be configured with a means of acquiring
     them, i.e., the group address that members of a NHS group use for
     the purpose of address or next-hop resolution.)  The NHS(s) will
     likely also represent the stations's default or peer routers, so
     their NBMA addresses may be obtained from the station's existing
     configuration.  If the station is attached to several subnetworks
     (including logical NBMA subnetworks), the station should also be
     configured to receive routing information from its NHS(s) and peer
     routers so that it can determine which IP networks are reachable
     through which subnetworks.


   Next Hop Servers

     An NHS is configured with knowledge of its own IP and NBMA
     addresses, a set of IP address prefixes that correspond to the IP
     addresses of the stations it serves, and a logical NBMA subnetwork
     identifier (see Section 5.3.2).  If a served station is attached to
     several subnetworks, the NHS may also need to be configured to
     advertise routing information to such stations.

     If an NHS acts as an egress router for stations connected to other
     subnetworks than the NBMA subnetwork, the NHS must, in addition to
     the above, be configured to exchange routing information between
     the NBMA subnetwork and these other subnetworks.

     In all cases, routing information is exchanged using conventional
     intra-domain and/or inter-domain routing protocols.

     The NBMA addresses of the stations served by the NHS may be learned
     via NHRP Register packets or manual configuration.

5. NHRP Packet Formats
   This section describes the format of NHRP packets.

   An NHRP packet consists of a Fixed Part, a Mandatory Part, and an
   Extensions Part.  The Fixed Part is common to all NHRP packet types.
   The Mandatory Part MUST be present, but varies depending on packet
   type.  The Extensions Part also varies depending on packet type, and
   need not be present.

   The length of the Fixed Part is fixed at 20 octets.  The length of
   the Mandatory Part is determined by the contents of the extensions
   offset field (ar$extoff).  If ar$extoff=0x0 then the mandatory part
   length is equal to total packet length (ar$pktsz) minus 20 otherwise
   the mandatory part lenth is equal to ar$extoff minus 20.  The length
   of the Extensions Part is implied by ar$pktsz minus ar$extoff minus
   20.  NHSs may increase the size of an NHRP packet as a result of



Katz, Piscitello, Cole, Luciani                                [Page 10]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   extension processing, but not beyond the offered maximum SDU size of
   the NBMA network.

   NHRP packets are encapsulated using the native formats used on the
   particular NBMA network over which NHRP is carried.  For example,
   SMDS networks always use LLC/SNAP encapsulation at the NBMA layer,
   and an NHRP packet is preceded by the following LLC/SNAP
   encapsulation:

   [0xAA-AA-03] [0x00-00-5E] [0x00-03]

   The first three octets are LLC, indicating that SNAP follows.  The
   SNAP OUI portion is the IANA's OUI, and the SNAP PID portion
   identifies NHRP (see [4]).

   ATM uses either LLC/SNAP encapsulation of each packet (including
   NHRP), or uses no encapsulation on VCs dedicated to a single protocol
   (see [7]).  Frame Relay and X.25 both use NLPID/SNAP encapsulation or
   identification of NHRP, using a NLPID of 0x0080 and the same SNAP
   contents as above (see [8], [9]).

   Fields marked "unused" MUST be set to zero on transmission, and
   ignored on receipt.

   Most packet types (ar$op.type) have both internetwork layer
   protocol-independent fields and protocol-specific fields. The
   protocol-independent fields always come first in the packet, and the
   protocol type/snap fields (ar$pro.type/snap) qualify the format of
   the protocol-specific fields.


5.1 NHRP Fixed Header

   The Fixed Part of the NHRP packet contains those elements of the NHRP
   packet which are always present and do not vary in size with the type
   of packet.















Katz, Piscitello, Cole, Luciani                                [Page 11]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996



          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            ar$hrd             |          ar$pro.type          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                          ar$pro.snap                          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  ar$pro.snap  |   ar$hopcnt   |            ar$pktsz           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           ar$chksum           |            ar$extoff          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | ar$op.version |   ar$op.type  |    ar$shtl    |    ar$sstl    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   ar$hrd
     Defines the type of "link layer" addresses being carried.  This
     number is taken from the number hardware type from the list in [6].

***The use of the number hardware type or of the address family number
is still an open issue.

   ar$pro.type
     field is a 16 bit unsigned integer representing the following
     number space:

       0x0000 to 0x00FF  Protocols defined by the equivalent NPLIDs.
       0x0100 to 0x03FF  Reserved for future use by the IETF.
       0x0400 to 0x04FF  Allocated for use by the ATM Forum.
       0x0500 to 0x05FF  Experimental/Local use.
       0x0600 to 0xFFFF  Protocols defined by the equivalent Ethertypes.

     (based on the observations that valid Ethertypes are never smaller
     than 0x600, and NPLIDs never larger than 0xFF.)

   ar$pro.snap
     When ar$pro.type has a value of 0x0080, a SNAP encoded extension is
     being used to encode the protocol type. This snap extension is
     placed in the ar$pro.snap field.  This is termed the 'long form'
     protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be
     zero on transmit and ignored on receive. The ar$pro.type field
     itself identifies the protocol being referred to. This is termed
     the 'short form' protocol ID.

     In all cases, where a protocol has an assigned number in the
     ar$pro.type space (excluding 0x0080) the short form MUST be used
     when transmitting NHRP messages. Additionally, where a protocol has



Katz, Piscitello, Cole, Luciani                                [Page 12]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


     valid short and long forms of identification, receivers MAY choose
     to recognise the long form.

   ar$hopcnt
     The Hop count indicates the maximum number of NHSs that an NHRP
     packet is allowed to traverse before being discarded.

   ar$pktsz
     The total length of the NHRP packet, in octets (exluding link layer
     encapsulation).

   ar$chksum
     The standard IP checksum over the entire NHRP packet (starting with
     the fixed header).  If only the hop count field is changed, the
     checksum is adjusted without full recomputation.  The checksum is
     completely recomputed when other header fields are changed.

   ar$extoff
     This field identifies the existence and location NHRP extensions.
     If this field is 0 then no extensions exist otherwise this field
     represents the offset from the beginning of the NHRP packet (i.e.,
     starting from the ar$afn field) of the first extension.

   ar$op.version
     This field is set to 0x0001 for NHRP version 1.

   ar$op.type
     This is the NHRP packet type (request, reply, purge, or error).

   ar$shtl
     Type & length of source NBMA address interpreted in the context of
     the 'hardware' (NBMA media) indicated by ar$afn (e.g.,
     ar$afn=0x0003 for ATM).

   ar$sstl
     Type & length of source NBMA subaddress interpreted in the context
     of the 'hardware' (NBMA media) indicated by ar$afn (e.g.,
     ar$afn=0x0003 for ATM).  When an NBMA technology has no concept of
     a subaddress the subaddress is always null and ar$sstl = 0 and no
     storage is allocated for the address in the appropriate mandatory
     part.

   The ar$shtl and ar$sstl fields are coded as follows:








Katz, Piscitello, Cole, Luciani                                [Page 13]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


                7 6 5 4 3 2 1 0
               +-+-+-+-+-+-+-+-+
               |0|x|  length   |
               +-+-+-+-+-+-+-+-+

   The most significant bit is reserved and MUST be set to zero. The
   second most significant bit (x) is a flag indicating whether the NBMA
   address being referred to is in:

      - NSAP format (x = 0).
      - Native E.164 format (x = 1).

   For NBMA technologies that use neither NSAP nor E.164 format
   addresses, x = 0 SHALL be used to indicate the native form for the
   particular NBMA technology.

   The bottom 6 bits is an unsigned integer value indicating the length
   of the associated NBMA address in octets. If this value is zero the
   flag x is ignored.


5.2 Mandatory Part

   The Mandatory Part of the NHRP packet contains the operation specific
   information (e.g., Next Hop Resolution request/reply, etc.) and
   variable length data which is pertinent to the packet type.

5.2.1 Next Hop Resolution Request

   The Next Hop Resolution Request packet has a Type code of 1. The
   Mandatory Part has the following format:




















Katz, Piscitello, Cole, Luciani                                [Page 14]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         Request ID                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |Q|A|P|B| Unused| Proto Length |  Source Address Holding Time   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                            unused                             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Source NBMA Address (variable length)               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Source NBMA Subaddress (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Source Protocol Address (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |      Destination  Protocol Address (variable length)          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Request ID
     A value which, when coupled with the address of the source,
     provides a unique identifier for the information contained in a
     Request and its associated Next Hop Resolution Reply, and any
     subsequent Purge.  This  value can be used by the source to aid in
     matching requests with replies.  This value could also be sent
     across a virtual circuit (in SVC environments) to aid in matching
     NHRP transactions with virtual circuits (this use is for further
     study).

     The value is taken from a 32 bit counter that is incremented each
     time a new NHRP request is transmitted.  The same value MUST be
     used when sending another request for the same destination when a
     previous request is still active or pending, i.e., when
     retransmitting a Next Hop Resolution Request because a Next Hop
     Resolution Reply was not received, or when refreshing an existing
     entry to avoid holding timer expiration.  A new value MUST be used
     when sending a request when no cache entry is present, or a
     previous cache entry was deleted for any reason.

   Next Hop Resolution Request Flags

     Q
       Set if the requester is a router;  clear if the requester is a
       host.

     A
       A response to an NHRP request may contain cached information. If
       an authoritative answer is desired, then this bit
       ("Authoritative") should be set.  If non-authoritative (cached)



Katz, Piscitello, Cole, Luciani                                [Page 15]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


       information is acceptable, this bit should be clear.

     P
       Unused (clear on transmit)

     B
       Unused (clear on transmit)

   Proto Length
     The length in octets, of the internetwork layer protocol addresses
     appearing in this packet.  If this length is not a multiple of 4,
     each internetwork layer address is zero-filled to the nearest 32-
     bit boundary.

   Source Address Holding Time
     The Source Address Holding Time field specifies the number of
     seconds for which the source NBMA information is considered to be
     valid.  Cached information SHALL be discarded when the holding time
     expires.

   Source NBMA Address
     The Source NBMA address field is the address of the source station
     which initiated the request.  It is zero-filled to the nearest 32-
     bit boundary. However, if its length as specified in ar$shtl is 0
     then no storage is allocated for this address at all.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the address of the source
     station which initiated the request.  It is zero-filled to the
     nearest 32- bit boundary. However, if its length as specified in
     ar$sstl is 0 then no storage is allocated for this address at all.

   Source Protocol Addresses
     This is the protocol address of the station which initially issued
     an NHRP Request packet.

   Destination Protocol Address
     This is the protocol address of the station for which the NBMA next
     hop is desired.

   (The NBMA address/subaddress form allows combined E.164/NSAPA form of
   NBMA addressing. For NBMA technologies without a subaddress concept,
   the subaddress field is always ZERO length and ar$sstl = 0.)

5.2.2 NHRP Next Hop Resolution Reply

   The NHRP Next Hop Resolution Reply packet has a type code of 2.  The
   Mandatory Part has the following format:



Katz, Piscitello, Cole, Luciani                                [Page 16]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         Request ID                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |Q|A|P|B| Unused| Proto Length |  Next Hop Holding Time         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  NH Addr T/L   | NH SAddr T/L |   Preference  |   unused      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source NBMA Subaddress (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination  Protocol Address (variable length)         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop Protocol Address (variable length)           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Next Hop NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Request ID
     A value which, when coupled with the address of the source,
     provides a unique identifier for the information contained in a
     Request and its associated Next Hop Resolution Reply, and any
     subsequent Purge.  This value can be used by the source to aid in
     matching requests with replies.  This value could also be sent
     across a virtual circuit (in SVC environments) to aid in matching
     NHRP transactions with virtual circuits (this use is for further
     study).

     The value is taken from a 32 bit counter that is incremented each
     time a new NHRP request is transmitted.  The same value MUST be
     used when sending another request for the same destination when a
     previous request is still active or pending, i.e., when
     retransmitting a Next Hop Resolution Request because a Next Hop
     Resolution Reply was not received, or when refreshing an existing
     entry to avoid holding timer expiration.  A new value MUST be used
     when sending a request when no cache entry is present, or a
     previous cache entry was deleted for any reason.

   Next Hop Resolution Request Flags

     Q
       Copied from the Next Hop Resolution Request.  Set if the



Katz, Piscitello, Cole, Luciani                                [Page 17]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


       Requester is a router;  clear if the requester is a host.

     A
       Set if the next hop in the Next Hop Resolution Reply is
       authoritative; clear if the Next Hop Resolution Reply is non-
       authoritative.

     P
       Set if the Next Hop Resolution Reply is positive;  clear if the
       Next Hop Resolution Reply is negative.

     B
       Set if the association between the destination and the next hop
       information is guaranteed to be stable for the lifetime of the
       information (the holding time).  This is the case if the Next Hop
       protocol address identifies the destination (though it may be
       different in value than the Destination address if the
       destination system has multiple addresses) or if the destination
       is not connected directly to the NBMA subnetwork but the egress
       router to that destination is guaranteed to be stable (such as
       when the destination is immediately adjacent to the egress router
       through a non-NBMA interface).  This information affects cacheing
       strategies (see section 6.2).

       An NHS is not allowed to reply to an Next Hop Resolution Request
       for authoritative information with cached information, but may do
       so for an NHRP Next Hop Resolution Request which indicates a
       request for non-authoritative information. An NHS may reply to an
       Next Hop Resolution Request for non-authoritative information
       with authoritative information.

   Proto Length
     The length in octets, of the internetwork layer protocol addresses
     appearing in this packet.  If this length is not a multiple of 4,
     each internetwork layer address is zero-filled to the nearest 32-
     bit boundary.


   Next Hop Address Holding Time
     The Next Hop Address Holding Time field specifies the number of
     seconds for which the next hop NBMA information is considered to be
     valid.  Cached information SHALL be discarded when the holding time
     expires.  Must be set to 0 on a NAK.

   NH Addr T/L
     Type & length of next hop NBMA address interpreted in the context
     of the 'hardware' (NBMA media) indicated by ar$afn (e.g.,
     ar$afn=0x0003 for ATM).  When the address length is specified as 0



Katz, Piscitello, Cole, Luciani                                [Page 18]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


     no storage is allocated for the address. Set to 0 on a NAK.

   NH SAddr T/L
     Type & length of next hop NBMA subaddress interpreted in the
     context of the 'hardware' (NBMA media) indicated by ar$afn (e.g.,
     ar$afn=0x0003 for ATM).  When an NBMA technology has no concept of
     a subaddress the subaddress is always null with a length of 0.
     When the address length is specified as 0 no storage is allocated
     for the address. Set to 0 on a NAK.

   Preference
     This field specifies the preference of the Next Hop entry, relative
     to other Next Hop entries in this NHRP Next Hop Resolution Reply
     packet which may be in the Additional Next Hop Entries Extension
     for the given internetworking protocol.  Higher values indicate
     more preferable Next Hop entries.  Action taken when multiple next
     hop entries have the highest preference value is a local matter.
     Set to 0 on a NAK.

   Source NBMA Address
     The Source NBMA address field is the address of the source station
     which initiated the request.  It is zero-filled to the nearest 32-
     bit boundary. However, if its length as specified in ar$shtl is 0
     then no storage is allocated for this address at all.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the address of the source
     station which initiated the request.  It is zero-filled to the
     nearest 32- bit boundary. However, if its length as specified in
     ar$sstl is 0 then no storage is allocated for this address at all.

   Source Protocol Addresses
     This is the protocol address of the station which initially issued
     an NHRP Request packet.

   Destination Protocol Address
     This is the protocol address of the station for which the NBMA next
     hop is desired.

     (The NBMA address/subaddress form allows combined E.164/NSAPA form
     of NBMA addressing. For NBMA technologies without a subaddress
     concept, the subaddress field is always ZERO length and ar$sstl =
     0.)

   Next Hop entry

     Next Hop Protocol Address
       This internetworkin layer address specifies the next hop.  This



Katz, Piscitello, Cole, Luciani                                [Page 19]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


       will be the address of the destination host if it is directly
       attached to the NBMA subnetwork, or the egress router if it is
       not directly attached.

     Next Hop NBMA Address
       This is the NBMA address of the station that is the next hop for
       packets bound for the internetworking layer address specified.
       The NBMA address field itself is zero-filled to the nearest 32-
       bit boundary.

     Next Hop NBMA SubAddress
       This is the NBMA sub address of the station that is the next hop
       for packets bound for the internetworking layer address
       specified.  The NBMA subaddress field itself is zero-filled to
       the nearest 32-bit boundary.

   There may be multiple Next Hop entries returned in the Next Hop
   Resolution Reply by including the Additional Next Hop Entries
   Extension.  See Section 5.3.9 for use of these entries.  The most
   preferable Next Hop must be specified in the mandatory part of the
   Next Hop Resolution Reply.

   Any extensions present in the Next Hop Resolution Request packet MUST
   be present in the NHRP Next Hop Resolution Reply packet, except for
   the case of unrecognized non-Compulsory extensions.

   If an unsolicited NHRP Next Hop Resolution Reply packet is received,
   an Error Indication of type Invalid Next Hop Resolution Reply
   Received SHOULD be sent in response.


5.2.3 NHRP Registration Request

   The NHRP Registration Request is sent from a station to an NHS to
   notify the NHS of the station's NBMA information.  It has a Type code
   of 3. The Mandatory Part has the following format:















Katz, Piscitello, Cole, Luciani                                [Page 20]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         Request ID                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Unused     | Proto Length |    Register Holding Time      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                            unused                             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source NBMA Subaddress (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination  Protocol Address (variable length)         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Request ID
     A value which, when coupled with the address of the source,
     provides a unique identifier for the information contained in a
     Registration Request packet.  This value is copied directly from a
     Registration Request packet into the associated Registration Reply.
     This value could also be sent across a virtual circuit (in SVC
     environments) to aid in matching NHRP transactions with virtual
     circuits (this use is for further study).


   Proto Length
     The length in octets, of the internetwork layer protocol addresses
     appearing in this packet.  If this length is not a multiple of 4,
     each internetwork layer address is zero-filled to the nearest 32-
     bit boundary.

   Source Protocol Address
     The Protocol Address of the station wishing to register its NBMA
     address with an NHS.

   Register Holding Time
     The Register Holding Time field specifies the number of seconds for
     which the registered NBMA information is considered to be valid.
     Cached information SHALL be discarded when the holding time
     expires.

   Source NBMA Address
     The Source NBMA address field is the address of the source station
     which initiated the request.  It is zero-filled to the nearest 32-



Katz, Piscitello, Cole, Luciani                                [Page 21]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


     bit boundary. However, if its length as specified in ar$shtl is 0
     then no storage is allocated for this address at all.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the address of the source
     station which initiated the request.  It is zero-filled to the
     nearest 32- bit boundary. However, if its length as specified in
     ar$sstl is 0 then no storage is allocated for this address at all.

   Source Protocol Addresses
     This is the protocol address of the station which initially issued
     an NHRP Request packet.

   Destination Protocol Address
     This is the protocol address of the NHS for which the source NBMA
     next hop information is being reistered

   This packet is used to register a station's Protocol and NBMA
   addresses with its NHSs, as configured or known through conventional
   routing means.  This allows static configuration information to be
   reduced;  the NHSs need not be configured with the identities of all
   of the stations that they serve.

   It is possible that a misconfigured station will attempt to register
   with the wrong NHS (i.e., one that cannot serve it due to policy
   constraints or routing state).  If this is the case, the NHS MUST
   reply with a NAK-ed Registration Reply of type Can't Serve This
   Address.

   If an NHS cannot serve a station due to a lack of resources, the NHS
   MUST reply with a NAK-ed Registration Reply of type Registration
   Overflow.

   In order to keep the registration entry from being discarded, the
   station MUST resend the NHRP Registration Request packet often enough
   to refresh the registration, even in the face of occasional packet
   loss. It is recommended that the Registration Request packet be sent
   at an interval equal to one-third of the Holding Time specified
   therein.


5.2.4 NHRP Registration Reply

   The NHRP Registration Reply is sent by an NHS to a client in response
   to that client's Registration Request. If the NAK Code field has
   anything other than 0 zero in it then the Registration Reply is a NAK
   otherwise the reply is an ACK.  The Registration Reply has a Type
   code of 4.  Its mandatory part has the following format:



Katz, Piscitello, Cole, Luciani                                [Page 22]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         Request ID                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   NAK Code    |  Proto Length |    Register Holding Time      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                            unused                             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source NBMA Subaddress (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination  Protocol Address (variable length)         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Request ID
     A value which, when coupled with the address of the source,
     provides a unique identifier for the information contained in a
     Registration Request packet.  This value is copied directly from a
     Registration Request packet into the associated Registration Reply.
     This value could also be sent across a virtual circuit (in SVC
     environments) to aid in matching NHRP transactions with virtual
     circuits (this use is for further study).

   NAK Code
     If this field is set to zero then this packet contains a
     Registration Request Acknowledgement.  If this field contains any
     other value then this contains a Registration Request NAK.
     Currently defined NAK Codes are as follows:

       4 - Can't Serve This Address

         An NHS may refuse an NHRP registration attempt for
         administrative reasons.  If so, the NHS MUST reply with this
         NAK in the Registration Reply which contains a NAK code of 4.

       5 - Registration Overflow

         If an NHS cannot serve a station due to a lack of resources,
         the NHS MUST reply with a NAKed Registration Reply which
         contains a NAK code of 5.

   Proto Length
     The length in octets, of the internetwork layer protocol addresses



Katz, Piscitello, Cole, Luciani                                [Page 23]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


     appearing in this packet.  If this length is not a multiple of 4,
     each internetwork layer address is zero-filled to the nearest 32-
     bit boundary.

   Source Protocol Address
     The Protocol Address of the client that sent a Registration
     Request.

   Register Holding Time
     The Register Holding Time field specifies the number of seconds for
     which the registered NBMA information is considered to be valid.
     Cached information SHALL be discarded when the holding time
     expires.

   Source NBMA Address
     The Source NBMA address field is the address of the source station
     which initiated the request.  It is zero-filled to the nearest 32-
     bit boundary. However, if its length as specified in ar$shtl is 0
     then no storage is allocated for this address at all.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the subaddress of the source
     station which initiated the request.  It is zero-filled to the
     nearest 32-bit boundary. However, if its length as specified in
     ar$sstl is 0 then no storage is allocated for this address at all.

   Source Protocol Addresses
     This is the protocol address of the station which initially issued
     an NHRP request packet.

   Destination Protocol Address
     This is the protocol address of the station for which the NBMA next
     hop is desired.

   This packet is used to register a station's Protocol and NBMA
   addresses with its neighboring NHSs, as configured or known through
   conventional routing means.  This allows static configuration
   information to be reduced;  the NHSs need not be configured with the
   identities of all of the stations that they serve.

   It is possible that a misconfigured station will attempt to register
   with the wrong NHS (i.e., one that cannot serve it due to policy
   constraints or routing state).  If this is the case, the NHS MUST
   reply with a NAK-ed Registration Reply of type Can't Serve This
   Address.

   If an NHS cannot serve a station due to a lack of resources, the NHS
   MUST reply with a NAK-ed Registration Reply of type Registration



Katz, Piscitello, Cole, Luciani                                [Page 24]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   Overflow.

   In order to keep the registration entry from being discarded, the
   station MUST resend the NHRP Registration Request packet often enough
   to refresh the registration, even in the face of occasional packet
   loss. It is recommended that the Registration Request packet be sent
   at an interval equal to one-third of the Holding Time specified
   therein.

5.2.5 NHRP Purge

   The NHRP Purge packet has a type code of 5.  The Mandatory Part has
   the following format:


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                            unused                             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |A|    Unused    | Proto Length |          unused               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                            unused                             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source NBMA Subaddress (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination  Protocol Address (variable length)         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Target Protocol Address (variable length)           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A
     Clear if this is a purge request, set if this is an acknowledgment.

   Proto Length
     The length in octets, of the internetwork layer protocol addresses
     appearing in this packet.  If this length is not a multiple of 4,
     each internetwork layer address is zero-filled to the nearest 32-
     bit boundary.

   Source NBMA Address
     The Source NBMA address field is the address of the source station
     which initiated the Purge.  It is zero-filled to the nearest 32-
     bit boundary. However, if its length as specified in ar$shtl is 0



Katz, Piscitello, Cole, Luciani                                [Page 25]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


     then no storage is allocated for this address at all.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the address of the source
     station which initiated the Purge.  It is zero-filled to the
     nearest 32- bit boundary. However, if its length as specified in
     ar$sstl is 0 then no storage is allocated for this address at all.

   Source Protocol Address
     The address of the station which is sending the purge notification.

   Destination Protocol Address
     The address of the station that will be receiving the purge
     notification.

   Target Protocol Address
     The address which is to be purged from the receiver's database.

   An NHRP Purge request packet is sent from an NHS to a station to
   cause it to delete previously cached information.  This is done when
   the information may be no longer valid (typically when the NHS has
   previously provided next hop information for a station that is not
   directly connected to the NBMA subnetwork, and the egress point to
   that station may have changed).

   An NHRP Purge request packet may also be sent from a client to an NHS
   with which the client had previously sent a registration packet to.
   This allows for a client to invalidate an NHRP registration before it
   would otherwise expire.

   The station sending the NHRP Purge request MUST periodically
   retransmit the request until it is acknowledged, or until the holding
   time of the information being purged has expired.  Retransmission
   strategies are for further investigation.

   When a station receives an NHRP Purge request, it MUST discard any
   previous cached information that matches the Target Protocol Address.

   An acknowledgment MUST be returned for the Purge request even if the
   station does not have a matching cache entry.  The acknowledgment is
   constructed by setting the Acknowledgment (A) bit and returning the
   Purge request to the Source Protocol Address.

   If the station wishes to reestablish communication with the
   destination shortly after receiving a Purge request, it should make
   an authoritative request in order to avoid any stale cache entries
   that might be present in intermediate NHSs.  (See section 6.2.2.)  It
   is recommended that authoritative Next Hop Resolution Requests be



Katz, Piscitello, Cole, Luciani                                [Page 26]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   made for the duration of the holding time of the old information.


5.2.6  NHRP Error Indication

   The NHRP Error Indication is used to convey error indications to the
   sender of an NHRP packet.  It has a type code of 6.  The Mandatory
   Part has the following format:


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Error Code          |        Error Offset           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |    Unused      | Proto Length |                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                            unused                             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source NBMA Subaddress (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination  Protocol Address (variable length)         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Contents of NHRP Packet in error (variable length)      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Error Code
     An error code indicating the type of error detected, chosen from
     the following list:

       1 - Unrecognized Extension

         When the Compulsory bit of an extension is set, the NHRP
         request cannot be satisfied unless the extension is processed.
         The responder MUST return an Error Indication of type
         Unrecognized Extension if it is incapable of processing the
         extension.  However, if a transit NHS (one which is not going
         to generate a reply) detects an unrecognized extension, it
         SHALL ignore the extension.

       2 - Subnetwork ID Mismatch

         This error occurs when the current station receives an NHRP
         packet whose NBMA subnetwork identifier matches none of the



Katz, Piscitello, Cole, Luciani                                [Page 27]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


         locally known identifiers for the NBMA subnetwork on which the
         packet is received.

       3 - NHRP Loop Detected

         A Loop Detected error is generated when it is determined that
         an NHRP packet is being forwarded in a loop.


       8 - NHRP SDU Size Exceeded

         If the SDU size of the NHRP packet exceeds the maximum SDU size
         of the NBMA network, this error is returned.

       9 - Invalid Extension

         If an NHS finds an extension in a packet which is inappropriate
         for the packet type, an error is sent back to the sender with
         Invalid Extension as the code.

       10- Invalid Next Hop Resolution Reply Received

         If a client receives a Next Hop Resolution Reply for a Next Hop
         Resolution Request which it believes it did not make then an
         error packet is sent to the station making the reply with an
         error code of Invalid Reply Received.

   Error Offset
     The offset in octets into the original NHRP packet, starting at the
     NHRP Fixed Header, at which the error was detected.

   Proto Length
     The length in octets, of the internetwork layer protocol addresses
     appearing in this packet.  If this length is not a multiple of 4,
     each internetwork layer address is zero-filled to the nearest 32-
     bit boundary.

   Source NBMA Address
     The Source NBMA address field is the address of the source station
     which observed the error.  It is zero-filled to the nearest 32- bit
     boundary. However, if its length as specified in ar$shtl is 0 then
     no storage is allocated for this address at all.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the address of the source
     station which observed the error.  It is zero-filled to the nearest
     32- bit boundary. However, if its length as specified in ar$sstl is
     0 then no storage is allocated for this address at all.



Katz, Piscitello, Cole, Luciani                                [Page 28]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   Source Protocol Addresses
     This is the protocol address of the station which issued the Error
     packet.

   Destination Protocol Address
     This is the protocol address of the station for which the NBMA next
     hop is desired. However, if its length as specified in Proto Length
     is set to 0 then no storage is allocated for this address at all.

   An Error Indication packet SHALL NEVER be generated in response to
   another Error Indication packet.  When an Error Indication packet is
   generated, the offending NHRP packet SHALL be discarded.  In no case
   should more than one Error Indication packet be generated for a
   single NHRP packet.


5.3  Extensions Part

   The Extensions Part, if present, carries one or more extensions in
   {Type, Length, Value} triplets.  Extensions are only present in a
   Reply if they were present in the corresponding Request;  therefore,
   minimal NHRP station implementations that do not act as an NHS and do
   not transmit extensions need not be able to receive them.  An
   implementation that is incapable of processing extensions SHALL
   return an Error Indication of type Unrecognized Extension when it
   receives an NHRP packet containing extensions.

   Extensions are typically protocol-specific, as noted.

   Extensions have the following format:


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |C|u|        Type               |        Length                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         Value...                              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   C
     "Compulsory."  If clear, and the NHS does not recognize the type
     code, the extension may safely be ignored.  If set, and the NHS
     does not recognize the type code, the NHRP request is considered to
     be in error.  (See below for details.)

   u
     Unused and must be set to zero.



Katz, Piscitello, Cole, Luciani                                [Page 29]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   Type
     The extension type code (see below).  The extension type is not
     qualified by the Compulsory bit, but is orthogonal to it.

   Length
     The length in octets of the value (not including the Type and
     Length fields;  a null extension will have only an extension header
     and a length of zero).

   Each extension is padded with zero octets to a 32 bit boundary.  This
   padding is not included in the Length field.

   When extnsions exist, extensions list is terminated by the Null TLV,
   having Type = 0 and Length = 0.

   Extensions may occur in any order, but any particular extension type
   (other than the vendor-private extension) may occur only once in an
   NHRP packet.  The vendor-private extension may occur multiple times
   in a packet, to allow for extensions which do not share the same
   vendor ID to be represented.

   The Compulsory bit provides for a means to add to the extension set.
   If the bit is set, the NHRP request cannot be satisfied unless the
   extension is processed, so the responder MUST return an Error
   Indication of type Unrecognized Extension.  If the bit is clear, the
   extension can be safely ignored, though unrecognized extensions so
   ignored that were received in an NHRP Request packet MUST be returned
   unchanged in the corresponding NHRP Reply.

   If a transit NHS (one which is not going to generate a reply) detects
   an unrecognized extension, it SHALL ignore the extension.  If the
   Compulsory bit is set, the transit NHS MUST NOT cache the information
   (in the case of a reply) and MUST NOT identify itself as an egress
   router (in the Forward Record or Reverse Record extensions).
   Effectively, this means that a transit NHS that encounters an
   extension that it cannot process and determines that the Compulsory
   bit is set MUST NOT participate in any way in the protocol exchange,
   other than acting as a forwarding agent for the request.

5.3.1  Destination Prefix Extension

    Compulsory = 0
    Type = 1
    Length = 1

   This extension is used to indicate that the information carried in an
   NHRP Reply pertains to an equivalence class of destinations rather
   than just the destination Protocol address specified in the request.



Katz, Piscitello, Cole, Luciani                                [Page 30]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   All addresses that match the destination Protocol address in the bit
   positions for which the mask has a one bit are part of the
   equivalence class.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Destination Mask (variable lenfth)                    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The size of the mask in number of octets is obtained through the
   "Proto Length" in the Mandatory Part of packet.

   For example, in the case of IPv4, if an initiator would like to
   receive this equivalence information, it SHALL add this extension to
   the NHRP Request with a value of 255.255.255.255.  The responder
   SHALL copy the extension to the NHRP Reply and modify the mask
   appropriately.

5.3.2  NBMA Subnetwork ID Extension

    Compulsory = 1
    Type = 2
    Length = variable

   This extension is used to carry one or more identifiers for the NBMA
   subnetwork.  This can be used as a validity check to ensure that the
   request does not leave a particular NBMA subnetwork.  The extension
   is placed in an NHRP Request packet by the initiator with an ID value
   of zero;  the first NHS fills in the field with the identifier(s) for
   the NBMA subnetwork.

   Multiple NBMA Subnetwork IDs may be used as a transition mechanism
   while NBMA Subnetworks are being split or merged.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                    NBMA Subnetwork ID                         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     ...

   Each identifier consists of a 32 bit globally unique value assigned
   to the NBMA subnetwork.  This value should be chosen from the IP
   address space administered by the operators of the NBMA subnetwork.
   This value is used for identification only, not for routing or any
   other purpose.




Katz, Piscitello, Cole, Luciani                                [Page 31]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   Each NHS processing an NHRP Request SHALL verify these values.  If
   none of the values matches the NHS's NBMA Subnetwork ID, the NHS
   SHALL return an Error Indication of type "Subnetwork ID Mismatch" and
   discard the NHRP Request.

   When an NHS is building an NHRP Reply and the NBMA Subnetwork ID
   extension is present in the NHRP Request, the NBMA Subnetwork ID
   extension SHALL be copied from the Request to the Reply, including
   all values carried therein.

   Each NHS processing an NHRP Reply SHALL verify the values carried in
   the NBMA Subnetwork ID extension, if present.  If none of the values
   matches the NHSs NBMA Subnetwork ID, the NHS SHALL return an Error
   Indication of type "Subnetwork ID Mismatch" and discard the NHRP
   Reply.


5.3.3  Responder Address Extension

    Compulsory = 1
    Type = 3
    Length = 4

   This extension is used to determine the Protocol address of the NHRP
   Responder, that is, the entity that generates the NHRP Reply packet.
   The intent is to identify the entity responding to the request, which
   may be different (in the case of cached replies) than the system
   identified in the Next Hop field of the reply, and to aid in
   detecting loops in the NHRP forwarding path.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |              Responder's Protocol Address                     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The size of the Responder's Protocol Address in octets is obtained
   through the "Proto Length" in the Mandatory Part of packet.

   If a requester desires this information, it SHALL include this
   extension, with a value of zero, in the NHRP Request packet.

   If an NHS is generating an NHRP Reply packet in response to a request
   containing this extension, it SHALL include this extension,
   containing its Protocol address, in the NHRP Reply.  If an NHS has
   more than one Protocol address, it SHALL use the same Protocol
   address consistently in all of the Responder Address, Forward NHS
   Record, and Reverse NHS Record extensions.  The choice of which of



Katz, Piscitello, Cole, Luciani                                [Page 32]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   several Protocol addresses to include in this extension is a local
   matter.

   If an NHRP Next Hop Resolution Reply packet being forwarded by an NHS
   contains an Protocol  address of that NHS in the Responder Address
   Extension, the NHS SHALL generate an Error Indication of type "NHRP
   Loop Detected" and discard the Next Hop Resolution Reply.

   If an NHRP Next Hop Resolution Reply packet is being returned by an
   intermediate NHS  based on cached data, it SHALL place its own
   address in this extension (differentiating it from the address in the
   Next Hop field).


5.3.4  NHRP Forward NHS Record Extension

    Compulsory = 1
    Type = 4
    Length = variable

   The NHRP forward NHS record is a list of NHSs through which an NHRP
   request traverses.  Each NHS SHALL append a Next Hop element
   containing its Protocol address to this extension.

   In addition, NHSs that are willing to act as egress routers for
   packets from the source to the destination SHALL include information
   about their NBMA Address.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Unused     | Proto Length |         Holding Time          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  NHS Addr T/L  | NHS SAddr T/L|             unused            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |             Protocol Address (variable length)                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Next Hop NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Proto Length
     The length in octets, of the internetwork layer protocol addresses
     appearing in this packet.  If this length is not a multiple of 4,
     each internetwork layer address is zero-filled to the nearest 32-
     bit boundary.




Katz, Piscitello, Cole, Luciani                                [Page 33]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   Holding Time
     The Holding Time field specifies the number of seconds for which
     the NBMA information is considered to be valid.  Cached information
     SHALL be discarded when the holding time expires.  Must be set to 0
     on a NAK.

   NHS Addr T/L
     Type & length of transit NHS's NBMA address interpreted in the
     context of the 'hardware' (NBMA media) indicated by ar$afn (e.g.,
     ar$afn=0x0003 for ATM).  When the address length is specified as 0
     no storage is allocated for the address. Set to 0 on a NAK.

   NHS SAddr T/L
     Type & length of transit NHS's NBMA subaddress interpreted in the
     context of the 'hardware' (NBMA media) indicated by ar$afn (e.g.,
     ar$afn=0x0003 for ATM).  When an NBMA technology has no concept of
     a subaddress the subaddress is always null with a length of 0.
     When the address length is specified as 0 no storage is allocated
     for the address. Set to 0 on a NAK.

   NHS Protocol Address
     This internetworkin layer address specifies the transit NHS.  This
     will be the address of the destination host if it is directly
     attached to the NBMA subnetwork, or the egress router if it is not
     directly attached.

   NHS NBMA Address
     This is the NBMA address of the station that is the transit NHS for
     packets bound for the internetworking layer address specified.  The
     NBMA address field itself is zero-filled to the nearest 32-bit
     boundary.

   NHS NBMA SubAddress
     This is the NBMA sub address of the station that is the transit NHS
     for packets bound for the internetworking layer address specified.
     The NBMA subaddress field itself is zero-filled to the nearest 32-
     bit boundary.

   If a requester wishes to obtain this information, it SHALL include
   this extension with a length of zero.

   Each NHS SHALL append an appropriate Next Hop element to this
   extension when processing an NHRP Request.  The extension length
   field and NHRP checksum SHALL be adjusted as necessary.

   The last Hop NHS (the one that will be generating the NHRP Reply)
   SHALL NOT update this extension (since this information will be in
   the reply).



Katz, Piscitello, Cole, Luciani                                [Page 34]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   If an NHS has more than one Protocol address, it SHALL use the same
   Protocol address consistently in all of the Responder Address,
   Forward NHS Record, and Reverse NHS Record extensions.  The choice of
   which of several Protocol addresses to include in this extension is a
   local matter.

   If an NHRP Request packet being forwarded by an NHS contains the
   Protocol address of that NHS in the Forward NHS Record Extension, the
   NHS SHALL generate an Error Indication of type "NHRP Loop Detected"
   and discard the Request.


5.3.5  NHRP Reverse NHS Record Extension

    Compulsory = 1
    Type = 5
    Length = variable

   The NHRP reverse NHS record is a list of NHSs through which an NHRP
   reply traverses.  Each NHS SHALL append a Next Hop element containing
   its Protocol address to this extension.

   In addition, NHSs that are willing to act as egress routers for
   packets from the source to the destination SHALL include information
   about their NBMA Address.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Unused     | Proto Length |         Holding Time          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  NHS Addr T/L  | NHS SAddr T/L|             unused            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |             Protocol Address (variable length)                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Next Hop NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Proto Length
     The length in octets, of the internetwork layer protocol addresses
     appearing in this packet.  If this length is not a multiple of 4,
     each internetwork layer address is zero-filled to the nearest 32-
     bit boundary.

   Holding Time
     The Holding Time field specifies the number of seconds for which



Katz, Piscitello, Cole, Luciani                                [Page 35]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


     the NBMA information is considered to be valid.  Cached information
     SHALL be discarded when the holding time expires.  Must be set to 0
     on a NAK.

   NHS Addr T/L
     Type & length of transit NHS's NBMA address interpreted in the
     context of the 'hardware' (NBMA media) indicated by ar$afn (e.g.,
     ar$afn=0x0003 for ATM).  When the address length is specified as 0
     no storage is allocated for the address. Set to 0 on a NAK.

   NHS SAddr T/L
     Type & length of transit NHS's NBMA subaddress interpreted in the
     context of the 'hardware' (NBMA media) indicated by ar$afn (e.g.,
     ar$afn=0x0003 for ATM).  When an NBMA technology has no concept of
     a subaddress the subaddress is always null with a length of 0.
     When the address length is specified as 0 no storage is allocated
     for the address. Set to 0 on a NAK.

   NHS Protocol Address
     This internetworkin layer address specifies the transit NHS.  This
     will be the address of the destination host if it is directly
     attached to the NBMA subnetwork, or the egress router if it is not
     directly attached.

   NHS NBMA Address
     This is the NBMA address of the station that is the transit NHS for
     packets bound for the internetworking layer address specified.  The
     NBMA address field itself is zero-filled to the nearest 32-bit
     boundary.

   NHS NBMA SubAddress
     This is the NBMA sub address of the station that is the transit NHS
     for packets bound for the internetworking layer address specified.
     The NBMA subaddress field itself is zero-filled to the nearest 32-
     bit boundary.


   If a requester wishes to obtain this information, it SHALL include
   this extension with a length of zero.

   Each NHS SHALL append an appropriate Next Hop element to this
   extension when processing an NHRP Reply.  The extension length field
   and NHRP checksum SHALL be adjusted as necessary.

   The NHS generating the NHRP Reply SHALL NOT update this extension.

   If an NHS has more than one Protocol address, it SHALL use the same
   Protocol address consistently in all of the Responder Address,



Katz, Piscitello, Cole, Luciani                                [Page 36]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   Forward NHS Record, and Reverse NHS Record extensions.  The choice of
   which of several Protocol addresses to include in this extension is a
   local matter.

   If an NHRP Reply packet being forwarded by an NHS contains the
   Protocol address of that NHS in the Reverse NHS Record Extension, the
   NHS SHALL generate an Error Indication of type "NHRP Loop Detected"
   and discard the Reply.

   Note that this information may be cached at intermediate NHSs;  if
   so, the cached value SHALL be used when generating a reply.  Note
   that the Responder Address extension may be used to disambiguate the
   set of NHSs that actually processed the reply.


5.3.6  NHRP QoS Extension

    Compulsory = 0
    Type = 6
    Length = variable

   The NHRP QoS Extension is carried in NHRP Request packets to indicate
   the desired QoS of the path to the indicated destination.  This
   information may be used to help select the appropriate NBMA next hop.

   It may also be carried in NHRP Register packets to indicate the QoS
   to which the registration applies.

   The syntax and semantics of this extension are TBD;  alignment with
   resource reservation may be useful.


5.3.7  NHRP Authentication Extension

    Compulsory = 1
    Type = 7
    Length = variable

   The NHRP Authentication Extension is carried in NHRP packets to
   convey authentication information between NHRP speakers.  The
   Authentication Extension may be included in any NHRP packet type.

   Authentication is done pairwise on an NHRP hop-by Hop basis;  the
   authentication extension is regenerated on each hop.  If a received
   packet fails the authentication test, the NHS SHALL generate an Error
   Indication of type "Authentication Failure" and discard the packet.
   In no case SHALL an Error Indication packet be generated on the
   receipt of an Error Indication packet, however.  Note that one



Katz, Piscitello, Cole, Luciani                                [Page 37]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   possible authentication failure is the lack of an Authentication
   Extension;  the presence or absence of the Authentication Extension
   is a local matter.


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                     Authentication Type                       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Authentication Type field identifies the authentication method in
   use.  Currently assigned values are:

   1 - Cleartext Password
   2 - Keyed MD5

   All other values are reserved.

   The Authentication Data field contains the type-specific
   authentication information.

   In the case of Cleartext Password Authentication, the Authentication
   Data consists of a variable length password.

   In the case of Keyed MD5 Authentication, the Authentication Data
   contains the 16 byte MD5 digest of the entire NHRP packet, including
   the encapsulated protocol's header, with the authentication key
   appended to the end of the packet.  The authentication key is not
   transmitted with the packet.

   Distribution of authentication keys is outside the scope of this
   document.


5.3.8  NHRP Vendor-Private Extension

    Compulsory = 0
    Type = 8
    Length = variable

   The NHRP Vendor-Private Extension is carried in NHRP packets to
   convey vendor-private information or NHRP extensions between NHRP
   speakers.  This extension may be used at any time; if the receiver



Katz, Piscitello, Cole, Luciani                                [Page 38]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   does not handle this extension, or does not match the vendor ID in
   the extension, then the extension may be completely ignored by the
   receiver.  The first 24 bits of the extension's payload (following
   the length field) contains the 802 vendor ID as assigned by the IEEE
   [6].  The remaining octets in the payload are vendor-dependent.


5.3.9  Additional Next Hop Entries Extension

    Compulsory = 0
    Type = 9
    Length = variable

   This extension may be used to return multiple Next Hop entries in a
   single NHRP Reply packet.  This extension MUST only be used for
   positive replies.  The preference values are used to specify the
   relative preference of the entries contained in the extension.  The
   same next Hop Protocol address may be associated with multiple NBMA
   addresses.  Load-splitting may be performed over the addresses, given
   equal preference values, and the alternative addresses may be used in
   case of connectivity failure in the NBMA subnetwork (such as a failed
   call attempt in connection-oriented NBMA subnetworks).





























Katz, Piscitello, Cole, Luciani                                [Page 39]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Unused     | Proto Length |  Next Hop Holding Time        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  NH Addr T/L   | NH SAddr T/L |   Preference  |   unused      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop Protocol Address (variable length)           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Next Hop NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              .....................
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Unused     | Proto Length |  Next Hop Holding Time        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  NH Addr T/L   | NH SAddr T/L |   Preference  |   unused      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop Protocol Address (variable length)           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Next Hop NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   An NHS is not allowed to reply to an NHRP request for authoritative
   information with cached information, but may do so for an NHRP
   Request which indicates a request for non-authoritative information.
   An NHS may reply to an NHRP request for non-authoritative information
   with authoritative information.

   Proto Length
     The length in octets, of the internetwork layer protocol addresses
     appearing in this packet.  If this length is not a multiple of 4,
     each internetwork layer address is zero-filled to the nearest 32-
     bit boundary.

   Next Hop Holding Time
     The Next Hop Address Holding Time field specifies the number of
     seconds for which the next hop NBMA information is considered to be
     valid.  Cached information SHALL be discarded when the holding time
     expires.  Must be set to 0 on a NAK.

   NH Addr T/L
     Type & length of next hop NBMA address interpreted in the context
     of the 'hardware' (NBMA media) indicated by ar$afn (e.g.,
     ar$afn=0x0003 for ATM).  When the address length is specified as 0



Katz, Piscitello, Cole, Luciani                                [Page 40]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


     no storage is allocated for the address. Set to 0 on a NAK.

   NH SAddr T/L
     Type & length of next hop NBMA subaddress interpreted in the
     context of the 'hardware' (NBMA media) indicated by ar$afn (e.g.,
     ar$afn=0x0003 for ATM).  When an NBMA technology has no concept of
     a subaddress the subaddress is always null with a length of 0.
     When the address length is specified as 0 no storage is allocated
     for the address. Set to 0 on a NAK.

   Preference
     This field specifies the preference of the Next Hop entry, relative
     to other Next Hop entries in this NHRP Reply packet which may be in
     the Additional Next Hop Entries Extension for the given
     internetworking protocol.  Higher values indicate more preferable
     Next Hop entries.  Action taken when multiple next hop entries have
     the highest preference value is a local matter.  Set to 0 on a NAK.

   Next Hop Protocol Address
     This internetworkin layer address specifies the next hop.  This
     will be the address of the destination host if it is directly
     attached to the NBMA subnetwork, or the egress router if it is not
     directly attached.

   Next Hop NBMA Address
     This is the NBMA address of the station that is the next hop for
     packets bound for the internetworking layer address specified.  The
     NBMA address field itself is zero-filled to the nearest 32-bit
     boundary.

   Next Hop NBMA SubAddress
     This is the NBMA sub address of the station that is the next hop
     for packets bound for the internetworking layer address specified.
     The NBMA subaddress field itself is zero-filled to the nearest 32-
     bit boundary.


6. Protocol Operation

   In this section, we discuss certain operational considerations of
   NHRP.


6.1 Router-to-Router Operation

   In practice, the initiating and responding stations may be either
   hosts or routers.  However, there is a possibility under certain
   conditions that a stable routing loop may occur if NHRP is used



Katz, Piscitello, Cole, Luciani                                [Page 41]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   between two routers.  In particular, attempting to establish an NHRP
   path across a boundary where information used in route selection is
   lost may result in a routing loop.  Such situations include the loss
   of BGP path vector information, the interworking of multiple routing
   protocols with dissimilar metrics (e.g, RIP and OSPF), etc.  In such
   circumstances, NHRP should not be used.  This situation can be
   avoided if there are no "back door" paths between the entry and
   egress router outside of the NBMA subnetwork.  Protocol mechanisms to
   relax these restrictions are under investigation.

   In general it is preferable to use mechanisms, if they exist, in
   routing protocols to resolve the egress point when the destination
   lies outside of the NBMA subnetwork, since such mechanisms will be
   more tightly coupled to the state of the routing system and will
   probably be less likely to create loops.

6.2 Cache Management Issues

   The management of NHRP caches in the source station, the NHS serving
   the destination, and any intermediate NHSs is dependent on a number
   of factors.


   6.2.1 Cacheing Requirements

     Source Stations

     Source stations MUST cache all received replies that they are
     actively using.  They also must cache "incomplete" entries, i.e.,
     those for which a request has been sent but which a reply has not
     been received.  This is necessary in order to preserve the Request
     ID for retries, and provides the state necessary to avoid
     triggering requests for every data packet sent to the destination.

     Source stations MUST purge expired information from their caches.
     Source stations MUST purge the appropriate cached information upon
     receipt of an NHRP Purge request packet.

     Source stations that are also NHSs may return cached information
     learned in response to its own Next Hop Resolution Request packets
     in reply to requests it receives, within the rules for Transit NHSs
     below.


     Serving NHSs

     The NHS serving the destination (the one which responds
     authoritatively to Next Hop Resolution Requests) SHOULD cache



Katz, Piscitello, Cole, Luciani                                [Page 42]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


     information about all requests to which it has responded if the
     information in the reply has the possibility of changing during its
     lifetime (so that an NHRP Purge request packet can be sent).  The
     NBMA information provided by the source station in the Next Hop
     Resolution Request may be cached for the duration of its holding
     time.  This information is considered to be stable, since it
     identifies a station directly attached to the NBMA subnetwork.  An
     example of unstable information is NBMA information derived from a
     routing table, where that routing table information has not been
     guaranteed to be stable through administrative means.

     Transit NHSs

     A Transit NHS (lying along the NHRP path between the source station
     and the responding NHS) may cache information contained in Next Hop
     Resolution Request packets that it forwards.  A Transit NHS may
     cache information contained in NHRP Reply packets that it forwards
     only if that reply has the Stable (B) bit set.  It MUST discard any
     cached information whose holding time has expired.  It may return
     cached information in response to non-authoritative requests only.


   6.2.2 Dynamics of Cached Information

   NBMA-Connected Destinations

     NHRP's most basic function is that of simple NBMA address
     resolution of stations directly attached to the NBMA subnetwork.
     These mappings are typically very static, and appropriately chosen
     holding times will minimize problems in the event that the NBMA
     address of a station must be changed.  Stale information will cause
     a loss of connectivity, which may be used to trigger an
     authoritative Next Hop Resolution Request and bypass the old data.
     In the worst case, connectivity will fail until the cache entry
     times out.

     This applies equally to information marked in replies as being
     "stable" (via the "B" 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 Next Hop Resolution
     Request packet is always considered "stable" because it represents
     a station that is directly connected to the NBMA subnetwork.






Katz, Piscitello, Cole, Luciani                                [Page 43]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   Destinations Off of the NBMA Subnetwork

     If the source of a request is a host and the destination is not
     directly attached to the NBMA subnetwork, and the route to that
     destination is not considered to be "stable," the destination
     mapping may be very dynamic (except in the case of a subnetwork
     where each destination is only singly homed to the NBMA
     subnetwork).  As such the cached information may very likely become
     stale.  The consequence of stale information in this case will be a
     suboptimal path (unless the internetwork has partitioned or some
     other routing failure has occurred).

     Strategies for maintaining NHRP cache information in the presence
     of dynamic routing changes will be discussed in a separate
     document.

6.3 Use of the Destination Prefix Extension

   A certain amount of care needs to be taken when using the Destination
   Prefix Extension, in particular with regard to the prefix length
   advertised (and thus the size of the equivalence class specified by
   it).  Assuming that the routers on the NBMA subnetwork are exchanging
   routing information, it should not be possible for an NHS to create a
   black hole by advertising too large of a set of destinations, but
   suboptimal routing (e.g., extra internetwork layer hops through the
   NBMA) can result.  To avoid this situation an NHS that wants to send
   the Destination Prefix Extension MUST obey the following rule:

     The NHS examines the Network Layer Reachability Information (NLRI)
     associated with the route that the NHS would use to forward towards
     the destination (as specified by the Destination IP address in the
     Next Hop Resolution Request), and extracts from this NLRI the
     shortest address prefix such that: (a) the Destination IP address
     (from the Next Hop Resolution Request) is 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 prefix may then be used for
     the Destination Prefix Extension.

   The NHRP Destination Prefix Extension should be used with restraint,
   in order to avoid NHRP stations choosing suboptimal transit paths
   when overlapping prefixes are available.  This extension SHOULD only
   be used in an NHRP Reply when either:

     (a) All destinations covered by the prefix are on the NBMA network, or
     (b) All destinations covered by the prefix are directly attached to
         the NHRP responding station.

   For other cases, there may be no single optimal transit path for



Katz, Piscitello, Cole, Luciani                                [Page 44]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   destinations encompassed by the address prefix, and an NHRP station
   may fail to choose the optimal transit path simply because it is not
   aware of all such paths.  So for cases not covered by (a) and (b), an
   NHRP Reply packet should not include the NHRP Destination Prefix
   Extension.

6.4 Domino Effect

   One could easy imagine a situation where a router, acting as an
   ingress station to the NBMA subnetwork, receives a data packet, such
   that this packet triggers an Next Hop Resolution Request.  If the
   router forwards this data packet without waiting for an NHRP transit
   path to be established, then when the next router along the path
   receives the packet, the next router may do exactly the same -
   originate its own Next Hop Resolution Request (as well as forward the
   packet).  In fact such a data packet may trigger Next Hop Resolution
   Request generation at every router along the path through an NBMA
   subnetwork.  We refer to this phenomena as the NHRP "domino" effect.

   The NHRP domino effect is clearly undesirable.  At best it may result
   in excessive NHRP traffic.  At worst it may result in an excessive
   number of virtual circuits being established unnecessarily.
   Therefore, it is important to take certain measures to avoid or
   suppress this behavior.  NHRP implementations for NHSs MUST provide a
   mechanism to address this problem.  It is recommended that
   implementations provide one or more of the following solutions.

   Possibly the most straightforward solution for suppressing the domino
   effect would be to require transit routers to be preconfigured not to
   originate Next Hop Resolution Requests for data traffic which is
   simply being forwarded (not originated).  In this case the routers
   avoid the domino effect through an administrative policy.

   A second possible solution would be to require that when a router
   forwards an Next Hop Resolution Request, the router instantiates a
   (short-lived) state.  This state consists of the route that was used
   to forward the request.  If the router receives a data packet, and
   the packet triggers an Next Hop Resolution Request generation by the
   router, the router checks whether the route to forward the request
   was recently used to forward some other Next Hop Resolution Request.
   If so, then the router suppresses generation of the new request (but
   still forwards the data packet).  This solution also requires that
   when a station attempts to originate an Next Hop Resolution Request
   the station should send the Next Hop Resolution Request before the
   data packet that triggered the origination of the request.
   Otherwise, unnecessary Next Hop Resolution Requests may still be
   generated.




Katz, Piscitello, Cole, Luciani                                [Page 45]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   A third possible strategy would be to configure a router in such a
   way that Next Hop Resolution Request generation by the router would
   be driven only by the traffic the router receives over its non-NBMA
   interfaces (interfaces that are not attached to an NBMA subnetwork).
   Traffic received by the router over its NBMA-attached interfaces
   would not trigger NHRP Next Hop Resolution Requests.  Just as in the
   first case, such a router avoids the NHRP domino effect through
   administrative means.

   Lastly, rate limiting of Next Hop Resolution Requests may help to
   avoid the NHRP domino effect.  Intermediate routers which would
   otherwise generate unnecessary Next Hop Resolution Requests may
   instead suppress such requests due to the measured request rate
   exceeding a certain threshold.  Of course, such rate limiting would
   have to be very aggressive in order to completely avoid the domino
   effect.  Further work is needed to analyze this solution.

7. Security Considerations

   As in any routing protocol, there are a number of potential security
   attacks possible.  Plausible examples include denial-of-service
   attacks, and masquerade attacks using register and purge packets.
   The use of authentication on all packets is recommended to avoid such
   attacks.

   The authentication schemes described in this document are intended to
   allow the receiver of a packet to validate the identity of the
   sender; they do not provide privacy or protection against replay
   attacks.

   Detailed security analysis of this protocol is for further study.


8. Discussion

   The result of an Next Hop Resolution Request depends on how routing
   is configured among the NHSs of an NBMA subnetwork.  If the
   destination station is directly connected to the NBMA subnetwork and
   the the routed path to it lies entirely within the NBMA subnetwork,
   the NHRP replies always return the NBMA address of the destination
   station itself rather than the NBMA address of some egress router.
   On the other hand, if the routed path exits the NBMA subnetwork, NHRP
   will be unable to resolve the NBMA address of the destination, but
   rather will return the address of the egress router.  For
   destinations outside the NBMA subnetwork, egress routers and routers
   in the other subnetworks should exchange routing information so that
   the optimal egress router may be found.




Katz, Piscitello, Cole, Luciani                                [Page 46]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   In addition to NHSs, an NBMA station could also be associated with
   one or more regular routers that could act as "connectionless
   servers" for the station.  The station could then choose to resolve
   the NBMA next hop or just send the IP packets to one of its
   connectionless servers.  The latter option may be desirable if
   communication with the destination is short-lived and/or doesn't
   require much network resources.  The connectionless servers could, of
   course, be physically integrated in the NHSs by augmenting them with
   IP switching functionality.


References

   [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh
       Govindan, draft-ietf-rolc-nbma-arp-00.txt.

   [2] Address Resolution Protocol, David C. Plummer, RFC 826.

   [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577.

   [4] Transmission of IP datagrams over the SMDS service, J. Lawrence
       and D. Piscitello, RFC 1209.

   [5] Protocol Identification in the Network Layer, ISO/IEC TR
       9577:1990.

   [6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700.

   [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen,
       RFC1483.

   [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode,
       A. Malis, D. Robinson, and R. Ullmann, RFC1356.

   [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and
       A. Malis, RFC1490.



Acknowledgments

   We would like to thank Juha Heinenan of 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.  John Burnett of
   Adaptive, Dennis Ferguson of ANS, Joel Halpern of Newbridge, Paul
   Francis of NTT, Tony Li and Yakov Rekhter of cisco, and Grenville
   Armitage of Bellcore should also be acknowledged for comments and
   suggestions that improved this work substantially.  We would also



Katz, Piscitello, Cole, Luciani                                [Page 47]

INTERNET-DRAFT                 NBMA NHRP                Expires May 1996


   like to thank the members of the Routing Over Large Clouds working
   group of the IETF, whose review and discussion of this document have
   been invaluable.

Authors' Addresses


   Dave Katz                           David Piscitello
   cisco Systems                       Core Competence
   170 W. Tasman Dr.                   1620 Tuckerstown Road
   San Jose, CA 95134 USA              Dresher, PA 19025 USA

   Phone:  +1 408 526 8284             Phone:  +1 215 830 0692
   Email:  dkatz@cisco.com             Email: dave@corecom.com

   Bruce Cole                          James V. Luciani
   cisco Systems                       Ascom Nexion
   170 W. Tasman Dr.                   289 Great Road
   San Jose, CA 95134 USA              Acton, MA 01720-4379 USA

   Phone:  +1 408 526 4000             Phone:  +1 508 266 3450
   Email:  bcole@cisco.com             Email: luciani@nexen.com





























Katz, Piscitello, Cole, Luciani                                [Page 48]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/