home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-rolc-nhrp-12.txt < prev    next >
Text File  |  1997-10-29  |  122KB  |  2,800 lines
  1.  
  2.  
  3. Routing over Large Clouds Working Group                 James V. Luciani
  4. INTERNET-DRAFT                                            (Bay Networks)
  5. <draft-ietf-rolc-nhrp-12.txt>                                  Dave Katz
  6.                                                          (cisco Systems)
  7.                                                         David Piscitello
  8.                                                  (Core Competence, Inc.)
  9.                                                               Bruce Cole
  10.                                                       (Juniper Networks)
  11.                                                       Expires March 1998
  12.  
  13.  
  14.                 NBMA Next Hop Resolution Protocol (NHRP)
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This document is an Internet-Draft.  Internet-Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its areas,
  21.    and its working groups.  Note that other groups may also distribute
  22.    working documents as Internet-Drafts.
  23.  
  24.    Internet-Drafts are draft documents valid for a maximum of six months
  25.    and may be updated, replaced, or obsoleted by other documents at any
  26.    time.  It is inappropriate to use Internet-Drafts as reference
  27.    material or to cite them other than as ``work in progress.''
  28.  
  29.    To learn the current status of any Internet-Draft, please check the
  30.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  31.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  32.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  33.    Rim).
  34.  
  35.    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
  36.    SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
  37.    document, are to be interpreted as described in [15].
  38.  
  39.  
  40. Abstract
  41.  
  42.    This document describes the NBMA Next Hop Resolution Protocol (NHRP).
  43.    NHRP can be used by a source station (host or router) connected to a
  44.    Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
  45.    internetworking layer address and NBMA subnetwork addresses of the
  46.    ''NBMA next hop'' towards a destination station.  If the destination is
  47.    connected to the NBMA subnetwork, then the NBMA next hop is the
  48.    destination station itself.  Otherwise, the NBMA next hop is the
  49.    egress router from the NBMA subnetwork that is ''nearest'' to the
  50.    destination station.  NHRP is intended for use in a multiprotocol
  51.  
  52.  
  53.  
  54. Luciani, Katz, Piscitello, Cole                                 [Page 1]
  55.  
  56. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  57.  
  58.  
  59.    internetworking layer environment over NBMA subnetworks.
  60.  
  61.    Note that while this protocol was developed for use with NBMA
  62.    subnetworks, it is possible, if not likely, that it will be applied
  63.    to BMA subnetworks as well.  However, this usage of NHRP is for
  64.    further study.
  65.  
  66.    This document is intended to be a functional superset of the NBMA
  67.    Address Resolution Protocol (NARP) documented in [1].
  68.  
  69.    Operation of NHRP as a means of establishing a transit path across an
  70.    NBMA subnetwork between two routers will be addressed in a separate
  71.    document (see [13]).
  72.  
  73.  
  74.  
  75.  
  76. 1. Introduction
  77.  
  78.    The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
  79.    (a host or router), wishing to communicate over a Non-Broadcast,
  80.    Multi-Access (NBMA) subnetwork, to determine the internetworking
  81.    layer addresses and NBMA addresses of suitable "NBMA next hops"
  82.    toward a destination station.  A subnetwork can be non-broadcast
  83.    either because it technically doesn't support broadcasting (e.g., an
  84.    X.25 subnetwork) or because broadcasting is not feasible for one
  85.    reason or another (e.g., an SMDS multicast group or an extended
  86.    Ethernet would be too large).  If the destination is connected to the
  87.    NBMA subnetwork, then the NBMA next hop is the destination station
  88.    itself.  Otherwise, the NBMA next hop is the egress router from the
  89.    NBMA subnetwork that is "nearest" to the destination station.
  90.  
  91.    One way to model an NBMA network is by using the notion of logically
  92.    independent IP subnets (LISs). LISs, as defined in [3] and [4], have
  93.    the following properties:
  94.  
  95.       1)  All members of a LIS have the same IP network/subnet number
  96.           and address mask.
  97.  
  98.       2)  All members of a LIS are directly connected to the same
  99.           NBMA subnetwork.
  100.  
  101.       3)  All hosts and routers outside of the LIS are accessed via a router.
  102.  
  103.       4)  All members of a LIS access each other directly (without routers).
  104.  
  105.    Address resolution as described in [3] and [4] only resolves the next
  106.    hop address if the destination station is a member of the same LIS as
  107.  
  108.  
  109.  
  110. Luciani, Katz, Piscitello, Cole                                 [Page 2]
  111.  
  112. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  113.  
  114.  
  115.    the source station; otherwise, the source station must forward
  116.    packets to a router that is a member of multiple LIS's.  In multi-LIS
  117.    configurations, hop-by-hop address resolution may not be sufficient
  118.    to resolve the "NBMA next hop" toward the destination station, and IP
  119.    packets may have multiple IP hops through the NBMA subnetwork.
  120.  
  121.    Another way to model NBMA is by using the notion of Local Address
  122.    Groups (LAGs) [10]. The essential difference between the LIS and the
  123.    LAG models is that while with the LIS model the outcome of the
  124.    "local/remote" forwarding decision is driven purely by addressing
  125.    information, with the LAG model the outcome of this decision is
  126.    decoupled from the addressing information and is coupled with the
  127.    Quality of Service and/or traffic characteristics.  With the LAG
  128.    model any two entities on a common NBMA network could establish a
  129.    direct communication with each other, irrespective of the entities'
  130.    addresses.
  131.  
  132.    Support for the LAG model assumes the existence of a mechanism that
  133.    allows any entity (i.e., host or router) connected to an NBMA network
  134.    to resolve an internetworking layer address to an NBMA address for
  135.    any other entity connected to the same NBMA network.  This resolution
  136.    would take place regardless of the address assignments to these
  137.    entities. Within the parameters described in this document, NHRP
  138.    describes such a mechanism.  For example, when the internetworking
  139.    layer address is of type IP, once the NBMA next hop has been
  140.    resolved, the source may either start sending IP packets to the
  141.    destination (in a connectionless NBMA subnetwork such as SMDS) or may
  142.    first establish a connection to the destination with the desired
  143.    bandwidth (in a connection-oriented NBMA subnetwork such as ATM).
  144.  
  145.    Use of NHRP may be sufficient for hosts doing address resolution when
  146.    those hosts are directly connected to an NBMA subnetwork, allowing
  147.    for straightforward implementations in NBMA stations. NHRP also has
  148.    the capability of determining the egress point from an NBMA
  149.    subnetwork when the destination is not directly connected to the NBMA
  150.    subnetwork and the identity of the egress router is not learned by
  151.    other methods (such as routing protocols).  Optional extensions to
  152.    NHRP provide additional robustness and diagnosability.
  153.  
  154.    Address resolution techniques such as those described in [3] and [4]
  155.    may be in use when NHRP is deployed.  ARP servers and services over
  156.    NBMA subnetworks may be required to support hosts that are not
  157.    capable of dealing with any model for communication other than the
  158.    LIS model, and deployed hosts may not implement NHRP but may continue
  159.    to support ARP variants such as those described in [3] and [4].  NHRP
  160.    is intended to reduce or eliminate the extra router hops required by
  161.    the LIS model, and can be deployed in a non-interfering manner with
  162.    existing ARP services [14].
  163.  
  164.  
  165.  
  166. Luciani, Katz, Piscitello, Cole                                 [Page 3]
  167.  
  168. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  169.  
  170.  
  171.    The operation of NHRP to establish transit paths across NBMA
  172.    subnetworks between two routers requires additional mechanisms to
  173.    avoid stable routing loops, and will be described in a separate
  174.    document (see [13]).
  175.  
  176.  
  177. 2. Overview
  178.  
  179.  
  180. 2.1 Terminology
  181.  
  182.    The term "network" is highly overloaded, and is especially confusing
  183.    in the context of NHRP.  We use the following terms:
  184.  
  185.      Internetwork layer--the media-independent layer (IP in the case of
  186.      TCP/IP networks).
  187.  
  188.      Subnetwork layer--the media-dependent layer underlying the
  189.      internetwork layer, including the NBMA technology (ATM, X.25, SMDS,
  190.      etc.)
  191.  
  192.      The term "server", unless explicitly stated to the contrary, refers
  193.      to a Next Hop Server (NHS).  An NHS is an entity performing the
  194.      Next Hop Resolution Protocol service within the NBMA cloud.  An NHS
  195.      is always tightly coupled with a routing entity (router, route
  196.      server or edge device) although the converse is not yet guaranteed
  197.      until ubiquitous deployment of this functionality occurs.  Note
  198.      that the presence of intermediate routers that are not coupled with
  199.      an NHS entity may preclude the use of NHRP when source and
  200.      destination stations on different sides of such routers and thus
  201.      such routers may partition NHRP reachability within an NBMA
  202.      network.
  203.  
  204.      The term "client", unless explicitly stated to the contrary, refers
  205.      to a Next Hop Resolution Protocol client (NHC).  An NHC is an
  206.      entity which initiates NHRP requests of various types in order to
  207.      obtain access to the NHRP service.
  208.  
  209.      The term "station" generally refers to a host or router which
  210.      contains an NHRP entity.  Occasionally, the term station will
  211.      describe a "user" of the NHRP client or service functionality; the
  212.      difference in usage is largely semantic.
  213.  
  214.  
  215. 2.2 Protocol Overview
  216.  
  217.    In this section, we briefly describe how a source S (which
  218.    potentially can be either a router or a host) uses NHRP to determine
  219.  
  220.  
  221.  
  222. Luciani, Katz, Piscitello, Cole                                 [Page 4]
  223.  
  224. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  225.  
  226.  
  227.    the "NBMA next hop" to destination D.
  228.  
  229.    For administrative and policy reasons, a physical NBMA subnetwork may
  230.    be partitioned into several, disjoint "Logical NBMA subnetworks".  A
  231.    Logical NBMA subnetwork is defined as a collection of hosts and
  232.    routers that share unfiltered subnetwork connectivity over an NBMA
  233.    subnetwork.  "Unfiltered subnetwork connectivity" refers to the
  234.    absence of closed user groups, address screening or similar features
  235.    that may be used to prevent direct communication between stations
  236.    connected to the same NBMA subnetwork.  (Hereafter, unless otherwise
  237.    specified, we use the term "NBMA subnetwork" to mean *logical* NBMA
  238.    subnetwork.)
  239.  
  240.    Placed within the NBMA subnetwork are one or more entities that
  241.    implement the NHRP protocol.  Such stations which are capable of
  242.    answering NHRP Resolution Requests are known as "Next Hop Servers"
  243.    (NHSs).  Each NHS serves a set of destination hosts, which may or may
  244.    not be directly connected to the NBMA subnetwork.  NHSs cooperatively
  245.    resolve the NBMA next hop within their logical NBMA subnetwork.  In
  246.    addition to NHRP, NHSs may support "classical" ARP service; however,
  247.    this will be the subject of a separate document [14].
  248.  
  249.    An NHS maintains a cache which contains protocol layer address to
  250.    NBMA subnetwork layer address resolution information.  This cache can
  251.    be constructed from information obtained from NHRP Register packets
  252.    (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply
  253.    packets, or through mechanisms outside the scope of this document
  254.    (examples of such mechanisms might include ARP[3] and pre-configured
  255.    tables).  Section 6.2 further describes cache management issues.
  256.  
  257.    For a station within a given LIS to avoid providing NHS
  258.    functionality, there must be one or more NHSs within the NBMA
  259.    subnetwork which are providing authoritative address resolution
  260.    information on its behalf.  Such an NHS is said to be "serving" the
  261.    station.  A station on a LIS that lacks NHS functionality and is a
  262.    client of the NHRP service is known as NHRP Client or just NHCs.  If
  263.    a serving NHS is to be able to supply the address resolution
  264.    information for an NHC then NHSs must exist at each hop along all
  265.    routed paths between the NHC making the resolution request and the
  266.    destination NHC.  The last NHRP entity along the routed path is the
  267.    serving NHS; that is, NHRP Resolution Requests are not forwarded to
  268.    destination NHCs but rather are processed by the serving NHS.
  269.  
  270.    An NHC also maintains a cache of protocol address to NBMA address
  271.    resolution information.  This cache is populated through information
  272.    obtained from NHRP Resolution Reply packets, from manual
  273.    configuration, or through mechanisms outside the scope of this
  274.    document.
  275.  
  276.  
  277.  
  278. Luciani, Katz, Piscitello, Cole                                 [Page 5]
  279.  
  280. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  281.  
  282.  
  283.    The protocol proceeds as follows.  An event occurs triggering station
  284.    S to want to resolve the NBMA address of a path to D.  This is most
  285.    likely to be when a data packet addressed to station D is to be
  286.    emitted from station S (either because station S is a host, or
  287.    station S is a transit router), but the address resolution could also
  288.    be triggered by other means (a routing protocol update packet, for
  289.    example). Station S first determines the next hop to station D
  290.    through normal routing processes (for a host, the next hop may simply
  291.    be the default router; for routers, this is the "next hop" to the
  292.    destination internetwork layer address).  If the destination's
  293.    address resolution information is already available in S's cache then
  294.    that information is used to forward the packet.  Otherwise, if the
  295.    next hop is reachable through one of its NBMA interfaces, S
  296.    constructs an NHRP Resolution Request packet (see Section 5.2.1)
  297.    containing station D's internetwork layer address as the (target)
  298.    destination address, S's own internetwork layer address as the source
  299.    address (Next Hop Resolution Request initiator), and station S's NBMA
  300.    addressing information.  Station S may also indicate that it prefers
  301.    an authoritative NHRP Resolution Reply (i.e., station S only wishes
  302.    to receive an NHRP Resolution Reply from an NHS serving the
  303.    destination NHC). Station S emits the NHRP Resolution Request packet
  304.    towards the destination.
  305.  
  306.    If the NHRP Resolution Request is triggered by a data packet then S
  307.    may, while awaiting an NHRP Resolution Reply, choose to dispose of
  308.    the data packet in one of the following ways:
  309.  
  310.      (a)  Drop the packet
  311.      (b)  Retain the packet until the NHRP Resolution Reply arrives
  312.           and a more optimal path is available
  313.      (c)  Forward the packet along the routed path toward D
  314.  
  315.  
  316.    The choice of which of the above to perform is a local policy matter,
  317.    though option (c) is the recommended default, since it may allow data
  318.    to flow to the destination while the NBMA address is being resolved.
  319.    Note that an NHRP Resolution Request for a given destination MUST NOT
  320.    be triggered on every packet.
  321.  
  322.    When the NHS receives an NHRP Resolution Request, a check is made to
  323.    see if it serves station D.  If the NHS does not serve D, the NHS
  324.    forwards the NHRP Resolution Request to another NHS.  Mechanisms for
  325.    determining how to forward the NHRP Resolution Request are discussed
  326.    in Section 3.
  327.  
  328.    If this NHS serves D, the NHS resolves station D's NBMA address
  329.    information, and generates a positive NHRP Resolution Reply on D's
  330.    behalf.  NHRP Resolution Replies in this scenario are always marked
  331.  
  332.  
  333.  
  334. Luciani, Katz, Piscitello, Cole                                 [Page 6]
  335.  
  336. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  337.  
  338.  
  339.    as "authoritative".  The NHRP Resolution Reply packet contains the
  340.    address resolution information for station D which is to be sent back
  341.    to S.  Note that if station D is not on the NBMA subnetwork, the next
  342.    hop internetwork layer address will be that of the egress router
  343.    through which packets for station D are forwarded.
  344.  
  345.    A transit NHS receiving an NHRP Resolution Reply may cache the
  346.    address resolution information contained therein.  To a subsequent
  347.    NHRP Resolution Request, this NHS may respond with the cached, "non-
  348.    authoritative" address resolution information if the NHS is permitted
  349.    to do so (see Sections 5.2.2 and 6.2 for more information on non-
  350.    authoritative versus authoritative NHRP Resolution Replies).  Non-
  351.    authoritative NHRP Resolution Replies are distinguished from
  352.    authoritative NHRP Resolution Replies so that if a communication
  353.    attempt based on non-authoritative information fails, a source
  354.    station can choose to send an authoritative NHRP Resolution Request.
  355.    NHSs MUST NOT respond to authoritative NHRP Resolution Requests with
  356.    cached information.
  357.  
  358.    If the determination is made that no NHS in the NBMA subnetwork can
  359.    reply to the NHRP Resolution Request for D then a negative NHRP
  360.    Resolution Reply (NAK) is returned.  This occurs when (a) no next-hop
  361.    resolution information is available for station D from any NHS, or
  362.    (b) an NHS is unable to forward the NHRP Resolution Request (e.g.,
  363.    connectivity is lost).
  364.  
  365.    NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies,
  366.    and NHRP Error Indications follow a routed path in the same fashion
  367.    that NHRP Resolution Requests and NHRP Resolution Replies do.
  368.    Specifically, "requests" and "indications" follow the routed path
  369.    from Source Protocol Address (which is the address of the station
  370.    initiating the communication) to the Destination Protocol Address.
  371.    "Replies", on the other hand, follow the routed path from the
  372.    Destination Protocol Address back to the Source Protocol Address with
  373.    the following exceptions: in the case of a NHRP Registration Reply
  374.    and in the case of an NHC initiated NHRP Purge Request, the packet is
  375.    always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if
  376.    one does not exists then one MUST be created.
  377.  
  378.    NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA
  379.    subnetwork however further study is being done in this area (see
  380.    Section 7).   Thus, the internetwork layer data traffic out of and
  381.    into an NBMA subnetwork always traverses an internetwork layer router
  382.    at its border.
  383.  
  384.    NHRP optionally provides a mechanism to send a NHRP Resolution Reply
  385.    which contains aggregated address resolution information. For
  386.    example, suppose that router X is the next hop from station S to
  387.  
  388.  
  389.  
  390. Luciani, Katz, Piscitello, Cole                                 [Page 7]
  391.  
  392. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  393.  
  394.  
  395.    station D and that X is an egress router for all stations sharing an
  396.    internetwork layer address prefix with station D.  When an NHRP
  397.    Resolution Reply is generated in response to a NHRP Resolution
  398.    Request, the responder may augment the internetwork layer address of
  399.    station D with a prefix length (see Section 5.2.0.1).  A subsequent
  400.    (non-authoritative) NHRP Resolution Request for some destination that
  401.    shares an internetwork layer address prefix (for the number of bits
  402.    specified in the prefix length) with D may be satisfied with this
  403.    cached information.  See section 6.2 regarding caching issues.
  404.  
  405.    To dynamically detect subnetwork-layer filtering in NBMA subnetworks
  406.    (e.g., X.25 closed user group facility, or SMDS address screens), to
  407.    trace the routed path that an NHRP packet takes, or to provide loop
  408.    detection and diagnostic capabilities, a "Route Record" may be
  409.    included in NHRP packets (see Sections 5.3.2 and 5.3.3).  The Route
  410.    Record extensions are the NHRP Forward Transit NHS Record Extension
  411.    and the NHRP Reverse Transit NHS Record Extension.  They contain the
  412.    internetwork (and subnetwork layer) addresses of all intermediate
  413.    NHSs between source and destination and between destination and
  414.    source respectively.  When a source station is unable to communicate
  415.    with the responder (e.g., an attempt to open an SVC fails), it may
  416.    attempt to do so successively with other subnetwork layer addresses
  417.    in the NHRP Forward Transit NHS Record Extension until it succeeds
  418.    (if authentication policy permits such action).  This approach can
  419.    find a suitable egress point in the presence of subnetwork-layer
  420.    filtering (which may be source/destination sensitive, for instance,
  421.    without necessarily creating separate logical NBMA subnetworks) or
  422.    subnetwork-layer congestion (especially in connection-oriented
  423.    media).
  424.  
  425.  
  426. 3. Deployment
  427.  
  428.    NHRP Resolution Requests traverse one or more hops within an NBMA
  429.    subnetwork before reaching the station that is expected to generate a
  430.    response.  Each station, including the source station, chooses a
  431.    neighboring NHS to which it will forward the NHRP Resolution Request.
  432.    The NHS selection procedure typically involves applying a destination
  433.    protocol layer address to the protocol layer routing table which
  434.    causes a routing decision to be returned.  This routing decision is
  435.    then used to forward the NHRP Resolution Request to the downstream
  436.    NHS. The destination protocol layer address previously mentioned is
  437.    carried within the NHRP Resolution Request packet.  Note that even
  438.    though a protocol layer address was used to acquire a routing
  439.    decision, NHRP packets are not encapsulated within a protocol layer
  440.    header but rather are carried at the NBMA layer using the
  441.    encapsulation described in Section 5.
  442.  
  443.  
  444.  
  445.  
  446. Luciani, Katz, Piscitello, Cole                                 [Page 8]
  447.  
  448. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  449.  
  450.  
  451.    Each NHS/router examines the NHRP Resolution Request packet on its
  452.    way toward the destination.  Each NHS which the NHRP packet traverses
  453.    on the way to the packet's destination might modify the packet (e.g.,
  454.    updating the Forward Record extension).  Ignoring error situations,
  455.    the NHRP Resolution Request eventually arrives at a station that is
  456.    to generate an NHRP Resolution Reply.  This responding station
  457.    "serves" the destination.  The responding station generates an NHRP
  458.    Resolution Reply using the source protocol address from within the
  459.    NHRP packet to determine where the NHRP Resolution Reply should be
  460.    sent.
  461.  
  462.    Rather than use routing to determine the next hop for an NHRP packet,
  463.    an NHS may use other applicable means (such as static configuration
  464.    information ) in order to determine to which neighboring NHSs to
  465.    forward the NHRP Resolution Request packet as long as such other
  466.    means would not cause the NHRP packet to arrive at an NHS which is
  467.    not along the routed path.  The use of static configuration
  468.    information for this purpose is beyond the scope of this document.
  469.  
  470.    The NHS serving a particular destination must lie along the routed
  471.    path to that destination.  In practice, this means that all egress
  472.    routers must double as NHSs serving the destinations beyond them, and
  473.    that hosts on the NBMA subnetwork are served by routers that double
  474.    as NHSs.  Also, this implies that forwarding of NHRP packets within
  475.    an NBMA subnetwork requires a contiguous deployment of NHRP capable
  476.    routers.  It is important that, in a given LIS/LAG which is using
  477.    NHRP, all NHSs within the LIS/LAG have at least some portion of their
  478.    resolution databases synchronized so that a packet arriving at one
  479.    router/NHS in a given LIS/LAG will be forwarded in the same fashion
  480.    as a packet arriving at a different router/NHS for the given LIS/LAG.
  481.    One method, among others, is to use the Server Cache Synchronization
  482.    Protocol (SCSP) [12].  It is RECOMMENDED that SCSP be the method used
  483.    when a LIS/LAG contains two or more router/NHSs.
  484.  
  485.    During migration to NHRP, it cannot be expected that all routers
  486.    within the NBMA subnetwork are NHRP capable.  Thus, NHRP traffic
  487.    which would otherwise need to be forwarded through such routers can
  488.    be expected to be dropped due to the NHRP packet not being
  489.    recognized.  In this case, NHRP will be unable to establish any
  490.    transit paths whose discovery requires the traversal of the non-NHRP
  491.    speaking routers.  If the client has tried and failed to acquire a
  492.    cut through path then the client should use the network layer routed
  493.    path as a default.
  494.  
  495.  
  496.    If an NBMA technology offers a group, an anycast, or a multicast
  497.    addressing feature then the NHC may be configured with such an
  498.    address which would be assigned to the appropriate NHSs.  The NHC
  499.  
  500.  
  501.  
  502. Luciani, Katz, Piscitello, Cole                                 [Page 9]
  503.  
  504. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  505.  
  506.  
  507.    might then submit NHRP Resolution Requests to such an address,
  508.    eliciting a response from one or more NHSs, depending on the response
  509.    strategy selected.  Note that the constraints described in Section 2
  510.    regarding directly sending NHRP Resolution Reply may apply.
  511.  
  512.    When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined
  513.    for the NHC directly to the NHC.  That is, the NHRP message MUST NOT
  514.    transit through any NHS which is not serving the NHC when the NHRP
  515.    message is currently at an NHS which does serve the NHC (this, of
  516.    course, assumes the NHRP message is destined for the NHC).  Further,
  517.    an NHS which serves an NHC SHOULD have a direct NBMA level connection
  518.    to that NHC (see Section 5.2.3 and 5.2.4 for examples).
  519.  
  520.    With the exception of NHRP Registration Requests (see Section 5.2.3
  521.    and 5.2.4 for details of the NHRP Registration Request case), an NHC
  522.    MUST send NHRP messages over a direct NBMA level connection between
  523.    the serving NHS and the served NHC.
  524.  
  525.    It may not be desirable to maintain semi-permanent NBMA level
  526.    connectivity between the NHC and the NHS.   In this case, when NBMA
  527.    level connectivity is initially setup between the NHS and the NHC (as
  528.    described in Section 5.2.4), the NBMA address of the NHS should be
  529.    obtained through the NBMA level signaling technology.  This address
  530.    should be stored for future use in setting up subsequent NBMA level
  531.    connections.  A somewhat more information rich technique to obtain
  532.    the address information (and more) of the serving NHS would be for
  533.    the NHC to include the Responder Address extension (see Section
  534.    5.3.1) in the NHRP Registration Request and to store the information
  535.    returned to the NHC in the Responder Address extension which is
  536.    subsequently included in the NHRP Registration Reply.  Note also
  537.    that, in practice, a client's default router should also be its NHS;
  538.    thus a client may be able to know the NBMA address of its NHS from
  539.    the configuration which was already required for the client to be
  540.    able to communicate.  Further, as mentioned in Section 4, NHCs may be
  541.    configured with the addressing information of one or more NHSs.
  542.  
  543.  
  544. 4. Configuration
  545.  
  546.    Next Hop Clients
  547.  
  548.      An NHC connected to an NBMA subnetwork MAY be configured with the
  549.      Protocol address(es) and NBMA address(es) of its NHS(s).  The
  550.      NHS(s) will likely also represent the NHC's default or peer
  551.      routers, so their NBMA addresses may be obtained from the NHC's
  552.      existing configuration.  If the NHC is attached to several
  553.      subnetworks (including logical NBMA subnetworks), the NHC should
  554.      also be configured to receive routing information from its NHS(s)
  555.  
  556.  
  557.  
  558. Luciani, Katz, Piscitello, Cole                                [Page 10]
  559.  
  560. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  561.  
  562.  
  563.      and peer routers so that it can determine which internetwork layer
  564.      networks are reachable through which subnetworks.
  565.  
  566.    Next Hop Servers
  567.  
  568.      An NHS is configured with knowledge of its own internetwork layer
  569.      and NBMA addresses.  An NHS MAY also be configured with a set of
  570.      internetwork layer address prefixes that correspond to the
  571.      internetwork layer addresses of the stations it serves. The NBMA
  572.      addresses of the stations served by the NHS may be learned via NHRP
  573.      Registration packets.
  574.  
  575.      If a served NHC is attached to several subnetworks, the
  576.      router/route-server coresident with the serving NHS may also need
  577.      to be configured to advertise routing information to such NHCs.
  578.  
  579.      If an NHS acts as an egress router for stations connected to other
  580.      subnetworks than the NBMA subnetwork, the NHS must, in addition to
  581.      the above, be configured to exchange routing information between
  582.      the NBMA subnetwork and these other subnetworks.
  583.  
  584.      In all cases, routing information is exchanged using conventional
  585.      intra-domain and/or inter-domain routing protocols.
  586.  
  587.  
  588. 5. NHRP Packet Formats
  589.  
  590.    This section describes the format of NHRP packets.  In the following,
  591.    unless otherwise stated explicitly, the unqualified term "request"
  592.    refers generically to any of the NHRP packet types which are
  593.    "requests".  Further, unless otherwise stated explicitly, the
  594.    unqualified term "reply" refers generically to any of the NHRP packet
  595.    types which are "replies".
  596.  
  597.    An NHRP packet consists of a Fixed Part, a Mandatory Part, and an
  598.    Extensions Part.  The Fixed Part is common to all NHRP packet types.
  599.    The Mandatory Part MUST be present, but varies depending on packet
  600.    type.  The Extensions Part also varies depending on packet type, and
  601.    need not be present.
  602.  
  603.    The length of the Fixed Part is fixed at 20 octets.  The length of
  604.    the Mandatory Part is determined by the contents of the extensions
  605.    offset field (ar$extoff).  If ar$extoff=0x0 then the mandatory part
  606.    length is equal to total packet length (ar$pktsz) minus 20 otherwise
  607.    the mandatory part length is equal to ar$extoff minus 20.  The length
  608.    of the Extensions Part is implied by ar$pktsz minus ar$extoff.  NHSs
  609.    may increase the size of an NHRP packet as a result of extension
  610.    processing, but not beyond the offered maximum packet size of the
  611.  
  612.  
  613.  
  614. Luciani, Katz, Piscitello, Cole                                [Page 11]
  615.  
  616. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  617.  
  618.  
  619.    NBMA network.
  620.  
  621.    NHRP packets are actually members of a wider class of address mapping
  622.    and management protocols being developed by the IETF. A specific
  623.    encapsulation, based on the native formats used on the particular
  624.    NBMA network over which NHRP is carried, indicates the generic IETF
  625.    mapping and management protocol. For example, SMDS networks always
  626.    use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet
  627.    is preceded by the following LLC/SNAP encapsulation:
  628.  
  629.    [0xAA-AA-03] [0x00-00-5E] [0x00-03]
  630.  
  631.    The first three octets are LLC, indicating that SNAP follows.  The
  632.    SNAP OUI portion is the IANA's OUI, and the SNAP PID portion
  633.    identifies the mapping and management protocol. A field in the Fixed
  634.    Header following the encapsulation indicates that it is NHRP.
  635.  
  636.    ATM uses either LLC/SNAP encapsulation of each packet (including
  637.    NHRP), or uses no encapsulation on VCs dedicated to a single protocol
  638.    (see [7]).  Frame Relay and X.25 both use NLPID/SNAP encapsulation or
  639.    identification of NHRP, using a NLPID of 0x0080 and the same SNAP
  640.    contents as above (see [8], [9]).
  641.  
  642.    Fields marked "unused" MUST be set to zero on transmission, and
  643.    ignored on receipt.
  644.  
  645.    Most packet types (ar$op.type) have both internetwork layer
  646.    protocol-independent fields and protocol-specific fields. The
  647.    protocol type/snap fields (ar$pro.type/snap) qualify the format of
  648.    the protocol-specific fields.
  649.  
  650.  
  651. 5.1 NHRP Fixed Header
  652.  
  653.    The Fixed Part of the NHRP packet contains those elements of the NHRP
  654.    packet which are always present and do not vary in size with the type
  655.    of packet.
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670. Luciani, Katz, Piscitello, Cole                                [Page 12]
  671.  
  672. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  673.  
  674.  
  675.  
  676.     0                   1                   2                   3
  677.     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
  678.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  679.    |            ar$afn             |          ar$pro.type          |
  680.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  681.    |                          ar$pro.snap                          |
  682.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  683.    |  ar$pro.snap  |   ar$hopcnt   |            ar$pktsz           |
  684.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  685.    |           ar$chksum           |            ar$extoff          |
  686.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  687.    | ar$op.version |   ar$op.type  |    ar$shtl    |    ar$sstl    |
  688.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  689.  
  690.  
  691.    ar$afn
  692.      Defines the type of "link layer" addresses being carried.  This
  693.      number is taken from the 'address family number' list specified in
  694.      [6].  This field has implications to the coding of ar$shtl and
  695.      ar$sstl as described below.
  696.  
  697.    ar$pro.type
  698.      field is a 16 bit unsigned integer representing the following
  699.      number space:
  700.  
  701.        0x0000 to 0x00FF  Protocols defined by the equivalent NLPIDs.
  702.        0x0100 to 0x03FF  Reserved for future use by the IETF.
  703.        0x0400 to 0x04FF  Allocated for use by the ATM Forum.
  704.        0x0500 to 0x05FF  Experimental/Local use.
  705.        0x0600 to 0xFFFF  Protocols defined by the equivalent Ethertypes.
  706.  
  707.      (based on the observations that valid Ethertypes are never smaller
  708.      than 0x600, and NLPIDs never larger than 0xFF.)
  709.  
  710.    ar$pro.snap
  711.      When ar$pro.type has a value of 0x0080, a SNAP encoded extension is
  712.      being used to encode the protocol type. This snap extension is
  713.      placed in the ar$pro.snap field.  This is termed the 'long form'
  714.      protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be
  715.      zero on transmit and ignored on receive. The ar$pro.type field
  716.      itself identifies the protocol being referred to. This is termed
  717.      the 'short form' protocol ID.
  718.  
  719.      In all cases, where a protocol has an assigned number in the
  720.      ar$pro.type space (excluding 0x0080) the short form MUST be used
  721.      when transmitting NHRP messages; i.e., if Ethertype or NLPID
  722.      codings exist then they are used on transmit rather than the
  723.  
  724.  
  725.  
  726. Luciani, Katz, Piscitello, Cole                                [Page 13]
  727.  
  728. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  729.  
  730.  
  731.      ethertype.   If both Ethertype and NLPID codings exist then when
  732.      transmitting NHRP messages, the Ethertype coding MUST be used (this
  733.      is consistent with RFC 1483 coding).  So, for example, the
  734.      following codings exist for IP:
  735.  
  736.        SNAP:      ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00
  737.        NLPID:     ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00
  738.        Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00
  739.  
  740.      and thus, since the Ethertype coding exists, it is used in
  741.      preference.
  742.  
  743.    ar$hopcnt
  744.      The Hop count indicates the maximum number of NHSs that an NHRP
  745.      packet is allowed to traverse before being discarded.  This field
  746.      is used in a similar fashion to the way that a TTL is used in an IP
  747.      packet and should be set accordingly.  Each NHS decrements the TTL
  748.      as the NHRP packet transits the NHS on the way to the next hop
  749.      along the routed path to the destination.  If an NHS receives an
  750.      NHRP packet which it would normally forward to a next hop and that
  751.      packet contains an ar$hopcnt set to zero then the NHS sends an
  752.      error indication message back to the source protocol address
  753.      stating that the hop count has been exceeded (see Section 5.2.7)
  754.      and the NHS drops the packet in error;  however, an error
  755.      indication is never sent as a result of receiving an error
  756.      indication.  When a responding NHS replies to an NHRP request, that
  757.      NHS places a value in ar$hopcnt as if it were sending a request of
  758.      its own.
  759.  
  760.    ar$pktsz
  761.      The total length of the NHRP packet, in octets (excluding link
  762.      layer encapsulation).
  763.  
  764.    ar$chksum
  765.      The standard IP checksum over the entire SCSP packet starting at
  766.      the fixed header.  If the packet is an odd number of bytes in
  767.      length then this calculation is performed as if a byte set to 0x00
  768.      is appended to the end of the packet.
  769.  
  770.    ar$extoff
  771.      This field identifies the existence and location of NHRP
  772.      extensions.  If this field is 0 then no extensions exist otherwise
  773.      this field represents the offset from the beginning of the NHRP
  774.      packet (i.e., starting from the ar$afn field) of the first
  775.      extension.
  776.  
  777.    ar$op.version
  778.      This field indicates what version of generic address mapping and
  779.  
  780.  
  781.  
  782. Luciani, Katz, Piscitello, Cole                                [Page 14]
  783.  
  784. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  785.  
  786.  
  787.      management protocol is represented by this message.
  788.  
  789.        0               MARS protocol [11].
  790.        1               NHRP as defined in this document.
  791.        0x02 - 0xEF     Reserved for future use by the IETF.
  792.        0xF0 - 0xFE     Allocated for use by the ATM Forum.
  793.        0xFF            Experimental/Local use.
  794.  
  795.    ar$op.type
  796.      When ar$op.version == 1, this is the NHRP packet type: NHRP
  797.      Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration
  798.      Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP
  799.      Purge Reply(6), or NHRP Error Indication(7).  Use of NHRP packet
  800.      Types in the range 128 to 255 are reserved for research or use in
  801.      other protocol development and will be administered by IANA (see
  802.      Section 9).
  803.  
  804.    ar$shtl
  805.      Type & length of source NBMA address interpreted in the context of
  806.      the 'address family number'[6] indicated by ar$afn.  See below for
  807.      more details.
  808.  
  809.    ar$sstl
  810.      Type & length of source NBMA subaddress interpreted in the context
  811.      of the 'address family number'[6] indicated by ar$afn.  When an
  812.      NBMA technology has no concept of a subaddress, the subaddress
  813.      length is always coded ar$sstl = 0 and no storage is allocated for
  814.      the subaddress in the appropriate mandatory part.  See below for
  815.      more details.
  816.  
  817.    Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
  818.    T/L) and subnetwork layer subaddresses type/length fields (e.g.,
  819.    ar$sstl, Cli SAddr T/L) are coded as follows:
  820.  
  821.     7 6 5 4 3 2 1 0
  822.    +-+-+-+-+-+-+-+-+
  823.    |0|x|  length   |
  824.    +-+-+-+-+-+-+-+-+
  825.  
  826.    The most significant bit is reserved and MUST be set to zero. The
  827.    second most significant bit (x) is a flag indicating whether the
  828.    address being referred to is in:
  829.  
  830.       - NSAP format (x = 0).
  831.       - Native E.164 format (x = 1).
  832.  
  833.    For NBMA technologies that use neither NSAP nor E.164 format
  834.    addresses, x = 0 SHALL be used to indicate the native form for the
  835.  
  836.  
  837.  
  838. Luciani, Katz, Piscitello, Cole                                [Page 15]
  839.  
  840. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  841.  
  842.  
  843.    particular NBMA technology.
  844.  
  845.    If the NBMA network is ATM and a subaddress (e.g., Source NBMA
  846.    SubAddress, Client NBMA SubAddress) is to be included in any part of
  847.    the NHRP packet then ar$afn MUST be set to 0x000F; further, the
  848.    subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
  849.    T/L) and subnetwork layer subaddress type/length fields (e.g.,
  850.    ar$sstl, Cli SAddr T/L) MUST be coded as in [11].  If the NBMA
  851.    network is ATM and no subaddress field is to be included in any part
  852.    of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008
  853.    (E.164) accordingly.
  854.  
  855.    The bottom 6 bits is an unsigned integer value indicating the length
  856.    of the associated NBMA address in octets. If this value is zero the
  857.    flag x is ignored.
  858.  
  859.  
  860. 5.2.0 Mandatory Part
  861.  
  862.    The Mandatory Part of the NHRP packet contains the operation specific
  863.    information (e.g., NHRP Resolution Request/Reply, etc.) and variable
  864.    length data which is pertinent to the packet type.
  865.  
  866. 5.2.0.1 Mandatory Part Format
  867.  
  868.    Sections 5.2.1 through 5.2.6 have a very similar mandatory part.
  869.    This mandatory part includes a common header and zero or more Client
  870.    Information Entries (CIEs). Section 5.2.7 has a different format
  871.    which is specified in that section.
  872.  
  873.    The common header looks like the following:
  874.  
  875.     0                   1                   2                   3
  876.     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
  877.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  878.    | Src Proto Len | Dst Proto Len |           Flags               |
  879.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  880.    |                         Request ID                            |
  881.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  882.    |            Source NBMA Address (variable length)              |
  883.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  884.    |          Source NBMA Subaddress (variable length)             |
  885.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  886.    |          Source Protocol Address (variable length)            |
  887.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  888.    |       Destination  Protocol Address (variable length)         |
  889.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  890.  
  891.  
  892.  
  893.  
  894. Luciani, Katz, Piscitello, Cole                                [Page 16]
  895.  
  896. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  897.  
  898.  
  899.    And the CIEs have the following format:
  900.  
  901.     0                   1                   2                   3
  902.     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
  903.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  904.    |    Code       | Prefix Length |         unused                |
  905.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  906.    |  Maximum Transmission Unit    |        Holding Time           |
  907.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  908.    |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
  909.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  910.    |            Client NBMA Address (variable length)              |
  911.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  912.    |           Client NBMA Subaddress (variable length)            |
  913.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  914.    |          Client Protocol Address (variable length)            |
  915.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  916.                         .....................
  917.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  918.    |    Code       | Prefix Length |         unused                |
  919.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  920.    |  Maximum Transmission Unit    |        Holding Time           |
  921.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  922.    |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
  923.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  924.    |            Client NBMA Address (variable length)              |
  925.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  926.    |           Client NBMA Subaddress (variable length)            |
  927.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  928.    |          Client Protocol Address (variable length)            |
  929.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  930.  
  931.    The meanings of the fields are as follows:
  932.  
  933.    Src Proto Len
  934.      This field holds the length in octets of the Source Protocol
  935.      Address.
  936.  
  937.    Dst Proto Len
  938.      This field holds the length in octets of the Destination Protocol
  939.      Address.
  940.  
  941.    Flags
  942.      These flags are specific to the given message type and they are
  943.      explained in each section.
  944.  
  945.    Request ID
  946.      A value which, when coupled with the address of the source,
  947.  
  948.  
  949.  
  950. Luciani, Katz, Piscitello, Cole                                [Page 17]
  951.  
  952. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  953.  
  954.  
  955.      provides a unique identifier for the information contained in a
  956.      "request" packet.  This value is copied directly from an "request"
  957.      packet into the associated "reply".  When a sender of a "request"
  958.      receives "reply", it will compare the Request ID and source address
  959.      information in the received "reply" against that found in its
  960.      outstanding "request" list.  When a match is found then the
  961.      "request" is considered to be acknowledged.
  962.  
  963.      The value is taken from a 32 bit counter that is incremented each
  964.      time a new "request" is transmitted.  The same value MUST be used
  965.      when resending a "request", i.e., when a "reply" has not been
  966.      received for a "request" and a retry is sent after an appropriate
  967.      interval.
  968.  
  969.      It is RECOMMENDED that the initial value for this number be 0.  A
  970.      node MAY reuse a sequence number if and only if the reuse of the
  971.      sequence number is not precluded by use of a particular method of
  972.      synchronization (e.g., as described in Appendix A).
  973.  
  974.    The NBMA address/subaddress form specified below allows combined
  975.    E.164/NSAPA form of NBMA addressing. For NBMA technologies without a
  976.    subaddress concept, the subaddress field is always ZERO length and
  977.    ar$sstl = 0.
  978.  
  979.    Source NBMA Address
  980.      The Source NBMA address field is the address of the source station
  981.      which is sending the "request". If the field's length as specified
  982.      in ar$shtl is 0 then no storage is allocated for this address at
  983.      all.
  984.  
  985.    Source NBMA SubAddress
  986.      The Source NBMA subaddress field is the address of the source
  987.      station which is sending the "request".  If the field's length as
  988.      specified in ar$sstl is 0 then no storage is allocated for this
  989.      address at all.
  990.  
  991.    For those NBMA technologies which have a notion of "Calling Party
  992.    Addresses", the Source NBMA Addresses above are the addresses used
  993.    when signaling for an SVC.
  994.  
  995.    "Requests" and "indications" follow the routed path from Source
  996.    Protocol Address to the Destination Protocol Address. "Replies", on
  997.    the other hand, follow the routed path from the Destination Protocol
  998.    Address back to the Source Protocol Address with the following
  999.    exceptions: in the case of a NHRP Registration Reply and in the case
  1000.    of an NHC initiated NHRP Purge Request, the packet is always returned
  1001.    via a direct VC (see Sections 5.2.4 and 5.2.5).
  1002.  
  1003.  
  1004.  
  1005.  
  1006. Luciani, Katz, Piscitello, Cole                                [Page 18]
  1007.  
  1008. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1009.  
  1010.  
  1011.    Source Protocol Address
  1012.      This is the protocol address of the station which is sending the
  1013.      "request".  This is also the protocol address of the station toward
  1014.      which a "reply" packet is sent.
  1015.  
  1016.    Destination Protocol Address
  1017.      This is the protocol address of the station toward which a
  1018.      "request" packet is sent.
  1019.  
  1020.    Code
  1021.      This field is message specific.  See the relevant message sections
  1022.      below.  In general, this field is a NAK code; i.e., when the field
  1023.      is 0 in a reply then the packet is acknowledging a request and if
  1024.      it contains any other value the packet contains a negative
  1025.      acknowledgment.
  1026.  
  1027.    Prefix Length
  1028.      This field is message specific.  See the relevant message sections
  1029.      below.  In general, however, this fields is used to indicate that
  1030.      the information carried in an NHRP message pertains to an
  1031.      equivalence class of internetwork layer addresses rather than just
  1032.      a single internetwork layer address specified. All internetwork
  1033.      layer addresses that match the first "Prefix Length" bit positions
  1034.      for the specific internetwork layer address are included in the
  1035.      equivalence class.  If this field is set to 0x00 then this field
  1036.      MUST be ignored and no equivalence information is assumed (note
  1037.      that 0x00 is thus equivalent to 0xFF).
  1038.  
  1039.  
  1040.    Maximum Transmission Unit
  1041.      This field gives the maximum transmission unit for the relevant
  1042.      client station.  If this value is 0 then either the default MTU is
  1043.      used or the MTU negotiated via signaling is used if such
  1044.      negotiation is possible for the given NBMA.
  1045.  
  1046.    Holding Time
  1047.      The Holding Time field specifies the number of seconds for which
  1048.      the Next Hop NBMA information specified in the CIE is considered to
  1049.      be valid.  Cached information SHALL be discarded when the holding
  1050.      time expires.  This field must be set to 0 on a NAK.
  1051.  
  1052.    Cli Addr T/L
  1053.      Type & length of next hop NBMA address specified in the CIE.  This
  1054.      field is interpreted in the context of the 'address family
  1055.      number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM).
  1056.  
  1057.    Cli SAddr T/L
  1058.      Type & length of next hop NBMA subaddress specified in the CIE.
  1059.  
  1060.  
  1061.  
  1062. Luciani, Katz, Piscitello, Cole                                [Page 19]
  1063.  
  1064. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1065.  
  1066.  
  1067.      This field is interpreted in the context of the 'address family
  1068.      number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes
  1069.      the address an E.164 and the subaddress an ATM Forum NSAP address).
  1070.      When an NBMA technology has no concept of a subaddress, the
  1071.      subaddress is always null with a length of 0.  When the address
  1072.      length is specified as 0 no storage is allocated for the address.
  1073.  
  1074.    Cli Proto Len
  1075.      This field holds the length in octets of the Client Protocol
  1076.      Address specified in the CIE.
  1077.  
  1078.    Preference
  1079.      This field specifies the preference for use of the specific CIE
  1080.      relative to other CIEs.  Higher values indicate higher preference.
  1081.      Action taken when multiple CIEs have equal or highest preference
  1082.      value is a local matter.
  1083.  
  1084.    Client NBMA Address
  1085.      This is the client's NBMA address.
  1086.  
  1087.    Client NBMA SubAddress
  1088.      This is the client's NBMA subaddress.
  1089.  
  1090.    Client Protocol Address
  1091.      This is the client's internetworking layer address specified.
  1092.  
  1093.    Note that an NHS may cache source address binding information from an
  1094.    NHRP Resolution Request if and only if the conditions described in
  1095.    Section 6.2 are met for the NHS.  In all other cases, source address
  1096.    binding information appearing in an NHRP message MUST NOT be cached.
  1097.  
  1098.  
  1099. 5.2.1 NHRP Resolution Request
  1100.  
  1101.    The NHRP Resolution Request packet has a Type code of 1. Its
  1102.    mandatory part is coded as described in Section 5.2.0.1 and the
  1103.    message specific meanings of the fields are as follows:
  1104.  
  1105.    Flags - The flags field is coded as follows:
  1106.  
  1107.       0                   1
  1108.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1109.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1110.      |Q|A|D|U|S|       unused        |
  1111.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1112.  
  1113.      Q
  1114.        Set if the station sending the NHRP Resolution Request is a
  1115.  
  1116.  
  1117.  
  1118. Luciani, Katz, Piscitello, Cole                                [Page 20]
  1119.  
  1120. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1121.  
  1122.  
  1123.        router; clear if the it is a host.
  1124.  
  1125.      A
  1126.        This bit is set in a NHRP Resolution Request if only
  1127.        authoritative next hop information is desired and is clear
  1128.        otherwise.  See the NHRP Resolution Reply section below for
  1129.        further details on the "A" bit and its usage.
  1130.  
  1131.      D
  1132.        Unused (clear on transmit)
  1133.  
  1134.      U
  1135.        This is the Uniqueness bit. This bit aids in duplicate address
  1136.        detection.  When this bit is set in an NHRP Resolution Request
  1137.        and one or more entries exist in the NHS cache which meet the
  1138.        requirements of the NHRP Resolution Request then only the CIE in
  1139.        the NHS's cache with this bit set will be returned.  Note that
  1140.        even if this bit was set at registration time, there may still be
  1141.        multiple CIEs that might fulfill the NHRP Resolution Request
  1142.        because an entire subnet can be registered through use of the
  1143.        Prefix Length in the CIE and the address of interest might be
  1144.        within such a subnet. If the "uniqueness" bit is set and the
  1145.        responding NHS has one or more cache entries which match the
  1146.        request but no such cache entry has the "uniqueness" bit set,
  1147.        then the NHRP Resolution Reply returns with a NAK code of "13 -
  1148.        Binding Exists But Is Not Unique" and no CIE is included.  If a
  1149.        client wishes  to  receive  non- unique  Next  Hop Entries, then
  1150.        the client must have the "uniqueness" bit set to zero in its NHRP
  1151.        Resolution Request. Note that when this bit is set in an NHRP
  1152.        Registration Request, only a single CIE may be specified in the
  1153.        NHRP Registration Request and that CIE must have the Prefix
  1154.        Length field set to 0xFF.
  1155.  
  1156.      S
  1157.        Set if the binding between the Source Protocol Address and the
  1158.        Source NBMA information in the NHRP Resolution Request is
  1159.        guaranteed to be stable and accurate (e.g., these addresses are
  1160.        those of an ingress router which is connected to an ethernet stub
  1161.        network or the NHC is an NBMA attached host).
  1162.  
  1163.    Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP
  1164.    Resolution Request.  If one is specified then that entry carries the
  1165.    pertinent information for the client sourcing the NHRP Resolution
  1166.    Request.  Usage of the CIE in the NHRP Resolution Request is
  1167.    described below:
  1168.  
  1169.      Prefix Length
  1170.        If a CIE is specified in the NHRP Resolution Request then the
  1171.  
  1172.  
  1173.  
  1174. Luciani, Katz, Piscitello, Cole                                [Page 21]
  1175.  
  1176. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1177.  
  1178.  
  1179.        Prefix Length field may be used to qualify the widest acceptable
  1180.        prefix which may be used to satisfy the NHRP Resolution Request.
  1181.        In the case of NHRP Resolution Request/Reply, the Prefix Length
  1182.        specifies the equivalence class of addresses which match the
  1183.        first "Prefix Length" bit positions of the Destination Protocol
  1184.        Address.  If the "U" bit is set in the common header then this
  1185.        field MUST be set to 0xFF.
  1186.  
  1187.      Maximum Transmission Unit
  1188.        This field gives the maximum transmission unit for the source
  1189.        station.  A possible use of this field in the NHRP Resolution
  1190.        Request packet is for the NHRP Resolution Requester to ask for a
  1191.        target MTU.
  1192.  
  1193.      Holding Time
  1194.        The Holding Time specified in the one CIE permitted to be
  1195.        included in an NHRP Resolution Request is the amount of time
  1196.        which the source address binding information in the NHRP
  1197.        Resolution Request is permitted to cached by transit and
  1198.        responding NHSs.  Note that this field may only have a non-zero
  1199.        value if the S bit is set.
  1200.  
  1201.      All other fields in the CIE MUST be ignored and SHOULD be set to 0.
  1202.  
  1203.    The Destination Protocol Address in the common header of the
  1204.    Mandatory Part of this message contains the protocol address of the
  1205.    station for which resolution is desired.  An NHC MUST send the NHRP
  1206.    Resolution Request directly to one of its serving NHSs (see Section 3
  1207.    for more information).
  1208.  
  1209.  
  1210. 5.2.2 NHRP Resolution Reply
  1211.  
  1212.    The NHRP Resolution Reply packet has a Type code of 2. CIEs
  1213.    correspond to Next Hop Entries in an NHS's cache which match the
  1214.    criteria in the NHRP Resolution Request.  Its mandatory part is coded
  1215.    as described in Section 5.2.0.1.  The message specific meanings of
  1216.    the fields are as follows:
  1217.  
  1218.    Flags - The flags field is coded as follows:
  1219.  
  1220.       0                   1
  1221.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1222.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1223.      |Q|A|D|U|S|       unused        |
  1224.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1225.  
  1226.      Q
  1227.  
  1228.  
  1229.  
  1230. Luciani, Katz, Piscitello, Cole                                [Page 22]
  1231.  
  1232. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1233.  
  1234.  
  1235.        Copied from the NHRP Resolution Request.  Set if the NHRP
  1236.        Resolution Requester is a router;  clear if it is a host.
  1237.  
  1238.      A
  1239.        Set if the next hop CIE in the NHRP Resolution Reply is
  1240.        authoritative; clear if the NHRP Resolution Reply is non-
  1241.        authoritative.
  1242.  
  1243.        When an NHS receives a NHRP Resolution Request for authoritative
  1244.        information for which it is the authoritative source, it MUST
  1245.        respond with a NHRP Resolution Reply containing all and only
  1246.        those next hop CIEs which are contained in the NHS's cache which
  1247.        both match the criteria of the NHRP Resolution Request and are
  1248.        authoritative cache entries.  An NHS is an authoritative source
  1249.        for a NHRP Resolution Request if the information in the NHS's
  1250.        cache matches the NHRP Resolution Request criteria and that
  1251.        information was obtained through a NHRP Registration Request or
  1252.        through synchronization with an NHS which obtained this
  1253.        information through a NHRP Registration Request.  An
  1254.        authoritative cache entry is one which is obtained through a NHRP
  1255.        Registration Request or through synchronization with an NHS which
  1256.        obtained this information through a NHRP Registration Request.
  1257.  
  1258.        An NHS obtains non-authoritative CIEs through promiscuous
  1259.        listening to NHRP packets other than NHRP Registrations which are
  1260.        directed at it.  A NHRP Resolution Request which indicates a
  1261.        request for non-authoritative information should cause a NHRP
  1262.        Resolution Reply which contains all entries in the replying NHS's
  1263.        cache (i.e., both authoritative and non-authoritative) which
  1264.        match the criteria specified in the request.
  1265.  
  1266.      D
  1267.        Set if the association between destination and the associate next
  1268.        hop information included in all CIEs of the NHRP Resolution Reply
  1269.        is guaranteed to be stable for the lifetime of the information
  1270.        (the holding time).  This is the case if the Next Hop protocol
  1271.        address in a CIE identifies the destination (though it may be
  1272.        different in value than the Destination address if the
  1273.        destination system has multiple addresses) or if the destination
  1274.        is not connected directly to the NBMA subnetwork but the egress
  1275.        router to that destination is guaranteed to be stable (such as
  1276.        when the destination is immediately adjacent to the egress router
  1277.        through a non-NBMA interface).
  1278.  
  1279.      U
  1280.        This is the Uniqueness bit. See the NHRP Resolution Request
  1281.        section above for details.  When this bit is set, only one CIE is
  1282.        included since only one unique binding should exist in an NHS's
  1283.  
  1284.  
  1285.  
  1286. Luciani, Katz, Piscitello, Cole                                [Page 23]
  1287.  
  1288. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1289.  
  1290.  
  1291.        cache.
  1292.  
  1293.      S
  1294.        Copied from NHRP Resolution Request message.
  1295.  
  1296.    One or more CIEs are specified in the NHRP Resolution Reply. Each CIE
  1297.    contains NHRP next hop information which the responding NHS has
  1298.    cached and which matches the parameters specified in the NHRP
  1299.    Resolution Request.  If no match is found by the NHS issuing the NHRP
  1300.    Resolution Reply then a single CIE is enclosed with the a CIE Code
  1301.    set appropriately (see below) and all other fields MUST be ignored
  1302.    and SHOULD be set to 0.  In order to facilitate the use of NHRP by
  1303.    minimal client implementations, the first CIE MUST contain the next
  1304.    hop with the highest preference value so that such an implementation
  1305.    need parse only a single CIE.
  1306.  
  1307.      Code
  1308.        If this field is set to zero then this packet contains a
  1309.        positively acknowledged NHRP Resolution Reply.  If this field
  1310.        contains any other value then this message contains an NHRP
  1311.        Resolution Reply NAK which means that an appropriate
  1312.        internetworking layer to NBMA address binding was not available
  1313.        in the responding NHS's cache.  If NHRP Resolution Reply contains
  1314.        a Client Information Entry with a NAK Code other than 0 then it
  1315.        MUST NOT contain any other CIE.  Currently defined NAK Codes are
  1316.        as follows:
  1317.  
  1318.  
  1319.        4 - Administratively Prohibited
  1320.  
  1321.          An NHS may refuse an NHRP Resolution Request attempt for
  1322.          administrative reasons (due to policy constraints or routing
  1323.          state).  If so, the NHS MUST send an NHRP Resolution Reply
  1324.          which contains a NAK code of 4.
  1325.  
  1326.        5 - Insufficient Resources
  1327.  
  1328.          If an NHS cannot serve a station due to a lack of resources
  1329.          (e.g., can't store sufficient information to send a purge if
  1330.          routing changes), the NHS MUST reply with a NAKed NHRP
  1331.          Resolution Reply which contains a NAK code of 5.
  1332.  
  1333.        12 - No Internetworking Layer Address to NBMA Address Binding
  1334.        Exists
  1335.  
  1336.          This code states that there were absolutely no internetworking
  1337.          layer address to NBMA address bindings found in the responding
  1338.          NHS's cache.
  1339.  
  1340.  
  1341.  
  1342. Luciani, Katz, Piscitello, Cole                                [Page 24]
  1343.  
  1344. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1345.  
  1346.  
  1347.        13 - Binding Exists But Is Not Unique
  1348.  
  1349.          This code states that there were one or more internetworking
  1350.          layer address to NBMA address bindings found in the responding
  1351.          NHS's cache, however none of them had the uniqueness bit set.
  1352.  
  1353.      Prefix Length
  1354.        In the case of NHRP Resolution Reply, the Prefix Length specifies
  1355.        the equivalence class of addresses which match the first "Prefix
  1356.        Length" bit positions of the Destination Protocol Address.
  1357.  
  1358.      Holding Time
  1359.        The Holding Time specified in a CIE of an NHRP Resolution Reply
  1360.        is the amount of time remaining before the expiration of the
  1361.        client information which is cached at the replying NHS.  It is
  1362.        not the value which was registered by the client.
  1363.  
  1364.      The remainder of the fields for the CIE for each next hop are
  1365.      filled out as they were defined when the next hop was registered
  1366.      with the responding NHS (or one of the responding NHS's
  1367.      synchronized servers) via the NHRP Registration Request.
  1368.  
  1369.    Load-splitting may be performed when more than one Client Information
  1370.    Entry is returned to a requester when equal preference values are
  1371.    specified.  Also, the alternative addresses may be used in case of
  1372.    connectivity failure in the NBMA subnetwork (such as a failed call
  1373.    attempt in connection-oriented NBMA subnetworks).
  1374.  
  1375.    Any extensions present in the NHRP Resolution Request packet MUST be
  1376.    present in the NHRP Resolution Reply even if the extension is non-
  1377.    Compulsory.
  1378.  
  1379.    If an unsolicited NHRP Resolution Reply packet is received, an Error
  1380.    Indication of type Invalid NHRP Resolution Reply Received SHOULD be
  1381.    sent in response.
  1382.  
  1383.    When an NHS that serves a given NHC receives an NHRP Resolution Reply
  1384.    destined for that NHC then the NHS must MUST send the NHRP Resolution
  1385.    Reply directly to the NHC (see Section 3).
  1386.  
  1387.  
  1388. 5.2.3 NHRP Registration Request
  1389.  
  1390.    The NHRP Registration Request is sent from a station to an NHS to
  1391.    notify the NHS of the station's NBMA information.  It has a Type code
  1392.    of 3. Each CIE corresponds to Next Hop information which is to be
  1393.    cached at an NHS.  The mandatory part of an NHRP Registration Request
  1394.    is coded as described in Section 5.2.0.1.  The message specific
  1395.  
  1396.  
  1397.  
  1398. Luciani, Katz, Piscitello, Cole                                [Page 25]
  1399.  
  1400. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1401.  
  1402.  
  1403.    meanings of the fields are as follows:
  1404.  
  1405.    Flags - The flags field is coded as follows:
  1406.  
  1407.       0                   1
  1408.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1409.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1410.      |U|         unused              |
  1411.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1412.  
  1413.      U
  1414.        This is the Uniqueness bit. When set in an NHRP Registration
  1415.        Request, this bit indicates that the registration of the protocol
  1416.        address is unique within the confines of the set of synchronized
  1417.        NHSs.  This "uniqueness" qualifier MUST be stored in the NHS/NHC
  1418.        cache.  Any attempt to register a binding between the protocol
  1419.        address and an NBMA address when this bit is set MUST be rejected
  1420.        with a Code of "14 - Unique Internetworking Layer Address Already
  1421.        Registered" if the replying NHS already has a cache entry for the
  1422.        protocol address and the cache entry has the "uniqueness" bit
  1423.        set.  A registration of a CIE's information is rejected when the
  1424.        CIE is returned with the Code field set to anything other than
  1425.        0x00.  See the description of the uniqueness bit in NHRP
  1426.        Resolution Request section above for further details.  When this
  1427.        bit is set only, only one CIE MAY be included in the NHRP
  1428.        Registration Request.
  1429.  
  1430.  
  1431.    Request ID
  1432.      The request ID has the same meaning as described in Section
  1433.      5.2.0.1.  However, the request ID for NHRP Registrations which is
  1434.      maintained at each client MUST be kept in non-volatile memory so
  1435.      that when a client crashes and reregisters there will be no
  1436.      inconsistency in the NHS's database.  In order to reduce the
  1437.      overhead associated with updating non-volatile memory, the actual
  1438.      updating need not be done with every increment of the Request ID
  1439.      but could be done, for example, every 50 or 100 increments.  In
  1440.      this scenario, when a client crashes and reregisters it knows to
  1441.      add 100 to the value of the Request ID in the non-volatile memory
  1442.      before using the Request ID for subsequent registrations.
  1443.  
  1444.  
  1445.    One or more CIEs are specified in the NHRP Registration Request.
  1446.    Each CIE contains next hop information which a client is attempting
  1447.    to register with its servers.  Generally, all fields in CIEs enclosed
  1448.    in NHRP Registration Requests are coded as described in Section
  1449.    5.2.0.1.  However, if a station is only registering itself with the
  1450.    NHRP Registration Request then it MAY code the Cli Addr T/L, Cli
  1451.  
  1452.  
  1453.  
  1454. Luciani, Katz, Piscitello, Cole                                [Page 26]
  1455.  
  1456. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1457.  
  1458.  
  1459.    SAddr T/L, and Cli Proto Len as zero which signifies that the client
  1460.    address information is to be taken from the source information in the
  1461.    common header (see Section 5.2.0.1).  Below, further clarification is
  1462.    given for some fields in a CIE in the context of a NHRP Registration
  1463.    Request.
  1464.  
  1465.      Code
  1466.        This field is set to 0x00 in NHRP Registration Requests.
  1467.  
  1468.      Prefix Length
  1469.  
  1470.        This field may be used in a NHRP Registration Request to register
  1471.        equivalence information for the Client Protocol Address specified
  1472.        in the CIE of an NHRP Registration Request In the case of NHRP
  1473.        Registration Request, the Prefix Length specifies the equivalence
  1474.        class of addresses which match the first "Prefix Length" bit
  1475.        positions of the Client Protocol Address.  If the "U" bit is set
  1476.        in the common header then this field MUST be set to 0xFF.
  1477.  
  1478.    The NHRP Registration Request is used to register an NHC's NHRP
  1479.    information with its NHSs.  If an NHC is configured with the protocol
  1480.    address of a serving NHS then the NHC may place the NHS's protocol
  1481.    address in the Destination Protocol Address field of the NHRP
  1482.    Registration Request common header otherwise the NHC must place its
  1483.    own protocol address in the Destination Protocol Address field.
  1484.  
  1485.    When an NHS receives an NHRP Registration Request which has the
  1486.    Destination Protocol Address field set to an address which belongs to
  1487.    a LIS/LAG for which the NHS is serving then if the Destination
  1488.    Protocol Address field is equal to the Source Protocol Address field
  1489.    (which would happen if the NHC put its protocol address in the
  1490.    Destination Protocol Address) or the Destination Protocol Address
  1491.    field is equal to the protocol address of the NHS then the NHS
  1492.    processes the NHRP Registration Request after doing appropriate error
  1493.    checking (including any applicable policy checking).
  1494.  
  1495.    When an NHS receives an NHRP Registration Request which has the
  1496.    Destination Protocol Address field set to an address which does not
  1497.    belong to a LIS/LAG for which the NHS is serving then the NHS
  1498.    forwards the packet down the routed path toward the appropriate
  1499.    LIS/LAG.
  1500.  
  1501.    When an NHS receives an NHRP Registration Request which has the
  1502.    Destination Protocol Address field set to an address which belongs to
  1503.    a LIS/LAG for which the NHS is serving then if the Destination
  1504.    Protocol Address field does not equal the Source Protocol Address
  1505.    field and the Destination Protocol Address field does not equal the
  1506.    protocol address of the NHS then the NHS forwards the message to the
  1507.  
  1508.  
  1509.  
  1510. Luciani, Katz, Piscitello, Cole                                [Page 27]
  1511.  
  1512. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1513.  
  1514.  
  1515.    appropriate NHS within the LIS/LAG as specified by Destination
  1516.    Protocol Address field.
  1517.  
  1518.    It is possible that a misconfigured station will attempt to register
  1519.    with the wrong NHS (i.e., one that cannot serve it due to policy
  1520.    constraints or routing state).  If this is the case, the NHS MUST
  1521.    reply with a NAK-ed Registration Reply of type Can't Serve This
  1522.    Address.
  1523.  
  1524.    If an NHS cannot serve a station due to a lack of resources, the NHS
  1525.    MUST reply with a NAK-ed Registration Reply of type Registration
  1526.    Overflow.
  1527.  
  1528.    In order to keep the registration entry from being discarded, the
  1529.    station MUST re-send the NHRP Registration Request packet often
  1530.    enough to refresh the registration, even in the face of occasional
  1531.    packet loss. It is recommended that the NHRP Registration Request
  1532.    packet be sent at an interval equal to one-third of the Holding Time
  1533.    specified therein.
  1534.  
  1535.  
  1536. 5.2.4 NHRP Registration Reply
  1537.  
  1538.    The NHRP Registration Reply is sent by an NHS to a client in response
  1539.    to that client's NHRP Registration Request. If the Code field of a
  1540.    CIE in the NHRP Registration Reply has anything other than zero in it
  1541.    then the NHRP Registration Reply is a NAK otherwise the reply is an
  1542.    ACK.  The NHRP Registration Reply has a Type code of 4.
  1543.  
  1544.    An NHRP Registration Reply is formed from an NHRP Registration
  1545.    Request by changing the type code to 4, updating the CIE Code field,
  1546.    and filling in the appropriate extensions if they exist.  The message
  1547.    specific meanings of the fields are as follows:
  1548.  
  1549.    Attempts to register the information in the CIEs of an NHRP
  1550.    Registration Request may fail for various reasons.  If this is the
  1551.    case then each failed attempt to register the information in a CIE of
  1552.    an NHRP Registration Request is logged in the associated NHRP
  1553.    Registration Reply by setting the CIE Code field to the appropriate
  1554.    error code as shown below:
  1555.  
  1556.      CIE Code
  1557.  
  1558.        0 - Successful Registration
  1559.  
  1560.          The information in the CIE was successfully registered with the
  1561.          NHS.
  1562.  
  1563.  
  1564.  
  1565.  
  1566. Luciani, Katz, Piscitello, Cole                                [Page 28]
  1567.  
  1568. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1569.  
  1570.  
  1571.        4 - Administratively Prohibited
  1572.  
  1573.          An NHS may refuse an NHRP Registration Request attempt for
  1574.          administrative reasons (due to policy constraints or routing
  1575.          state).  If so, the NHS MUST send an NHRP Registration Reply
  1576.          which contains a NAK code of 4.
  1577.  
  1578.        5 - Insufficient Resources
  1579.  
  1580.          If an NHS cannot serve a station due to a lack of resources,
  1581.          the NHS MUST reply with a NAKed NHRP Registration Reply which
  1582.          contains a NAK code of 5.
  1583.  
  1584.        14 - Unique Internetworking Layer Address Already Registered
  1585.          If a client tries to register a protocol address to NBMA
  1586.          address binding with the uniqueness bit on and the protocol
  1587.          address already exists in the NHS's cache then if that cache
  1588.          entry also has the uniqueness bit on then this NAK Code is
  1589.          returned in the CIE in the NHRP Registration Reply.
  1590.  
  1591.    Due to the possible existence of asymmetric routing, an NHRP
  1592.    Registration Reply may not be able to merely follow the routed path
  1593.    back to the source protocol address specified in the common header of
  1594.    the NHRP Registration Reply.  As a result, there MUST exist a direct
  1595.    NBMA level connection between the NHC and its NHS on which to send
  1596.    the NHRP Registration Reply before NHRP Registration Reply may be
  1597.    returned to the NHC.  If such a connection does not exist then the
  1598.    NHS must setup such a connection to the NHC by using the source NBMA
  1599.    information supplied in the common header of the NHRP Registration
  1600.    Request.
  1601.  
  1602.  
  1603. 5.2.5 NHRP Purge Request
  1604.  
  1605.    The NHRP Purge Request packet is sent in order to invalidate cached
  1606.    information in a station.  The NHRP Purge Request packet has a type
  1607.    code of 5.  The mandatory part of an NHRP Purge Request is coded as
  1608.    described in Section 5.2.0.1.  The message specific meanings of the
  1609.    fields are as follows:
  1610.  
  1611.    Flags - The flags field is coded as follows:
  1612.  
  1613.       0                   1
  1614.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1615.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1616.      |N|         unused              |
  1617.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1618.  
  1619.  
  1620.  
  1621.  
  1622. Luciani, Katz, Piscitello, Cole                                [Page 29]
  1623.  
  1624. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1625.  
  1626.  
  1627.      N
  1628.        When set, this bit tells the receiver of the NHRP Purge Request
  1629.        that the requester does not expect to receive an NHRP Purge
  1630.        Reply.  If an unsolicited NHRP Purge Reply is received by a
  1631.        station where that station is identified in the Source Protocol
  1632.        Address of the packet then that packet must be ignored.
  1633.  
  1634.    One or more CIEs are specified in the NHRP Purge Request.  Each CIE
  1635.    contains next hop information which is to be purged from an NHS/NHC
  1636.    cache.  Generally, all fields in CIEs enclosed in NHRP Purge Requests
  1637.    are coded as described in Section 5.2.0.1.  Below, further
  1638.    clarification is given for some fields in a CIE in the context of a
  1639.    NHRP Purge Request.
  1640.  
  1641.      Code
  1642.        This field is set to 0x00 in NHRP Purge Requests.
  1643.  
  1644.      Prefix Length
  1645.  
  1646.        In the case of NHRP Purge Requests, the Prefix Length specifies
  1647.        the equivalence class of addresses which match the first "Prefix
  1648.        Length" bit positions of the Client Protocol Address specified in
  1649.        the CIE.  All next hop information which contains a protocol
  1650.        address which matches an element of this equivalence class is to
  1651.        be purged from the receivers cache.
  1652.  
  1653.      The Maximum Transmission Unit and Preference fields of the CIE are
  1654.      coded as zero.  The Holding Time should be coded as zero but there
  1655.      may be some utility in supplying a "short" holding time to be
  1656.      applied to the matching next hop information before that
  1657.      information would be purged; this usage is for further study. The
  1658.      Client Protocol Address field and the Cli Proto Len field MUST be
  1659.      filled in.  The Client Protocol Address is filled in with the
  1660.      protocol address to be purged from the receiving station's cache
  1661.      while the Cli Proto Len is set the length of the purged client's
  1662.      protocol address.  All remaining fields in the CIE MAY be set to
  1663.      zero although the client NBMA information (and associated length
  1664.      fields) MAY be specified to narrow the scope of the NHRP Purge
  1665.      Request if requester desires.  However, the receiver of an NHRP
  1666.      Purge Request may choose to ignore the Client NBMA information if
  1667.      it is supplied.
  1668.  
  1669.    An NHRP Purge Request packet is sent from an NHS to a station to
  1670.    cause it to delete previously cached information.  This is done when
  1671.    the information may be no longer valid (typically when the NHS has
  1672.    previously provided next hop information for a station that is not
  1673.    directly connected to the NBMA subnetwork, and the egress point to
  1674.    that station may have changed).
  1675.  
  1676.  
  1677.  
  1678. Luciani, Katz, Piscitello, Cole                                [Page 30]
  1679.  
  1680. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1681.  
  1682.  
  1683.    An NHRP Purge Request packet may also be sent from an NHC to an NHS
  1684.    with which the NHC had previously registered.  This allows for an NHC
  1685.    to invalidate its registration with NHRP before it would otherwise
  1686.    expire via the holding timer. If an NHC does not have knowledge of a
  1687.    protocol address of a serving NHS then the NHC must place its own
  1688.    protocol address in the Destination Protocol Address field and
  1689.    forward the packet along the routed path.  Otherwise, the NHC must
  1690.    place the protocol address of a serving NHS in this field.
  1691.  
  1692.    Serving NHSs may need to send one or more new NHRP Purge Requests as
  1693.    a result of receiving a purge from one of their served NHCs since the
  1694.    NHS may have previously responded to NHRP Resolution Requests for
  1695.    that NHC's NBMA information.  These purges are "new" in that they are
  1696.    sourced by the NHS and not the NHC;  that is, for each NHC that
  1697.    previously sent a NHRP Resolution Request for the purged NHC NBMA
  1698.    information, an NHRP Purge Request is sent which contains the Source
  1699.    Protocol/NBMA Addresses of the NHS and the Destination Protocol
  1700.    Address of the NHC which previously sent an NHRP Resolution Request
  1701.    prior to the purge.
  1702.  
  1703.    The station sending the NHRP Purge Request MAY periodically
  1704.    retransmit the NHRP Purge Request until either NHRP Purge Request is
  1705.    acknowledged or until the holding time of the information being
  1706.    purged has expired. Retransmission strategies for NHRP Purge Requests
  1707.    are a local matter.
  1708.  
  1709.    When a station receives an NHRP Purge Request, it MUST discard any
  1710.    previously cached information that matches the information in the
  1711.    CIEs.
  1712.  
  1713.    An NHRP Purge Reply MUST be returned for the NHRP Purge Request even
  1714.    if the station does not have a matching cache entry assuming that the
  1715.    "N" bit is off in the NHRP Purge Request.
  1716.  
  1717.    If the station wishes to reestablish communication with the
  1718.    destination shortly after receiving an NHRP Purge Request, it should
  1719.    make an authoritative NHRP Resolution Request in order to avoid any
  1720.    stale cache entries that might be present in intermediate NHSs (See
  1721.    section 6.2.2.).  It is recommended that authoritative NHRP
  1722.    Resolution Requests be made for the duration of the holding time of
  1723.    the old information.
  1724.  
  1725.  
  1726. 5.2.6 NHRP Purge Reply
  1727.  
  1728.    The NHRP Purge Reply packet is sent in order to assure the sender of
  1729.    an NHRP Purge Request that all cached information of the specified
  1730.    type has been purged from the station sending the reply.  The NHRP
  1731.  
  1732.  
  1733.  
  1734. Luciani, Katz, Piscitello, Cole                                [Page 31]
  1735.  
  1736. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1737.  
  1738.  
  1739.    Purge Reply has a type code of 6.
  1740.  
  1741.    An NHRP Purge Reply is formed from an NHRP Purge Request by merely
  1742.    changing the type code in the request to 6.  The packet is then
  1743.    returned to the requester after filling in the appropriate extensions
  1744.    if they exist.
  1745.  
  1746.  
  1747. 5.2.7  NHRP Error Indication
  1748.  
  1749.    The NHRP Error Indication is used to convey error indications to the
  1750.    sender of an NHRP packet.  It has a type code of 7.  The Mandatory
  1751.    Part has the following format:
  1752.  
  1753.  
  1754.     0                   1                   2                   3
  1755.     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
  1756.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1757.    | Src Proto Len | Dst Proto Len |            unused             |
  1758.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1759.    |           Error Code          |        Error Offset           |
  1760.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1761.    |            Source NBMA Address (variable length)              |
  1762.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1763.    |          Source NBMA Subaddress (variable length)             |
  1764.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1765.    |          Source Protocol Address (variable length)            |
  1766.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1767.    |       Destination  Protocol Address (variable length)         |
  1768.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1769.    |       Contents of NHRP Packet in error (variable length)      |
  1770.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1771.  
  1772.    Src Proto Len
  1773.      This field holds the length in octets of the Source Protocol
  1774.      Address.
  1775.  
  1776.    Dst Proto Len
  1777.      This field holds the length in octets of the Destination Protocol
  1778.      Address.
  1779.  
  1780.    Error Code
  1781.      An error code indicating the type of error detected, chosen from
  1782.      the following list:
  1783.  
  1784.        1 - Unrecognized Extension
  1785.  
  1786.          When the Compulsory bit of an extension in NHRP packet is set,
  1787.  
  1788.  
  1789.  
  1790. Luciani, Katz, Piscitello, Cole                                [Page 32]
  1791.  
  1792. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1793.  
  1794.  
  1795.          the NHRP packet cannot be processed unless the extension has
  1796.          been processed.  The responder MUST return an NHRP Error
  1797.          Indication of type Unrecognized Extension if it is incapable of
  1798.          processing the extension.  However, if a transit NHS (one which
  1799.          is not going to generate a reply) detects an unrecognized
  1800.          extension, it SHALL ignore the extension.
  1801.  
  1802.        3 - NHRP Loop Detected
  1803.  
  1804.          A Loop Detected error is generated when it is determined that
  1805.          an NHRP packet is being forwarded in a loop.
  1806.  
  1807.        6 - Protocol Address Unreachable
  1808.  
  1809.          This error occurs when a packet it moving along the routed path
  1810.          and it reaches a point such that the protocol address of
  1811.          interest is not reachable.
  1812.  
  1813.        7 - Protocol Error
  1814.  
  1815.          A generic packet processing error has occurred (e.g., invalid
  1816.          version number, invalid protocol type, failed checksum, etc.)
  1817.  
  1818.        8 - NHRP SDU Size Exceeded
  1819.  
  1820.          If the SDU size of the NHRP packet exceeds the MTU size of the
  1821.          NBMA network then this error is returned.
  1822.  
  1823.        9 - Invalid Extension
  1824.  
  1825.          If an NHS finds an extension in a packet which is inappropriate
  1826.          for the packet type, an error is sent back to the sender with
  1827.          Invalid Extension as the code.
  1828.  
  1829.        10 - Invalid NHRP Resolution Reply Received
  1830.  
  1831.          If a client receives a NHRP Resolution Reply for a Next Hop
  1832.          Resolution Request which it believes it did not make then an
  1833.          error packet is sent to the station making the reply with an
  1834.          error code of Invalid Reply Received.
  1835.  
  1836.        11 - Authentication Failure
  1837.  
  1838.          If a received packet fails an authentication test then this
  1839.          error is returned.
  1840.  
  1841.        15 - Hop Count Exceeded
  1842.  
  1843.  
  1844.  
  1845.  
  1846. Luciani, Katz, Piscitello, Cole                                [Page 33]
  1847.  
  1848. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1849.  
  1850.  
  1851.          The hop count which was specified in the Fixed Header of an
  1852.          NHRP message has been exceeded.
  1853.  
  1854.    Error Offset
  1855.      The offset in octets into the original NHRP packet in which an
  1856.      error was detected.  This offset is calculated starting from the
  1857.      NHRP Fixed Header.
  1858.  
  1859.    Source NBMA Address
  1860.      The Source NBMA address field is the address of the station which
  1861.      observed the error.
  1862.  
  1863.    Source NBMA SubAddress
  1864.      The Source NBMA subaddress field is the address of the station
  1865.      which observed the error.  If the field's length as specified in
  1866.      ar$sstl is 0 then no storage is allocated for this address at all.
  1867.  
  1868.    Source Protocol Address
  1869.      This is the protocol address of the station which issued the Error
  1870.      packet.
  1871.  
  1872.    Destination Protocol Address
  1873.      This is the protocol address of the station which sent the packet
  1874.      which was found to be in error.
  1875.  
  1876.    An NHRP Error Indication packet SHALL NEVER be generated in response
  1877.    to another NHRP Error Indication packet.  When an NHRP Error
  1878.    Indication packet is generated, the offending NHRP packet SHALL be
  1879.    discarded.  In no case should more than one NHRP Error Indication
  1880.    packet be generated for a single NHRP packet.
  1881.  
  1882.    If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA
  1883.    and Source Protocol address fields of a transiting NHRP Error
  1884.    Indication packet then the NHS will quietly drop the packet and do
  1885.    nothing (this scenario would occur when the NHRP Error Indication
  1886.    packet was itself in a loop).
  1887.  
  1888.    Note that no extensions may be added to an NHRP Error Indication.
  1889.  
  1890.  
  1891. 5.3  Extensions Part
  1892.  
  1893.    The Extensions Part, if present, carries one or more extensions in
  1894.    {Type, Length, Value} triplets.
  1895.  
  1896.    Extensions have the following format:
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902. Luciani, Katz, Piscitello, Cole                                [Page 34]
  1903.  
  1904. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1905.  
  1906.  
  1907.     0                   1                   2                   3
  1908.     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
  1909.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1910.    |C|u|        Type               |        Length                 |
  1911.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1912.    |                         Value...                              |
  1913.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1914.  
  1915.    C
  1916.      "Compulsory."  If clear, and the NHS does not recognize the type
  1917.      code, the extension may safely be ignored.  If set, and the NHS
  1918.      does not recognize the type code, the NHRP "request" is considered
  1919.      to be in error.  (See below for details.)
  1920.  
  1921.    u
  1922.      Unused and must be set to zero.
  1923.  
  1924.    Type
  1925.      The extension type code (see below).  The extension type is not
  1926.      qualified by the Compulsory bit, but is orthogonal to it.
  1927.  
  1928.    Length
  1929.      The length in octets of the value (not including the Type and
  1930.      Length fields;  a null extension will have only an extension header
  1931.      and a length of zero).
  1932.  
  1933.    When extensions exist, the extensions list is terminated by the Null
  1934.    TLV, having Type = 0 and Length = 0.
  1935.  
  1936.    Extensions may occur in any order, but any particular extension type
  1937.    may occur only once in an NHRP packet unless explicitly stated to the
  1938.    contrary in the extensions definition.  For example, the vendor-
  1939.    private extension may occur multiple times in a packet in order to
  1940.    allow for extensions which do not share the same vendor ID to be
  1941.    represented.  It is RECOMMENDED that a given vendor include no more
  1942.    than one Vendor Private Extension.
  1943.  
  1944.    An NHS MUST NOT change the order of extensions.  That is, the order
  1945.    of extensions placed in an NHRP packet by an NHC (or by an NHS when
  1946.    an NHS sources a packet) MUST be preserved as the packet moves
  1947.    between NHSs.  Minimal NHC implementations MUST only recognize, but
  1948.    not necessarily parse, the Vendor Private extension and the End Of
  1949.    Extensions extension.  Extensions are only present in a "reply" if
  1950.    they were present in the corresponding "request" with the exception
  1951.    of Vendor Private extensions.  The previous statement is not intended
  1952.    to preclude the creation of NHS-only extensions which might be added
  1953.    to and removed from NHRP packets by the same NHS; such extensions
  1954.    MUST not be propagated to NHCs.
  1955.  
  1956.  
  1957.  
  1958. Luciani, Katz, Piscitello, Cole                                [Page 35]
  1959.  
  1960. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  1961.  
  1962.  
  1963.    The Compulsory bit provides for a means to add to the extension set.
  1964.    If the bit is set in an extension then the station responding to the
  1965.    NHRP message which contains that extension MUST be able to understand
  1966.    the extension (in this case, the station responding to the message is
  1967.    the station that would issue an NHRP reply in response to a NHRP
  1968.    request).  As a result, the responder MUST return an NHRP Error
  1969.    Indication of type Unrecognized Extension.  If the Compulsory bit is
  1970.    clear then the extension can be safely ignored; however, if an
  1971.    ignored extension is in a "request" then it MUST be returned,
  1972.    unchanged, in the corresponding "reply" packet type.
  1973.  
  1974.    If a transit NHS (one which is not going to generate a "reply")
  1975.    detects an unrecognized extension, it SHALL ignore the extension.  If
  1976.    the Compulsory bit is set, the transit NHS MUST NOT cache the
  1977.    information contained in the packet and MUST NOT identify itself as
  1978.    an egress router (in the Forward Record or Reverse Record
  1979.    extensions).  Effectively, this means, if a transit NHS encounters an
  1980.    extension which it cannot process and which has the Compulsory bit
  1981.    set then that NHS MUST NOT participate in any way in the protocol
  1982.    exchange other than acting as a forwarding agent.
  1983.  
  1984.    The NHRP extension Type space is subdivided to encourage use outside
  1985.    the IETF.
  1986.  
  1987.      0x0000 - 0x0FFF         Reserved for NHRP.
  1988.      0x1000 - 0x11FF         Allocated to the ATM Forum.
  1989.      0x1200 - 0x37FF         Reserved for the IETF.
  1990.      0x3800 - 0x3FFF         Experimental use.
  1991.  
  1992.    IANA will administer the ranges reserved for the IETF (see Section
  1993.    9). Values in the 'Experimental use' range have only local
  1994.    significance.
  1995.  
  1996.  
  1997. 5.3.0  The End Of Extensions
  1998.  
  1999.     Compulsory = 1
  2000.     Type = 0
  2001.     Length = 0
  2002.  
  2003.    When extensions exist, the extensions list is terminated by the End
  2004.    Of Extensions/Null TLV.
  2005.  
  2006.  
  2007. 5.3.1  Responder Address Extension
  2008.  
  2009.     Compulsory = 1
  2010.     Type = 3
  2011.  
  2012.  
  2013.  
  2014. Luciani, Katz, Piscitello, Cole                                [Page 36]
  2015.  
  2016. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2017.  
  2018.  
  2019.     Length = variable
  2020.  
  2021.    This extension is used to determine the address of the NHRP
  2022.    responder; i.e., the entity that generates the appropriate "reply"
  2023.    packet for a given "request" packet.  In the case of an NHRP
  2024.    Resolution Request, the station responding may be different (in the
  2025.    case of cached replies) than the system identified in the Next Hop
  2026.    field of the NHRP Resolution Reply.  Further, this extension may aid
  2027.    in detecting loops in the NHRP forwarding path.
  2028.  
  2029.    This extension uses a single CIE with the extension specific meanings
  2030.    of the fields set as follows:
  2031.  
  2032.    The Prefix Length fields MUST be set to 0 and ignored.
  2033.  
  2034.    CIE Code
  2035.      5 - Insufficient Resources
  2036.        If the responder to an NHRP Resolution Request is an egress point
  2037.        for the target of the address resolution request (i.e., it is one
  2038.        of the stations identified in the list of CIEs in an NHRP
  2039.        Resolution Reply) and the Responder Address extension is included
  2040.        in the NHRP Resolution Request and insufficient resources to
  2041.        setup a cut-through VC exist at the responder then the Code field
  2042.        of the Responder Address Extension is set to 5 in order to tell
  2043.        the client that a VC setup attempt would in all likelihood be
  2044.        rejected; otherwise this field MUST be coded as a zero.  NHCs MAY
  2045.        use this field to influence whether they attempt to setup a cut-
  2046.        through to the egress router.
  2047.  
  2048.    Maximum Transmission Unit
  2049.      This field gives the maximum transmission unit preferred by the
  2050.      responder.  If this value is 0 then either the default MTU is used
  2051.      or the MTU negotiated via signaling is used if such negotiation is
  2052.      possible for the given NBMA.
  2053.  
  2054.    Holding Time
  2055.      The Holding Time field specifies the number of seconds for which
  2056.      the NBMA information of the responser is considered to be valid.
  2057.      Cached information SHALL be discarded when the holding time
  2058.      expires.
  2059.  
  2060.    "Client Address" information is actually "Responder Address"
  2061.    information for this extension.  Thus, for example, Cli Addr T/L is
  2062.    the responder NBMA address type and length field.
  2063.  
  2064.    If a "requester" desires this information, the "requester" SHALL
  2065.    include this extension with a value of zero.  Note that this implies
  2066.    that no storage is allocated for the Holding Time and Type/Length
  2067.  
  2068.  
  2069.  
  2070. Luciani, Katz, Piscitello, Cole                                [Page 37]
  2071.  
  2072. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2073.  
  2074.  
  2075.    fields until the "Value" portion of the extension is filled out.
  2076.  
  2077.    If an NHS is generating a "reply" packet in response to a "request"
  2078.    containing this extension, the NHS SHALL include this extension,
  2079.    containing its protocol address in the "reply".  If an NHS has more
  2080.    than one protocol address, it SHALL use the same protocol address
  2081.    consistently in all of the Responder Address, Forward Transit NHS
  2082.    Record, and Reverse Transit NHS Record extensions.  The choice of
  2083.    which of several protocol address to include in this extension is a
  2084.    local matter.
  2085.  
  2086.    If an NHRP Resolution Reply packet being forwarded by an NHS contains
  2087.    a protocol address of that NHS in the Responder Address Extension
  2088.    then that NHS SHALL generate an NHRP Error Indication of type "NHRP
  2089.    Loop Detected" and discard the NHRP Resolution Reply.
  2090.  
  2091.    If an NHRP Resolution Reply packet is being returned by an
  2092.    intermediate NHS based on cached data, it SHALL place its own address
  2093.    in this extension (differentiating it from the address in the Next
  2094.    Hop field).
  2095.  
  2096.  
  2097. 5.3.2  NHRP Forward Transit NHS Record Extension
  2098.  
  2099.     Compulsory = 1
  2100.     Type = 4
  2101.     Length = variable
  2102.  
  2103.    The NHRP Forward Transit NHS record contains a list of transit NHSs
  2104.    through which a "request" has traversed.  Each NHS SHALL append to
  2105.    the extension a Forward Transit NHS element (as specified below)
  2106.    containing its Protocol address.  The extension length field and the
  2107.    ar$chksum fields SHALL be adjusted appropriately.
  2108.  
  2109.    The responding NHS, as described in Section 5.3.1, SHALL NOT update
  2110.    this extension.
  2111.  
  2112.    In addition, NHSs that are willing to act as egress routers for
  2113.    packets from the source to the destination SHALL include information
  2114.    about their NBMA Address.
  2115.  
  2116.    This extension uses a single CIE per NHS Record element with the
  2117.    extension specific meanings of the fields set as follows:
  2118.  
  2119.    The Prefix Length fields MUST be set to 0 and ignored.
  2120.  
  2121.    CIE Code
  2122.      5 - Insufficient Resources
  2123.  
  2124.  
  2125.  
  2126. Luciani, Katz, Piscitello, Cole                                [Page 38]
  2127.  
  2128. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2129.  
  2130.  
  2131.        If an NHRP Resolution Request contains an NHRP Forward Transit
  2132.        NHS Record Extension and insufficient resources to setup a cut-
  2133.        through VC exist at the current transit NHS then the CIE Code
  2134.        field for NHRP Forward Transit NHS Record Extension is set to 5
  2135.        in order to tell the client that a VC setup attempt would in all
  2136.        likelihood be rejected; otherwise this field MUST be coded as a
  2137.        zero.  NHCs MAY use this field to influence whether they attempt
  2138.        to setup a cut-through as described in Section 2.2.  Note that
  2139.        the NHRP Reverse Transit NHS Record Extension MUST always have
  2140.        this field set to zero.
  2141.  
  2142.    Maximum Transmission Unit
  2143.      This field gives the maximum transmission unit preferred by the
  2144.      transit NHS.  If this value is 0 then either the default MTU is
  2145.      used or the MTU negotiated via signaling is used if such
  2146.      negotiation is possible for the given NBMA.
  2147.  
  2148.    Holding Time
  2149.      The Holding Time field specifies the number of seconds for which
  2150.      the NBMA information of the transit NHS is considered to be valid.
  2151.      Cached information SHALL be discarded when the holding time
  2152.      expires.
  2153.  
  2154.    "Client Address" information is actually "Forward Transit NHS
  2155.    Address" information for this extension.  Thus, for example, Cli Addr
  2156.    T/L is the transit NHS NBMA address type and length field.
  2157.  
  2158.    If a "requester" wishes to obtain this information, it SHALL include
  2159.    this extension with a length of zero.  Note that this implies that no
  2160.    storage is allocated for the Holding Time and Type/Length fields
  2161.    until the "Value" portion of the extension is filled out.
  2162.  
  2163.    If an NHS has more than one Protocol address, it SHALL use the same
  2164.    Protocol address consistently in all of the Responder Address,
  2165.    Forward NHS Record, and Reverse NHS Record extensions.  The choice of
  2166.    which of several Protocol addresses to include in this extension is a
  2167.    local matter.
  2168.  
  2169.    If a "request" that is being forwarded by an NHS contains the
  2170.    Protocol Address of that NHS in one of the Forward Transit NHS
  2171.    elements then the NHS SHALL generate an NHRP Error Indication of type
  2172.    "NHRP Loop Detected" and discard the "request".
  2173.  
  2174.  
  2175. 5.3.3  NHRP Reverse Transit NHS Record Extension
  2176.  
  2177.     Compulsory = 1
  2178.     Type = 5
  2179.  
  2180.  
  2181.  
  2182. Luciani, Katz, Piscitello, Cole                                [Page 39]
  2183.  
  2184. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2185.  
  2186.  
  2187.     Length = variable
  2188.  
  2189.    The NHRP Reverse Transit NHS record contains a list of transit NHSs
  2190.    through which a "reply" has traversed.  Each NHS SHALL append a
  2191.    Reverse Transit NHS element (as specified below) containing its
  2192.    Protocol address to this extension.  The extension length field and
  2193.    ar$chksum SHALL be adjusted appropriately.
  2194.  
  2195.    The responding NHS, as described in Section 5.3.1, SHALL NOT update
  2196.    this extension.
  2197.  
  2198.    In addition, NHSs that are willing to act as egress routers for
  2199.    packets from the source to the destination SHALL include information
  2200.    about their NBMA Address.
  2201.  
  2202.  
  2203.    This extension uses a single CIE per NHS Record element with the
  2204.    extension specific meanings of the fields set as follows:
  2205.  
  2206.    The CIE Code and Prefix Length fields MUST be set to 0 and ignored.
  2207.  
  2208.    Maximum Transmission Unit
  2209.      This field gives the maximum transmission unit preferred by the
  2210.      transit NHS.  If this value is 0 then either the default MTU is
  2211.      used or the MTU negotiated via signaling is used if such
  2212.      negotiation is possible for the given NBMA.
  2213.  
  2214.    Holding Time
  2215.      The Holding Time field specifies the number of seconds for which
  2216.      the NBMA information of the transit NHS is considered to be valid.
  2217.      Cached information SHALL be discarded when the holding time
  2218.      expires.
  2219.  
  2220.    "Client Address" information is actually "Reverse Transit NHS
  2221.    Address" information for this extension.  Thus, for example, Cli Addr
  2222.    T/L is the transit NHS NBMA address type and length field.
  2223.  
  2224.    If a "requester" wishes to obtain this information, it SHALL include
  2225.    this extension with a length of zero.  Note that this implies that no
  2226.    storage is allocated for the Holding Time and Type/Length fields
  2227.    until the "Value" portion of the extension is filled out.
  2228.  
  2229.    If an NHS has more than one Protocol address, it SHALL use the same
  2230.    Protocol address consistently in all of the Responder Address,
  2231.    Forward NHS Record, and Reverse NHS Record extensions.  The choice of
  2232.    which of several Protocol addresses to include in this extension is a
  2233.    local matter.
  2234.  
  2235.  
  2236.  
  2237.  
  2238. Luciani, Katz, Piscitello, Cole                                [Page 40]
  2239.  
  2240. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2241.  
  2242.  
  2243.    If a "reply" that is being forwarded by an NHS contains the Protocol
  2244.    Address of that NHS in one of the Reverse Transit NHS elements then
  2245.    the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop
  2246.    Detected" and discard the "reply".
  2247.  
  2248.    Note that this information may be cached at intermediate NHSs;  if
  2249.    so, the cached value SHALL be used when generating a reply.
  2250.  
  2251.  
  2252. 5.3.4 NHRP Authentication Extension
  2253.  
  2254.    Compulsory = 1 Type = 7 Length = variable
  2255.  
  2256.    The NHRP Authentication Extension is carried in NHRP packets to
  2257.    convey authentication information between NHRP speakers.  The
  2258.    Authentication Extension may be included in any NHRP "request" or
  2259.    "reply" only.
  2260.  
  2261.    The authentication is always done pairwise on an NHRP hop-by-hop
  2262.    basis;  i.e., the authentication extension is regenerated at each
  2263.    hop.  If a received packet fails the authentication test, the station
  2264.    SHALL generate an Error Indication of type "Authentication Failure"
  2265.    and discard the packet. Note that one possible authentication failure
  2266.    is the lack of an Authentication Extension; the presence or absence
  2267.    of the Authentication Extension is a local matter.
  2268.  
  2269. 5.3.4.1 Header Format
  2270.  
  2271.    The authentication header has the following format:
  2272.  
  2273.    0                   1                   2                   3
  2274.    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
  2275.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2276.    |   Reserved                    | Security Parameter Index (SPI)|
  2277.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2278.    |               Src Addr...                                     |
  2279.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2280.    |                                                               |
  2281.    +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
  2282.    |                                                               |
  2283.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2284.  
  2285.    Security Parameter Index (SPI) can be thought of as an index into a
  2286.    table that maintains the keys and other information such as hash
  2287.    algorithm. Src and Dst communicate either offline using manual keying
  2288.    or online using a key management protocol to populate this table. The
  2289.    sending NHRP entity always allocates the SPI and the parameters
  2290.    associated with it.
  2291.  
  2292.  
  2293.  
  2294. Luciani, Katz, Piscitello, Cole                                [Page 41]
  2295.  
  2296. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2297.  
  2298.  
  2299.    Src Addr a variable length field is the address assigned to the
  2300.    outgoing interface. The length of the addr is obtained from the
  2301.    source protocol length field in the mandatory part of the NHRP
  2302.    header.  The tuple <spi, src addr> uniquely identifies the key and
  2303.    other parameters that are used in authentication.
  2304.  
  2305.    The length of the authentication data field  is dependent on the hash
  2306.    algorithm used. The data field contains the keyed hash calculated
  2307.    over the entire NHRP payload. The authentication data field is zeroed
  2308.    out before the hash is calculated.
  2309.  
  2310. 5.3.4.2 SPI and Security Parameters Negotiation
  2311.  
  2312.    SPI's can be negotiated either manually or using an Internet Key
  2313.    Management protocol. Manual keying MUST be supported. The following
  2314.    parameters are associated with the tuple <SPI, src>- lifetime,
  2315.    Algorithm, Key. Lifetime indicates the duration in seconds for which
  2316.    the key is valid. In case of manual keying, this duration can be
  2317.    infinite. Also, in order to better support manual keying, there may
  2318.    be multiple tuples active at the same time (Dst being the same).
  2319.  
  2320.    Algorithm specifies the hash algorithm agreed upon by the two
  2321.    entities. HMAC-MD5-128 [16] is the default algorithm. Other
  2322.    algorithms MAY be supported by defining new values. IANA will assign
  2323.    the numbers to identify the algorithm being used (see Section 9).
  2324.  
  2325.  
  2326.    Any Internet standard key management protocol MAY so be used to
  2327.    negotiate the SPI and parameters.
  2328.  
  2329.  
  2330.  
  2331. 5.3.4.3 Message Processing
  2332.  
  2333.    At the time of adding the authentication extension header, src looks
  2334.    up in a table to fetch the SPI and the security parameters based on
  2335.    the outgoing interface address. If there are no entries in the table
  2336.    and if there is support for key management, the src initiates the key
  2337.    management protocol to fetch the necessary parameters. The src
  2338.    constructs the Authentication Extension payload and calculates the
  2339.    hash by zeroing authentication data field. The result replaces in the
  2340.    zeroed authentication data field. The src address field in the
  2341.    payload is the IP address assigned to the outgoing interface.
  2342.  
  2343.    If key management is not supported and authentication is mandatory,
  2344.    the packet is dropped and this information is logged.
  2345.  
  2346.    On the receiving end, dst fetches the parameters based on the SPI and
  2347.  
  2348.  
  2349.  
  2350. Luciani, Katz, Piscitello, Cole                                [Page 42]
  2351.  
  2352. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2353.  
  2354.  
  2355.    the ip address in the authentication extension payload. The
  2356.    authentication data field is extracted before zeroing out to
  2357.    calculate the hash. It computes the hash on the entire payload and if
  2358.    the hash does not match, then an "abnormal event" has occurred.
  2359.  
  2360. 5.3.4.4 Security Considerations
  2361.  
  2362.    It is important that the keys chosen are strong as the security of
  2363.    the entire system depends on the keys being chosen properly and the
  2364.    correct implementation of the algorithms.
  2365.  
  2366.    The security is performed on a hop by hop basis. The data received
  2367.    can be trusted only so much as one trusts all the entities in the
  2368.    path traversed.
  2369.  
  2370.  
  2371. 5.3.5  NHRP Vendor-Private Extension
  2372.  
  2373.     Compulsory = 0
  2374.     Type = 8
  2375.     Length = variable
  2376.  
  2377.    The NHRP Vendor-Private Extension is carried in NHRP packets to
  2378.    convey vendor-private information or NHRP extensions between NHRP
  2379.    speakers.
  2380.  
  2381.     0                   1                   2                   3
  2382.     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
  2383.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2384.    |                  Vendor ID                    |  Data....     |
  2385.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2386.  
  2387.    Vendor ID
  2388.      802 Vendor ID as assigned by the IEEE [6]
  2389.  
  2390.    Data
  2391.      The remaining octets after the Vendor ID in the payload are
  2392.      vendor-dependent data.
  2393.  
  2394.    This extension may be added to any "request" or "reply" packet and it
  2395.    is the only extension that may be included multiple times.  If the
  2396.    receiver does not handle this extension, or does not match the Vendor
  2397.    ID in the extension then the extension may be completely ignored by
  2398.    the receiver.  If a Vendor Private Extension is included in a
  2399.    "request" then it must be copied to the corresponding "reply".
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405.  
  2406. Luciani, Katz, Piscitello, Cole                                [Page 43]
  2407.  
  2408. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2409.  
  2410.  
  2411. 6. Protocol Operation
  2412.  
  2413.    In this section, we discuss certain operational considerations of
  2414.    NHRP.
  2415.  
  2416.  
  2417. 6.1 Router-to-Router Operation
  2418.  
  2419.    In practice, the initiating and responding stations may be either
  2420.    hosts or routers.  However, there is a possibility under certain
  2421.    conditions that a stable routing loop may occur if NHRP is used
  2422.    between two routers.  In particular, attempting to establish an NHRP
  2423.    path across a boundary where information used in route selection is
  2424.    lost may result in a routing loop.  Such situations include the loss
  2425.    of BGP path vector information, the interworking of multiple routing
  2426.    protocols with dissimilar metrics (e.g, RIP and OSPF), etc.  In such
  2427.    circumstances, NHRP should not be used.  This situation can be
  2428.    avoided if there are no "back door" paths between the entry and
  2429.    egress router outside of the NBMA subnetwork.  Protocol mechanisms to
  2430.    relax these restrictions are under investigation.
  2431.  
  2432.    In general it is preferable to use mechanisms, if they exist, in
  2433.    routing protocols to resolve the egress point when the destination
  2434.    lies outside of the NBMA subnetwork, since such mechanisms will be
  2435.    more tightly coupled to the state of the routing system and will
  2436.    probably be less likely to create loops.
  2437.  
  2438.  
  2439. 6.2 Cache Management Issues
  2440.  
  2441.    The management of NHRP caches in the source station, the NHS serving
  2442.    the destination, and any intermediate NHSs is dependent on a number
  2443.    of factors.
  2444.  
  2445. 6.2.1 Caching Requirements
  2446.  
  2447.    Source Stations
  2448.  
  2449.      Source stations MUST cache all received NHRP Resolution Replies
  2450.      that they are actively using.  They also must cache "incomplete"
  2451.      entries, i.e., those for which a NHRP Resolution Request has been
  2452.      sent but those for which an NHRP Resolution Reply has not been
  2453.      received.  This is necessary in order to preserve the Request ID
  2454.      for retries, and provides the state necessary to avoid triggering
  2455.      NHRP Resolution Requests for every data packet sent to the
  2456.      destination.
  2457.  
  2458.      Source stations MUST purge expired information from their caches.
  2459.  
  2460.  
  2461.  
  2462. Luciani, Katz, Piscitello, Cole                                [Page 44]
  2463.  
  2464. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2465.  
  2466.  
  2467.      Source stations MUST purge the appropriate cached information upon
  2468.      receipt of an NHRP Purge Request packet.
  2469.  
  2470.      When a station has a co-resident NHC and NHS, the co-resident NHS
  2471.      may reply to NHRP Resolution Requests from the co-resident NHC with
  2472.      information which the station cached as a result of the co-resident
  2473.      NHC making its own NHRP Resolution Requests as long as the co-
  2474.      resident NHS follows the rules for Transit NHSs as seen below.
  2475.  
  2476.    Serving NHSs
  2477.  
  2478.      The NHS serving the destination (the one which responds
  2479.      authoritatively to NHRP Resolution Requests) SHOULD cache protocol
  2480.      address information from all NHRP Resolution Requests to which it
  2481.      has responded if the information in the NHRP Resolution Reply has
  2482.      the possibility of changing during its lifetime (so that an NHRP
  2483.      Purge Request packet can be issued). The internetworking to NBMA
  2484.      binding information provided by the source station in the NHRP
  2485.      Resolution Request may also be cached if and only if the "S" bit is
  2486.      set, the NHRP Resolution Request has included a CIE with the
  2487.      Holding Time field set greater than zero (this is the valid Holding
  2488.      Time for the source binding), and only for non-authoritative use
  2489.      for a period not to exceed the Holding Time.
  2490.  
  2491.    Transit NHSs
  2492.  
  2493.      A Transit NHS (lying along the NHRP path between the source station
  2494.      and the responding NHS) may cache source binding information
  2495.      contained in NHRP Resolution Request packets that it forwards if
  2496.      and only if the "S" bit is set, the NHRP Resolution Request has
  2497.      included a CIE with the Holding Time field set greater than zero
  2498.      (this is the valid Holding Time for the source binding), and only
  2499.      for non-authoritative use for a period not to exceed the Holding
  2500.      Time.
  2501.  
  2502.      A Transit NHS may cache destination information contained in NHRP
  2503.      Resolution Reply CIE if only if the D bit is set and then only for
  2504.      non-authoritative use for a period not to exceed the Holding Time
  2505.      value contained in the CIE.  A Transit NHS MUST NOT cache source
  2506.      binding information contained in an NHRP Resolution Reply.
  2507.  
  2508.      Further, a transit NHS MUST discard any cached information when the
  2509.      prescribed time has expired.  It may return cached information in
  2510.      response to non-authoritative NHRP Resolution Requests only.
  2511.  
  2512.  
  2513.  
  2514.  
  2515.  
  2516.  
  2517.  
  2518. Luciani, Katz, Piscitello, Cole                                [Page 45]
  2519.  
  2520. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2521.  
  2522.  
  2523. 6.2.2 Dynamics of Cached Information
  2524.  
  2525.    NBMA-Connected Destinations
  2526.  
  2527.      NHRP's most basic function is that of simple NBMA address
  2528.      resolution of stations directly attached to the NBMA subnetwork.
  2529.      These mappings are typically very static, and appropriately chosen
  2530.      holding times will minimize problems in the event that the NBMA
  2531.      address of a station must be changed. Stale information will cause
  2532.      a loss of connectivity, which may be used to trigger an
  2533.      authoritative NHRP Resolution Request and bypass the old data.  In
  2534.      the worst case, connectivity will fail until the cache entry times
  2535.      out.
  2536.  
  2537.      This applies equally to information marked in NHRP Resolution
  2538.      Replies as being "stable" (via the "D" bit).
  2539.  
  2540.    Destinations Off of the NBMA Subnetwork
  2541.  
  2542.      If the source of an NHRP Resolution Request is a host and the
  2543.      destination is not directly attached to the NBMA subnetwork, and
  2544.      the route to that destination is not considered to be "stable," the
  2545.      destination mapping may be very dynamic (except in the case of a
  2546.      subnetwork where each destination is only singly homed to the NBMA
  2547.      subnetwork).  As such the cached information may very likely become
  2548.      stale.  The consequence of stale information in this case will be a
  2549.      suboptimal path (unless the internetwork has partitioned or some
  2550.      other routing failure has occurred).
  2551.  
  2552.  
  2553. 6.3 Use of the Prefix Length field of a CIE
  2554.  
  2555.    A certain amount of care needs to be taken when using the Prefix
  2556.    Length field of a CIE, in particular with regard to the prefix length
  2557.    advertised (and thus the size of the equivalence class specified by
  2558.    it).  Assuming that the routers on the NBMA subnetwork are exchanging
  2559.    routing information, it should not be possible for an NHS to create a
  2560.    black hole by advertising too large of a set of destinations, but
  2561.    suboptimal routing (e.g., extra internetwork layer hops through the
  2562.    NBMA) can result.  To avoid this situation an NHS that wants to send
  2563.    the Prefix Length MUST obey the following rule:
  2564.  
  2565.      The NHS examines the Network Layer Reachability Information (NLRI)
  2566.      associated with the route that the NHS would use to forward towards
  2567.      the destination (as specified by the Destination internetwork layer
  2568.      address in the NHRP Resolution Request), and extracts from this
  2569.      NLRI the shortest address prefix such that: (a) the Destination
  2570.      internetwork layer address (from the NHRP Resolution Request) is
  2571.  
  2572.  
  2573.  
  2574. Luciani, Katz, Piscitello, Cole                                [Page 46]
  2575.  
  2576. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2577.  
  2578.  
  2579.      covered by the prefix, (b) the NHS does not have any routes with
  2580.      NLRI which form a subset of what is covered by the prefix. The
  2581.      prefix may then be used in the CIE.
  2582.  
  2583.    The Prefix Length field of the CIE should be used with restraint, in
  2584.    order to avoid NHRP stations choosing suboptimal transit paths when
  2585.    overlapping prefixes are available.  This document specifies the use
  2586.    of the prefix length only when all the destinations covered by the
  2587.    prefix are "stable". That is, either:
  2588.  
  2589.      (a) All destinations covered by the prefix are on the NBMA network, or
  2590.  
  2591.      (b) All destinations covered by the prefix are directly attached to
  2592.          the NHRP responding station.
  2593.  
  2594.    Use of the Prefix Length field of the CIE in other circumstances is
  2595.    outside the scope of this document.
  2596.  
  2597.  
  2598. 6.4 Domino Effect
  2599.  
  2600.    One could easily imagine a situation where a router, acting as an
  2601.    ingress station to the NBMA subnetwork, receives a data packet, such
  2602.    that this packet triggers an NHRP Resolution Request.  If the router
  2603.    forwards this data packet without waiting for an NHRP transit path to
  2604.    be established, then when the next router along the path receives the
  2605.    packet, the next router may do exactly the same - originate its own
  2606.    NHRP Resolution Request (as well as forward the packet).  In fact
  2607.    such a data packet may trigger NHRP Resolution Request generation at
  2608.    every router along the path through an NBMA subnetwork.  We refer to
  2609.    this phenomena as the NHRP "domino" effect.
  2610.  
  2611.    The NHRP domino effect is clearly undesirable.  At best it may result
  2612.    in excessive NHRP traffic.  At worst it may result in an excessive
  2613.    number of virtual circuits being established unnecessarily.
  2614.    Therefore, it is important to take certain measures to avoid or
  2615.    suppress this behavior.  NHRP implementations for NHSs MUST provide a
  2616.    mechanism to address this problem. One possible strategy to address
  2617.    this problem would be to configure a router in such a way that NHRP
  2618.    Resolution Request generation by the router would be driven only by
  2619.    the traffic the router receives over its non-NBMA interfaces
  2620.    (interfaces that are not attached to an NBMA subnetwork).  Traffic
  2621.    received by the router over its NBMA-attached interfaces would not
  2622.    trigger NHRP Resolution Requests.  Such a router avoids the NHRP
  2623.    domino effect through administrative means.
  2624.  
  2625.  
  2626.  
  2627.  
  2628.  
  2629.  
  2630. Luciani, Katz, Piscitello, Cole                                [Page 47]
  2631.  
  2632. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2633.  
  2634.  
  2635. 7. NHRP over Legacy BMA Networks
  2636.  
  2637.    There would appear to be no significant impediment to running NHRP
  2638.    over legacy broadcast subnetworks.  There may be issues around
  2639.    running NHRP across multiple subnetworks. Running NHRP on broadcast
  2640.    media has some interesting possibilities; especially when setting up
  2641.    a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both
  2642.    end stations are legacy attached.  This use for NHRP requires further
  2643.    research.
  2644.  
  2645.  
  2646. 8. Discussion
  2647.  
  2648.    The result of an NHRP Resolution Request depends on how routing is
  2649.    configured among the NHSs of an NBMA subnetwork.  If the destination
  2650.    station is directly connected to the NBMA subnetwork and the routed
  2651.    path to it lies entirely within the NBMA subnetwork, the NHRP
  2652.    Resolution Replies always return the NBMA address of the destination
  2653.    station itself rather than the NBMA address of some egress router.
  2654.    On the other hand, if the routed path exits the NBMA subnetwork, NHRP
  2655.    will be unable to resolve the NBMA address of the destination, but
  2656.    rather will return the address of the egress router.  For
  2657.    destinations outside the NBMA subnetwork, egress routers and routers
  2658.    in the other subnetworks should exchange routing information so that
  2659.    the optimal egress router may be found.
  2660.  
  2661.    In addition to NHSs, an NBMA station could also be associated with
  2662.    one or more regular routers that could act as "connectionless
  2663.    servers" for the station.  The station could then choose to resolve
  2664.    the NBMA next hop or just send the packets to one of its
  2665.    connectionless servers.  The latter option may be desirable if
  2666.    communication with the destination is short-lived and/or doesn't
  2667.    require much network resources.  The connectionless servers could, of
  2668.    course, be physically integrated in the NHSs by augmenting them with
  2669.    internetwork layer switching functionality.
  2670.  
  2671.  
  2672. 9. IANA Considerations
  2673.    IANA will redirect requests for numbers in the various number spaces
  2674.    described herein to the working group chairs.  Currently, these
  2675.    chairs are Andy Malis (malis@ascend.com) and George Swallow
  2676.    (swallow@cisco.com).  The working group chair(s) will accept any and
  2677.    all requests for value assignment as long as the client/server
  2678.    protocol specific document exists (i.e., the protocol specific
  2679.    document has been published as an internet draft or informational
  2680.    RFC).
  2681.  
  2682.  
  2683.  
  2684.  
  2685.  
  2686. Luciani, Katz, Piscitello, Cole                                [Page 48]
  2687.  
  2688. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2689.  
  2690.  
  2691. References
  2692.  
  2693.    [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh
  2694.        Govindan, RFC1735.
  2695.  
  2696.    [2] Address Resolution Protocol, David C. Plummer, RFC 826.
  2697.  
  2698.    [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577.
  2699.  
  2700.    [4] Transmission of IP datagrams over the SMDS service, J. Lawrence
  2701.        and D. Piscitello, RFC 1209.
  2702.  
  2703.    [5] Protocol Identification in the Network Layer, ISO/IEC TR
  2704.        9577:1990.
  2705.  
  2706.    [6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700.
  2707.  
  2708.    [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen,
  2709.        RFC1483.
  2710.  
  2711.    [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode,
  2712.        A. Malis, D. Robinson, and R. Ullmann, RFC1356.
  2713.  
  2714.    [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and
  2715.        A. Malis, RFC1490.
  2716.  
  2717.    [10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks,
  2718.         Yakov Rekhter, Dilip Kandlur, RFC1937.
  2719.  
  2720.    [11] Support for Multicast over UNI 3.0/3.1 based ATM Networks,
  2721.         G. Armitage, RFC2021
  2722.  
  2723.    [12] Server Cache Synchronization Protocol (SCSP) - NBMA,
  2724.         J. Luciani, G. Armitage, J. Halpern, draft-ietf-ion-scsp-02.txt
  2725.  
  2726.    [13] NHRP for Destinations off the NBMA Subnetwork,
  2727.         Y. Rekhter, Work In Progress.
  2728.  
  2729.    [14] Classical IP to NHRP Transition, J. Luciani, et al., Work In Progress.
  2730.  
  2731.    [15] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
  2732.         RFC 2119.
  2733.  
  2734.    [16] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare,
  2735.         Canetti, RFC 2104.
  2736.  
  2737.  
  2738.  
  2739.  
  2740.  
  2741.  
  2742. Luciani, Katz, Piscitello, Cole                                [Page 49]
  2743.  
  2744. INTERNET-DRAFT                 NBMA NHRP              Expires March 1998
  2745.  
  2746.  
  2747. Acknowledgments
  2748.  
  2749.    We would like to thank (in no particular order) Naganand Doraswami of
  2750.    Bay Networks for the entirety of the security section, Thomas Narton
  2751.    of IBM for his comments in the role of Internet AD, Juha Heinenan of
  2752.    Telecom Finland and Ramesh Govidan of ISI for their work on NBMA ARP
  2753.    and the original NHRP draft, which served as the basis for this work.
  2754.    Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of
  2755.    ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul
  2756.    Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco,
  2757.    and Grenville Armitage of Bellcore should also be acknowledged for
  2758.    comments and suggestions that improved this work substantially.  We
  2759.    would also like to thank the members of the ION working group of the
  2760.    IETF, whose review and discussion of this document have been
  2761.    invaluable.
  2762.  
  2763.  
  2764. Authors' Addresses
  2765.  
  2766.  
  2767.    James V. Luciani                    Dave Katz
  2768.    Bay Networks                        cisco Systems
  2769.    3 Federal Street                    170 W. Tasman Dr.
  2770.    Mail Stop: BL3-04                   San Jose, CA 95134 USA
  2771.    Billerica, MA 01821                 Phone:  +1 408 526 8284
  2772.    Phone:  +1 508 916 4734             Email:  dkatz@cisco.com
  2773.    Email:  luciani@baynetworks.com
  2774.  
  2775.    David Piscitello                    Bruce Cole
  2776.    Core Competence                     Juniper Networks
  2777.    1620 Tuckerstown Road               3260 Jay St.
  2778.    Dresher, PA 19025 USA               Santa Clara, CA 95054
  2779.    Phone:  +1 215 830 0692             Phone:  +1 408 327 1900
  2780.    Email: dave@corecom.com             Email:  bcole@jnx.com
  2781.  
  2782.  
  2783.  
  2784.  
  2785.  
  2786.  
  2787.  
  2788.  
  2789.  
  2790.  
  2791.  
  2792.  
  2793.  
  2794.  
  2795.  
  2796.  
  2797.  
  2798. Luciani, Katz, Piscitello, Cole                                [Page 50]
  2799.  
  2800.