home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ion-r2r-nhrp-00.txt < prev    next >
Text File  |  1997-02-03  |  30KB  |  779 lines
  1.  
  2.  
  3.  
  4.  
  5. Network Working Group                                      Yakov Rekhter
  6. Internet Draft                                             Cisco Systems
  7. Expiration Date: August 1997                               February 1997
  8.  
  9.  
  10.              NHRP for Destinations off the NBMA Subnetwork
  11.  
  12.                      draft-ietf-ion-r2r-nhrp-00.txt
  13.  
  14.  
  15. 1. Status of this Memo
  16.  
  17.    This document is an Internet-Draft.  Internet-Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its areas,
  19.    and its working groups.  Note that other groups may also distribute
  20.    working documents as Internet-Drafts.
  21.  
  22.    Internet-Drafts are draft documents valid for a maximum of six months
  23.    and may be updated, replaced, or obsoleted by other documents at any
  24.    time.  It is inappropriate to use Internet-Drafts as reference
  25.    material or to cite them other than as ``work in progress.''
  26.  
  27.    To learn the current status of any Internet-Draft, please check the
  28.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  29.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  30.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  31.    ftp.isi.edu (US West Coast).
  32.  
  33.  
  34. 2. Abstract
  35.  
  36.    The NBMA Next Hop Resolution Protocol (NHRP) [NHRP] specifies a
  37.    mechanism that allows a source station (e.g., a host or a router) on
  38.    an NBMA subnetwork to find the NBMA subnetwork address address of a
  39.    destination station when the destination station is connected to the
  40.    NBMA subnetwork. For the case where the destination station is off
  41.    the NBMA subnetwork the mechanism described in [NHRP] allows to
  42.    determine the NBMA subnetwork address of an egress router from the
  43.    NBMA subnetwork that is ``nearest'' to the destination station.
  44.    However, the ability of determining the egress router is constrained
  45.    to the destinations that are directly connected to the egress router.
  46.  
  47.    This document describes extensions to the NBMA Next Hop Resolution
  48.    Protocol (NHRP) [NHRP] that allow to acquire and maintain the
  49.    information about the egress router without constraining the
  50.    destination(s) to be directly connected to the egress router.
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Yakov Rekhter                                                    [Page 1]
  57.  
  58.  
  59.  
  60.  
  61.  
  62. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  63.  
  64.  
  65. 3. NHRP Target Information
  66.  
  67.    The mechanism described in this document allows to find an egress
  68.    router for either a single destination, or a set of destinations
  69.    (where the set is expressed as a single address prefix). Since a
  70.    single destination is just a special case of a set of destinations,
  71.    for the rest of the document we will always talk about a set of
  72.    destinations, and will refer to this set as an ``NHRP target''.
  73.  
  74.    The NHRP target is carried in the NHRP Request,  Reply, and Purge
  75.    messages as an address prefix (using the Destination Prefix Length
  76.    extension). This document requires that the NHRP target shall not be
  77.    modified by the routers that forward the messages.
  78.  
  79.    In general a router may maintain in its Forwarding Information Bas
  80.    (FIB) routes whose Network Layer Reachability Information (NLRI) that
  81.    exhibits a subset relation. Such routes are called overlapping
  82.    routes.  To provide correct forwarding in the presence of overlapping
  83.    routes this document constrains an NHRP target by requiring that all
  84.    the destinations covered by the target must form a subset of the NLRI
  85.    of at least one route in the Forwarding Information Base (FIB) of the
  86.    router that either originates, or propagates an NHRP Request. For the
  87.    rest of the document we'll refer to this as the ``first NHRP target
  88.    constraint''.  A station can originate an NHRP Request, and a router
  89.    can propagate an NHRP Request only if the NHRP target of the Request
  90.    does not violate the first NHRP target constraint.
  91.  
  92.    A route (from a local FIB) whose NLRI forms a minimal superset of all
  93.    the destinations covered by the NHRP target is called an ``NHRP
  94.    forwarding route''. Observe, that by definition the set of
  95.    destinations covered by an NHRP target always exhibits a subset
  96.    relation to the set of destinations covered by the NHRP forwarding
  97.    route associated with the target.
  98.  
  99.    This document further constrains origination/propagation of NHRP
  100.    Requests by prohibiting the NHRP target (carried by a Request) to
  101.    form a superset of the destinations covered by any of the routes in
  102.    the local FIB.  The constraint applies both to the station that
  103.    originates an NHRP Request and to the routers that propagate the
  104.    Request. For the rest of the document we'll refer to this constraint
  105.    as the ``second NHRP target constraint''. A station can originate an
  106.    NHRP Request, and a router can propagate an NHRP Request only if the
  107.    NHRP target of the Request does not violate the second NHRP target
  108.    constraint. The second NHRP target constraint guarantees that
  109.    forwarding to all the destinations covered by the NHRP target would
  110.    be accomplished via a single (common) route, and this route would be
  111.    nothing, but the NHRP forwarding route for the target.
  112.  
  113.  
  114.  
  115.  
  116. Yakov Rekhter                                                    [Page 2]
  117.  
  118.  
  119.  
  120.  
  121.  
  122. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  123.  
  124.  
  125. 4. NHRP Route Information
  126.  
  127.    To allow  routers along a path to unambiguously determine routing
  128.    domain boundaries, and to provide correct next hop information, the
  129.    NHRP Request carries the NHRP route information. The NHRP route
  130.    information is generated by the router that originates an NHRP
  131.    Request, but could be modified by the routers that forward the
  132.    Request.
  133.  
  134.    The NHRP route information consists of two components, protocol
  135.    independent and protocol specific.  The protocol independent
  136.    component consists of NLRI and the protocol type of the NHRP
  137.    forwarding route associated with the NHRP target.  For RIP, OSPF, and
  138.    Dual IS-IS  the protocol specific component is empty.  For RIP-2 the
  139.    protocol specific component contains the Route Tag of the route.
  140.    Definition of the protocol specific component for other routing
  141.    protocols is outside the scope of this document.
  142.  
  143.    [Discussion: it is not clear how much value is in carrying (and
  144.    updating) the NLRI information (as part of the NHRP route
  145.    information) for such protocols as RIP, OSPF, and Dual IS-IS.]
  146.  
  147.  
  148.  
  149. 5. Processing NHRP Request
  150.  
  151.    Processing of an NHRP Request is covered by two sets of rules: the
  152.    first set is independent of a particular routing domain, the second
  153.    set is specific to a particular routing domains.
  154.  
  155.  
  156. 5.1. Domain-independent rules
  157.  
  158.    When a router receives a  Request, the router uses the NHRP target
  159.    and the NHRP route information  to check whether  (a) the first and
  160.    the second NHRP target constraints are satisfied, (b) the router it
  161.    is in the same routing domain as the originator of the Request, and
  162.    if yes, then whether (c) it is a border router for that domain.
  163.  
  164.    If the first NHRP target constraint is violated, the router reports
  165.    an error to the originator of the Request and terminates the query.
  166.  
  167.    If the second NHRP target constraint is violated, then the router
  168.    sends back an NHRP Reply and terminates the query. The Reply should
  169.    indicate that the second NHRP target constraint was violated.  The
  170.    Reply contains IP and NBMA addresses of the router.
  171.  
  172.    If the NHRP forwarding route indicates next hop that is not on the
  173.  
  174.  
  175.  
  176. Yakov Rekhter                                                    [Page 3]
  177.  
  178.  
  179.  
  180.  
  181.  
  182. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  183.  
  184.  
  185.    same NBMA as the interface on which the Request was received, the
  186.    router sends back an NHRP Reply and terminates the query.
  187.  
  188.    If a router receives a Request that is not annotated with the border
  189.    router information, then the router is either within the routing
  190.    domain that the originator of the Request is in, or is a border
  191.    router for that domain. In this case the router uses domain-specific
  192.    rules (see below)  to determine whether it is a border router for the
  193.    routing domain that the originator of the request is in, or whether
  194.    it is just an internal router within the domain.
  195.  
  196.    If the router is a border router for the routing domain that the
  197.    originator of the Request is in, then the router can either (a)
  198.    annotate the request with the IP and NBMA addresses associated with
  199.    the NHRP forwarding route for the NHRP target carried by the Request
  200.    and forward the Request (outside the domain), or (b) send back an
  201.    NHRP Reply (and thus terminate the query). The Reply contains the IP
  202.    and NBMA addresses associated with the NHRP forwarding route for the
  203.    NHRP target carried by the Request.  The choice between (a) and (b)
  204.    is a local to the router matter.
  205.  
  206.    If a router receives a Request that is annotated with the border
  207.    router information, then the originator of the Request and the router
  208.    are in different routing domains.  In this case the router uses only
  209.    the NHRP target information  to handle the Request.
  210.  
  211.  
  212. 5.2. Domain-specific rules
  213.  
  214.    The following sections describes rules specific to particular routing
  215.    domains (e.g., RIP domain, OSPF domain).
  216.  
  217.  
  218. 5.2.1. RIP Domain
  219.  
  220.    When a router receives a Request, such that (a) the NHRP route
  221.    information indicates RIP,  (b) the router determines (using the
  222.    domain-independent rules) that it is in the same domain as the
  223.    originator of the Request, and (c) the domain-independent rules do
  224.    not require the router to terminate the query, the router checks if
  225.    the NHRP forwarding route is a RIP-learned route.
  226.  
  227.    If it is a RIP-learned route, then the router replaces NLRI in the
  228.    NHRP route information of the Request with the NLRI of the NHRP
  229.    forwarding route, and forwards the Request to the next hop specified
  230.    by the route.  Otherwise,  the router and the originator of the
  231.    Request are in the same routing domain, and the router is a border
  232.    router for that domain.
  233.  
  234.  
  235.  
  236. Yakov Rekhter                                                    [Page 4]
  237.  
  238.  
  239.  
  240.  
  241.  
  242. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  243.  
  244.  
  245.    [Discussion: it is not clear what is the value of updating NLRI in
  246.    the NHRP route information.]
  247.  
  248.  
  249. 5.2.2. RIP-2 Domain
  250.  
  251.    When a router receives a Request, such that (a) the NHRP route
  252.    information indicates RIP-2,  (b) the router determines (using the
  253.    domain-independent rules) that it is in the same domain as the
  254.    originator of the Request, and (c) the domain-independent rules do
  255.    not require the router to terminate the query, the router checks if
  256.    the NHRP forwarding route is a RIP-2-learned route.
  257.  
  258.    If it is a RIP-2-learned route, and the Route Tag of the route is the
  259.    same as the one carried in the NHRP route information of the Request,
  260.    then the router replaces the NLRI information in the NHRP route
  261.    information of the Request with NLRI of the NHRP forwarding route,
  262.    and forwards the Request to the next hop specified by the route.
  263.    Otherwise, the router and the originator of the Request are in the
  264.    same routing domain, and the router is a border router for that
  265.    domain.
  266.  
  267.    [Discussion: it is not clear what is the value of updating NLRI in
  268.    the NHRP route information.]
  269.  
  270.  
  271. 5.2.3. OSPF Domain
  272.  
  273.    When a router receives a Request, such that (a) the NHRP route
  274.    information indicates OSPF,  (b) the router determines (using the
  275.    domain-independent rules) that it is in the same domain as the
  276.    originator of the Request, and (c) the domain-independent rules do
  277.    not require the router to terminate the query, the router checks if
  278.    the NHRP forwarding route is an OSPF-learned route.
  279.  
  280.    If the route is an OSPF-learned route, but the router is neither an
  281.    Area Border Router (ABR), nor AS Boundary Router (ASBR), the router
  282.    forwards the Request to the next hop specified by the NHRP forwarding
  283.    route.
  284.  
  285.    If the route is an OSPF-learned route, and the router is an ABR, then
  286.    the router replaces NLRI in the NHRP route information of the Request
  287.    with NLRI of the NHRP forwarding route, and forwards the Request to
  288.    the next hop specified by the route.
  289.  
  290.    [Discussion: it is not clear what is the value of updating NLRI in
  291.    the NHRP route information.]
  292.  
  293.  
  294.  
  295.  
  296. Yakov Rekhter                                                    [Page 5]
  297.  
  298.  
  299.  
  300.  
  301.  
  302. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  303.  
  304.  
  305.    If the route is not an OSPF-learned route, and the router is an ASBR,
  306.    then the router and the originator of the Request are in the same
  307.    routing domain, and the router is a border router for that domain.
  308.  
  309.    If the route is not an OSPF-learned route, and the router is not an
  310.    ASBR, then the router indicates an error.
  311.  
  312.  
  313.  
  314. 5.2.4. Dual IS-IS Domain
  315.  
  316.    When a router receives a Request, such that (a) the NHRP route
  317.    information indicates Dual IS-IS,  (b) the router determines (using
  318.    the domain-independent rules) that it is in the same domain as the
  319.    originator of the Request, and (c) the domain-independent rules do
  320.    not require the router to terminate the query, the router checks if
  321.    the NHRP forwarding route is a Dual IS-IS-learned route.
  322.  
  323.    If the route is a Dual IS-IS-learned route, and the router is not a
  324.    L2 router, the router forwards the Request to the next hop specified
  325.    by the route.
  326.  
  327.    If the route is not a Dual IS-IS-learned route, and the router is a
  328.    L2 router, then the router and the originator of the Request are in
  329.    the same routing domain, and the router is a border router for that
  330.    domain.
  331.  
  332.    If the route is a Dual IS-IS-learned route, and the router is a L2
  333.    router, then the router replaces the NLRI information in the NHRP
  334.    route information of the Request with the NLRI of the NHRP forwarding
  335.    route, and forwards the Request to the next hop specified by the
  336.    route.
  337.  
  338.    [Discussion: it is not clear what is the value of updating NLRI in
  339.    the NHRP route information.]
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356. Yakov Rekhter                                                    [Page 6]
  357.  
  358.  
  359.  
  360.  
  361.  
  362. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  363.  
  364.  
  365. 6. Maintaining correct shortcut information
  366.  
  367.    Once a router that originates an NHRP Request acquires the shortcut
  368.    next hop information, it is essential for the router to be able to
  369.    detect any changes that would affect the correctness of this
  370.    information. The following measures are intended to provide the
  371.    correctness.
  372.  
  373.    Both ends of a shortcut have to monitor the status of the route that
  374.    was associated with the shortcut (the NHRP forwarding route). If the
  375.    status changes at the router that generate the NHRP Reply, this
  376.    router should send a Purge message, so that the NHRP Requester would
  377.    issue another NHRP. If the status changes at the Requester, the
  378.    Requester must issue another NHRP. This allows to ensure that when
  379.    both end of a shortcut are up, any changes in routing that impact
  380.    forwarding to any of the destination in the NHRP target would result
  381.    in a revalidation (via NHRP) of the shortcut.
  382.  
  383.    Once a shortcut is established, the Requester needs to have some
  384.    mechanism(s) to ensure that the other end of the shortcut is alive.
  385.    Among the possible mechanisms are: (a) indications from the Data Link
  386.    layer, (b) presence of traffic in the reverse direction that comes
  387.    with the Link Layer address of the other end, (c) keepalives sent by
  388.    the other end. This is intended to suppress black holes, when the
  389.    next hop router in the shortcut (the router that generated Reply)
  390.    goes down.
  391.  
  392.    A requester should establish a shortcut only after the requester
  393.    determines that the information provided by NHRP is fairly stable.
  394.    This is necessary in order to avoid initiating shortcuts that are
  395.    based on transients routing information, and thus would need to be
  396.    revalidated almost immediately anyway.
  397.  
  398.    [Discussion: Should a router forward an NHRP Request based on a route
  399.    that is in a transient (e.g., holddown) state, or should the Request
  400.    be discarded ?]
  401.  
  402.    [Discussion: what are the criteria to determine whether the
  403.    information provided by NHRP is "fairly stable" ?]
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416. Yakov Rekhter                                                    [Page 7]
  417.  
  418.  
  419.  
  420.  
  421.  
  422. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  423.  
  424.  
  425. 7. Extensions to multi-domains shortcuts
  426.  
  427.    While the NHRP mechanism described above is mostly constrained to the
  428.    routers within a single routing domain, in certain situations the
  429.    information provided by this mechanism could be sufficient to
  430.    establish shortcuts that would span multiple domains.
  431.  
  432.    Consider an example where an NHRP Request was originated within a
  433.    particular routing domain A, and the NHRP target of the Request is in
  434.    some other routing domain B. Further assume that the border routers
  435.    in both A and B participate in a single common instance of BGP. Since
  436.    BGP preserves the next hop information across an NBMA network, the
  437.    routing information available at the border routers in A would
  438.    contain the next hop IP information that may be in some other routing
  439.    domain along the path to B, perhaps even in B itself. Therefore, when
  440.    a border router in A receives the Request, the router would annotate
  441.    the Request with the next hop information that is associated with a
  442.    router in some other routing domain, thus providing the information
  443.    needed to establish a shortcut that spans multiple routing domains.
  444.  
  445.    [Discussion: BGP preserves the next hop IP information, but does not
  446.    carry NBMA address information. The NBMA address information could be
  447.    either added to BGP (as another attribute), or NHRP could be used to
  448.    resolve IP address to NBMA address mapping.]
  449.  
  450.    [The following could be viewed as controversial. More discussion is
  451.    needed.]
  452.  
  453.    While the ability of BGP to preserve the next hop information could
  454.    reduce the number of IP hops along a path, the information, by
  455.    itself, may not be sufficient to form a single IP hop across an NBMA
  456.    network.  However, we could observe that once a router (e.g., a
  457.    border router) acquires a shortcut information, then as long as the
  458.    router has sufficient assurances that the information is correct, the
  459.    router could pass this information to other routers in response to
  460.    NHRP Requests.  Since a border router (by definition) belongs to
  461.    multiple routing domains, passing the information through the border
  462.    router from one domain to another would be sufficient for
  463.    establishing shortcuts that span multiple routing domains.
  464.  
  465.    For example, assume that a border router X within a given domain A
  466.    acquired the information needed to form a shortcut within A for a
  467.    given NHRP target (the target may be either within A or outside of
  468.    A).  Further assume that X is also in some other routing domain B,
  469.    and there is a router Y in B that would like to acquire the shortcut
  470.    information for exactly the same NHRP target. If the NHRP Request
  471.    originated by Y would reach X, then when X receives the Request
  472.    rather than indicating itself as the next hop, X would use the
  473.  
  474.  
  475.  
  476. Yakov Rekhter                                                    [Page 8]
  477.  
  478.  
  479.  
  480.  
  481.  
  482. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  483.  
  484.  
  485.    shortcut information it already has to specify the next hop in the
  486.    Reply. Thus Y would have the information to construct a shortcut that
  487.    crosses domain's boundary.
  488.  
  489.    If X would detect any changes in the information associated with the
  490.    shortcut (either due to local changes, or as a result of receiving a
  491.    Purge message), then X would reissue the NHRP Request, and also would
  492.    send a Purge message to Y. When Y would receive the Purge message
  493.    from X, Y would reissue the NHRP Request as well.
  494.  
  495.    Additional complexity in handling multi-domains shortcuts arise if
  496.    routing information gets aggregated at the border routers (which
  497.    certainly happens in practice). Since BGP is the major protocol that
  498.    is used to exchange routing information across multiple routing
  499.    domains, we'll restrict our proposal to the case where the routing
  500.    information exchange across domains' boundaries is controlled by BGP.
  501.  
  502.    If both the source and the destination domains are on a common NBMA
  503.    network, and the path between these two domains is also fully within
  504.    the same NBMA network, then we have only three routing domains to
  505.    deal with: source routing domain, BGP routing domain, and destination
  506.    routing domain. If the destination domain is not on the same NBMA as
  507.    the source domain, then we need to deal only with two domains - the
  508.    source and the BGP. Note that we treat all routers that participate
  509.    in a single (common) instance of BGP as a single BGP routing domain,
  510.    even if these routers participate in different intra-domain routing
  511.    protocols, or in different instances of the same intra-domain routing
  512.    protocol.
  513.  
  514.    To simplify the presentation we decompose the problem into the
  515.    following three subproblems:
  516.  
  517.          (a) how a border router in the domain that the originator of
  518.                the Request is in handles the Request (crossing IGP/BGP
  519.                boundary),
  520.  
  521.          (b) how the Request is handled across the BGP domain, and
  522.                finally
  523.  
  524.          (c) how a border router in the domain where the NHRP target is
  525.                in handles the Request (crossing BGP/IGP boundary).
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536. Yakov Rekhter                                                    [Page 9]
  537.  
  538.  
  539.  
  540.  
  541.  
  542. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  543.  
  544.  
  545. 7.1. Handling NHRP Request at the source domain border router
  546.  
  547.    When a border router receives an NHRP Request originated from within
  548.    its own (IGP) routing domain, the border router determines the NHRP
  549.    forwarding route for the NHRP target carried by the Request. If the
  550.    router already has the shortcut information for the forwarding route,
  551.    then the router uses this information to construct a Reply to the
  552.    source of the NHRP Request.  Otherwise, the router originates its own
  553.    NHRP Request.  The Request contains exactly the same NHRP target, as
  554.    was carried by the original Request;  the NHRP route information
  555.    contains NLRI and the protocol (BGP) of the NHRP forwarding route.
  556.    The newly originated Request is sent to the next hop of the NHRP
  557.    forwarding route. Once the border router receives a Reply to its own
  558.    Request, the border router uses the next hop information from the
  559.    Reply to construct its own Reply to the source of the original NHRP
  560.    Request.
  561.  
  562.    If the border router later on receives a Purge message for the NHRP
  563.    forwarding route, the border router treats this event as if there was
  564.    a local change in the NHRP forwarding route (even if the there was no
  565.    changes in the route).
  566.  
  567.  
  568. 7.2. Handling NHRP Request within the BGP domain
  569.  
  570.    When a BGP router (e.g., a border router at the source domain)
  571.    originates an NHRP Request, this Request would be sent to a router
  572.    that is either
  573.  
  574.          (a) an egress router from an NBMA network (since in the absence
  575.                of aggregation BGP preserves the next hop information),
  576.                or
  577.  
  578.          (b) a border router within the domain that contains all the
  579.                destinations carried by the NHRP target, or
  580.  
  581.          (c) a router that aggregates NLRI carried by the NHRP route
  582.                information of the Request.
  583.  
  584.  
  585.    With case (a) when the router receives the Request the router sends
  586.    back an NHRP Reply and terminates the query. Case (b) is handled as
  587.    described in the next section.
  588.  
  589.    With case (c) when the router receives the Request, the router
  590.    determines the NHRP forwarding route for the NHRP target carried by
  591.    the Request and originates its own NHRP Request.  The Request
  592.    contains exactly the same NHRP target, as was carried by the original
  593.  
  594.  
  595.  
  596. Yakov Rekhter                                                   [Page 10]
  597.  
  598.  
  599.  
  600.  
  601.  
  602. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  603.  
  604.  
  605.    request; the NHRP route information contains NLRI and the protocol
  606.    (BGP) of the NHRP forwarding route.  The newly originated Request is
  607.    sent to the next hop of the NHRP forwarding route. Once the router
  608.    receives a Reply to its own Request, the router uses the next hop
  609.    information from the Reply to construct its own Reply to the source
  610.    of the original NHRP Request.
  611.  
  612.    If the router later on receives a Purge message for the NHRP
  613.    forwarding route, the router treats this event as if there was a
  614.    change in the NHRP forwarding route (even if the there was no changes
  615.    in the route).
  616.  
  617.  
  618.  
  619. 7.3. Handling NHRP Request at the destination domain border router
  620.  
  621.    When a border router receives an NHRP Request from a BGP speaker, and
  622.    the border router determines that all the destinations covered by the
  623.    NHRP target of the Request are within the (IGP) domain of that border
  624.    router, the border router determines the NHRP forwarding route for
  625.    the NHRP target carried by the Request. The newly formed Request
  626.    contains exactly the same NHRP target as the received Request; the
  627.    NHRP route information contains NLRI and the protocol of the NHRP
  628.    forwarding route.  The newly originated Request is sent to the next
  629.    hop of the NHRP forwarding route. Once the border router receives a
  630.    Reply to its own Request, the border router uses the next hop
  631.    information from the Reply to construct its own Reply to the source
  632.    of the original NHRP Request.
  633.  
  634.    If the border router later on receives a Purge message for the NHRP
  635.    forwarding route, the border router treats this event as if there was
  636.    a change in the NHRP forwarding route (even if the there was no
  637.    changes in the route).
  638.  
  639.    [Discussion: it is not clear what are the merits of carrying and
  640.    updating NLRI in the NHRP route information.]
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656. Yakov Rekhter                                                   [Page 11]
  657.  
  658.  
  659.  
  660.  
  661.  
  662. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  663.  
  664.  
  665. 8. More state, less messages
  666.  
  667.    It should be possible to reduce the number of Purge messages and
  668.    subsequent NHRP messages (caused by the Purge messages) by
  669.    maintaining more state on the border routers at the source and
  670.    destination domains, and the BGP routers that perform aggregation
  671.    along the path from the source to the destination.
  672.  
  673.    Specifically, on these routers it would be necessary to keep the
  674.    information about all the NHRP targets for which the routers maintain
  675.    the shortcut information.  This way when such a router determines
  676.    that the NHRP forwarding route (for which the router maintains the
  677.    shortcut information) changes due to some local routing changes, the
  678.    router could check whether these local changes impact forwarding to
  679.    the destinations covered by the NHRP targets.  Only for the targets
  680.    that are impacted by the changes the router would send Purge
  681.    messages.
  682.  
  683.    Note that this mechanism (maintaining NHRP targets) precludes the use
  684.    of Address Prefix Extension - the shortcut will be determined only
  685.    for the destinations covered by the NHRP target (so, if the target is
  686.    a single IP address, then the shortcut would be determined only for
  687.    this address).
  688.  
  689.  
  690. 9. Open issues
  691.  
  692.    During routing transients it is quite possible that neither the
  693.    router that originates an NHRP Request for a particular NHRP target,
  694.    nor the router that terminates this Request (and sends back an NHRP
  695.    Reply) would experience any changes in the NHRP forwarding route
  696.    associated with the  NHRP target. However, this may not be true for
  697.    the routers along the path that the NHRP Request would traverse. It
  698.    is not clear whether this could lead to a formation of a persistent
  699.    forwarding loop, even in the presence of the mechanisms described
  700.    above. Further study of this issue is needed before advancing the use
  701.    of NHRP for establishing shortcuts among routers.
  702.  
  703.    The mechanisms described in this document assume that certain routers
  704.    along a path taken by an NHRP Request would be required to maintain
  705.    state associated with the NHRP forwarding route associated with the
  706.    NHRP target carried by the Request. However, it is quite clear that
  707.    the router(s) may also lose this state. Further study of the impact
  708.    of losing the state is needed before advancing the use of NHRP for
  709.    establishing shortcuts among routers.
  710.  
  711.    The mechanisms described in this document may result in a situation
  712.    where a router would be required to maintain NHRP peering with
  713.  
  714.  
  715.  
  716. Yakov Rekhter                                                   [Page 12]
  717.  
  718.  
  719.  
  720.  
  721.  
  722. Internet Draft       draft-ietf-ion-r2r-nhrp-00.txt        February 1997
  723.  
  724.  
  725.    potentially a fairly large number of other routers. Further study is
  726.    needed to understand the implications of this on the scalability of
  727.    the approach where NHRP is used to establish shortcuts among routers.
  728.  
  729.  
  730. 10. Security Considerations
  731.  
  732.    To be supplied
  733.  
  734.  
  735. 11. References
  736.  
  737.    To be supplied.
  738.  
  739.  
  740. 12. Acknowledgements
  741.  
  742.    To be supplied.
  743.  
  744.  
  745. 13. Author Information
  746.  
  747.    Yakov Rekhter
  748.    cisco Systems, Inc.
  749.    170 Tasman Dr.
  750.    San Jose, CA 95134
  751.    Phone: (914) 528-0090
  752.    email: yakov@cisco.com
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776. Yakov Rekhter                                                   [Page 13]
  777.  
  778.  
  779.