idnits 2.17.1 draft-ietf-ion-r2r-nhrp-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 197 has weird spacing: '...tion in a tra...' == Line 211 has weird spacing: '...ermines that ...' == Line 216 has weird spacing: '...rmation to ch...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1998) is 9560 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internetworking Over NBMA Yakov Rekhter 3 INTERNET-DRAFT Cisco Systems 4 Joel Halpern 5 Expiration Date: August 1999 Newbridge Networks, Inc. 6 February 1998 8 NHRP for Destinations off the NBMA Subnetwork 10 draft-ietf-ion-r2r-nhrp-01.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 The NBMA Next Hop Resolution Protocol (NHRP) [1] specifies a 34 mechanism that allows a source station (e.g., a host or a router) on 35 an NBMA subnetwork to find the NBMA subnetwork address address of a 36 destination station when the destination station is connected to the 37 NBMA subnetwork. For the case where the destination station is off 38 the NBMA subnetwork the mechanism described in [1] allows to 39 determine the NBMA subnetwork address of an egress router from the 40 NBMA subnetwork that is ``nearest'' to the destination station. If 41 used to locate an egress router wherein the destination station is 42 directly behind the egress router, the currently document NHRP 43 behaviors are sufficient. However, as documented elsewhere [2], 44 there are cases where if used between routers for generalized 45 transit, NHRP can produce loops. 47 This document describes extensions to the NBMA Next Hop Resolution 48 Protocol (NHRP) [1] 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. 52 3. CONVENTIONS 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [3]. 58 4. NHRP Target Information 60 The mechanism described in this document allows to find an egress 61 router for either a single destination, or a set of destinations 62 (where the set is expressed as a single address prefix). Since a 63 single destination is just a special case of a set of destinations, 64 for the rest of the document we will always talk about a set of 65 destinations, and will refer to this set as an ``NHRP target''. 67 The NHRP target is carried in the NHRP Request, Reply, and Purge 68 messages as an address prefix (using the Destination Prefix Length 69 extension). In order to ensure correctness, a target may be replaced 70 by an identical target with a longer prefix length. Other than this 71 increase of prefix length, no NHS shall modify the NHRP target 72 information in an NHRP message. 74 In general a router may maintain in its Forwarding Information Bas 75 (FIB) routes whose Network Layer Reachability Information (NLRI) that 76 exhibits a subset relation. Such routes are called overlapping 77 routes. To provide correct forwarding in the presence of overlapping 78 routes this document constrains an NHRP target by requiring that all 79 the destinations covered by the target must form a subset of the NLRI 80 of at least one route in the Forwarding Information Base (FIB) of the 81 router that either originates, or propagates an NHRP Request. For the 82 rest of the document we'll refer to this as the ``first NHRP target 83 constraint''. A station can originate an NHRP Request, and a router 84 can propagate an NHRP Request only if the NHRP target of the Request 85 does not violate the first NHRP target constraint. 87 If a received NHRP request does not meet this ``first NHRP target 88 constrant'' when received, the receiving router has two choices. It 89 may answer the request, defining itself as the egress. This is 90 compatible with the base NHRP specification, and preserves the 91 ``first NHRP target constraint''. Alternatively, the router may 92 lengthen the received prefix until the first constraint is met. 94 A route (from a local FIB) whose NLRI forms a minimal superset of all 95 the destinations covered by the NHRP target is called an ``NHRP 96 forwarding route''. Observe, that by definition the set of 97 destinations covered by an NHRP target always exhibits a subset 98 relation to the set of destinations covered by the NHRP forwarding 99 route associated with the target. 101 This document further constrains origination/propagation of NHRP 102 Requests by prohibiting the NHRP target (carried by a Request) to 103 form a superset of the destinations covered by any of the routes in 104 the local FIB. The constraint applies both to the station that 105 originates an NHRP Request and to the routers that propagate the 106 Request. For the rest of the document we'll refer to this constraint 107 as the ``second NHRP target constraint''. A station can originate an 108 NHRP Request, and a router can propagate an NHRP Request only if the 109 NHRP target of the Request does not violate the second NHRP target 110 constraint. The second NHRP target constraint guarantees that 111 forwarding to all the destinations covered by the NHRP target would 112 be accomplished via a single (common) route, and this route would be 113 nothing, but the NHRP forwarding route for the target. 115 Again, if a received NHRP request does not meet the ``second NHRP 116 target constraint'', the router may either respond to the request, 117 providing its own NBMA address, or it may lengthen the prefix in the 118 request so as to meet the second constraint. 120 5. NHRP Requester and Terminator Processing 122 The issue being addressed with the behaviors being mandated in this 123 document is to ensure that sufficient information is present and 124 processed to avoid NHRP shortcuts causing packet forwarding loops. 126 In order to do this, the requester and responder of the request must 127 undertake certain work, and any "border routers" in the forwarding 128 path must also perform certain work. 130 The work performed by the requester and responder consists of two 131 kinds of work. One set is requester only work, and is required in 132 order to determine where the protocol boundaries are. The other set 133 is the route monitoring work. 135 5.1. NHRP IGP information 137 The primary cause of NHRP forwarding loops is the loss of information 138 at a routing protocol boundary. Normally, such boundaries are 139 detected by the router at the boundary. However, it is possible for 140 IGP boundaries to overlap. Therefore, NHRP requesting Routers MUST 141 include the NHRP IGP Identifier extension. This extension indicates 142 what IGP the originator of the request uses. This extension must 143 always be included by a requesting router, since it is not possible 144 to tell a priori whether the eventual resolution of the request will 145 be a host or a router. 147 Because the entire BGP domain is consider one routing domain, the 148 extension also contains an indication as to whether the originator 149 was a BGP speaker. 151 5.2. NHRP Requestor and Responder monitoring 153 NHRP requestors and responders are required monitor routing to 154 mainting correct shortcut information. 156 Once a router that originates an NHRP Request acquires the shortcut 157 next hop information, it is essential for the router to be able to 158 detect any changes that would affect the correctness of this 159 information. The following measures are intended to provide the 160 correctness. 162 Both ends of a shortcut have to monitor the status of the route that 163 was associated with the shortcut (the NHRP forwarding route). If the 164 status changes at the router that generate the NHRP Reply, this 165 router should send a Purge message, so that the NHRP Requester would 166 issue another NHRP. If the status changes at the Requester, the 167 Requester must issue another NHRP. This allows to ensure that when 168 both end of a shortcut are up, any changes in routing that impact 169 forwarding to any of the destination in the NHRP target would result 170 in a revalidation (via NHRP) of the shortcut. Note that in addition 171 to sending purges/reverifies in response to routing changes which 172 directly effect the NHRP target, there is one other case. 174 A router MUST perform the appropriate purge/reverification process if 175 it receives routing updates which case an issued NHRP request to 176 violate either of the the target constraints defined earlier. This 177 is possible at an NHRP originator, and is more likely at border 178 devices. 180 Once a shortcut is established, the Requester needs to have some 181 mechanism(s) to ensure that the other end of the shortcut is alive. 183 Among the possible mechanisms are: (a) indications from the Data Link 184 layer, (b) presence of traffic in the reverse direction that comes 185 with the Link Layer address of the other end, (c) keepalives sent by 186 the other end. This is intended to suppress black holes, when the 187 next hop router in the shortcut (the router that generated Reply) 188 goes down. 190 A requester should establish a shortcut only after the requester 191 determines that the information provided by NHRP is fairly stable. 192 This is necessary in order to avoid initiating shortcuts that are 193 based on transients routing information, and thus would need to be 194 revalidated almost immediately anyway. Thus, a router may wait to use 195 NHRP information if the underlying routing information has recently 196 changed. If the routing protocol being used has a notion of 197 stability, it should be used. Information in a transient or 198 holddown state SHOULD NOT be used, and requests which need to be 199 processed based on such information SHOULD be discarded. 201 6. Border Processing of NHRP Request 203 Processing of an NHRP Request is covered by two sets of rules: the 204 first set for IGP related processing, and the second set for BGP 205 related processing. The rules for IGP processing relate to 206 determining where the IGP borders are (in particular in the case of 207 overlapping IGPs), and then for what must happen at said borders. 209 6.1. Border Determination 211 When a router receives a request, and determines that it is not the 212 NBMA exit router, it must perform a seris of checks before forwarding 213 the request. 215 When a router receives such a Request, the router uses the NHRP 216 target and the NHRP IGP information to check whether (a) the first 217 and the second NHRP target constraints are satisfied, (b) the router 218 it is in the same routing domain as the originator of the Request, 219 and if yes, then whether (c) it is a border router for that domain. 221 When the NHRP target is checked against the forwarding database, a 222 determination must be made as to whether either of the target 223 constraints have been violated. If they are violated, then the 224 router MAY either 226 o Extend the prefix so as to meet the constraints. 228 o replay to the request indicating that it is the destination 230 o return an error indicating which constraint was violated. 232 If the NHRP forwarding route indicates next hop that is not on the 233 same NBMA as the interface on which the Request was received, the 234 router sends back an NHRP Reply and terminates the query. 236 If a router receives a request without IGP information, then it was 237 originated within this domain by a host. If the router is an AS 238 Border Router (ie running BGP), and if the forwarding path exits the 239 AS, then it must behave as a border router for this request. 240 Otherwise, for requests without IGP information, the router is not a 241 border router. 243 For requests with IGP information, the router compares the forwarding 244 information against the IGP in the request. If the forwarding entry 245 indicates that the next hop is to exit the AS (an AS Border Router), 246 then check the BGP behaviors below. 248 When the IGP the next hop was learned from is the same IGP as 249 indicated in the request, then the NHS simply forwards the request. 250 [Of course, as per NHRP, it is free to respond indicating it is the 251 termination of the shortcut, for example when the Router/NHS is a 252 firewall.] 254 When the IGP the next hop was learned fromis different from that 255 listed in the NHRP request, then this NHS is a border router for this 256 request. 258 6.2. Border Behavior 260 In all cases, a border router has two choices. It MAY terminate and 261 respond to the request, responding with its IP and NBMA address. 263 Alternatively, it MAY perform border propagation. 265 6.2.1. Reorigination 267 Open receiving an NHRP request for which the NHS is a border router, 268 if it chooses to propogate the request, it MUST originate a new NHRP 269 request. This request will have a locally generated request 270 identifier, and the same NHRP target information as in the received 271 request. The NHRP IGP Information will be the correct indication for 272 the outgoing interface, with BGP indication if the received request 273 had the BGP indication, or if this transition crosses the AS border. 275 All other extensions are copied from the incoming request to the new 276 request. 278 6.2.2. Response Propagation 280 When an NHRP response is received for a propagated request, the 281 information is copies from the received request, and passed on in a 282 new NHRP response, responding to the originally received request. 283 The prefix length in the received response is copied to the new 284 response. All extensions except the NHRP IGP Information are copied 285 to the new response. 287 In addition, the border router saves state about this information 288 exchange. The saved state includes the NHRP target from the 289 response, with the NHRP prefix length that resulted from the 290 exchange. It also includes the both the original requester, and the 291 identity of the responder. These are used to generate appropriate 292 reverification and purges whenever routing changes in a way that 293 could effect the resolution. 295 6.3. Border Information 297 Somtimes the routing protocol will have provided the border router 298 with enough information to generate a response to an incoming NHRP 299 request. In particular, the border router may have information about 300 IP prefix to NBMA address bindings. If such information is present, 301 it may be used by a border router to produce an NHRP response without 302 actually propagating the request. In such a case, that information 303 must be monitorred for stability to maintain the correctness of the 304 shortcut. 306 7. BGP Operation 308 While the NHRP mechanism described above is mostly constrained to the 309 routers within a single routing domain, the same mechanisms can be 310 used for shortcuts taht span multiple domains. In doing so, one 311 wants to produce as little additional overhead in the BGP space as 312 possible. 314 Therefore, we will treat the space over which BGP runs as a single 315 routing domain. Care must be taken to propagate information across 316 the individual AS without error, and to indicate that one has 317 properly entered the BGP space. 319 Additional complexity in handling multi-domains shortcuts arise if 320 routing information gets aggregated at the border routers (which 321 certainly happens in practice). Since BGP is the major protocol that 322 is used to exchange routing information across multiple routing 323 domains, we'll restrict our proposal to the case where the routing 324 information exchange across domains' boundaries is controlled by BGP. 326 If both the source and the destination domains are on a common NBMA 327 network, and the path between these two domains is also fully within 328 the same NBMA network, then we have only three routing domains to 329 deal with: source routing domain, BGP routing domain, and destination 330 routing domain. If the destination domain is not on the same NBMA as 331 the source domain, then we need to deal only with two domains - the 332 source and the BGP. Note that we treat all routers that participate 333 in a single (common) instance of BGP as a single BGP routing domain, 334 even if these routers participate in different intra-domain routing 335 protocols, or in different instances of the same intra-domain routing 336 protocol. 338 (a) how a border router in the domain that the originator of 339 the Request is in handles the Request (crossing IGP/BGP 340 boundary), 342 (b) how the Request is handled across the BGP domain, and 343 finally 345 (c) how a border router in the domain where the NHRP target is 346 in handles the Request (crossing BGP/IGP boundary). 348 7.1. Handling NHRP Request at the source domain border router 350 When a border router receives an NHRP Request originated from within 351 its own (IGP) routing domain, the border router determines the NHRP 352 forwarding route for the NHRP target carried by the Request. If the 353 router already has the shortcut information for the forwarding route, 354 then the router uses this information to construct a Reply to the 355 source of the NHRP Request. Otherwise, the router originates its own 356 NHRP Request. The Request contains exactly the same NHRP target, as 357 was carried by the original Request; The NHRP IGP Information will 358 indicate that the request was generated by BGP, and will indicate the 359 IGP of the BGP AS being entered. While it is assumed that a BGP 360 transit AS will generally use only one IGP, the IGP information (and 361 border processing) is included to allow all cases. The newly 362 originated Request is sent to the next hop of the NHRP forwarding 363 route. Once the border router receives a Reply to its own Request, 364 the border router uses the next hop information from the Reply to 365 construct its own Reply to the source of the original NHRP Request. 367 If the border router later on receives a Purge message for the NHRP 368 forwarding route, the border router treats this event as if there was 369 a local change in the NHRP forwarding route (even if the there was no 370 changes in the route). 372 This is exactly the same behavior as all other border cases, and is 373 described here for completeness. 375 7.2. Handling NHRP Request within the BGP domain 377 Routers within an AS will check the IGP, and perform appropriate 378 processing based on the IGP match. In general, this will result in 379 normal forwarding of the NHRP request. 381 Therefore, the significant cases occur at the BGP speaking routers. 382 There are two conditions to check for, early exit of the NBMA, and 383 reachability aggregation. Both of these conditions appply to 384 Automnomous systems which do not contain the NHRP target. 386 7.2.1. NBMA exit 388 The BGP router in deciding where to send the NHRP request will 389 determine what the correct exit from the autonomous system is. It 390 will determine if that exit is within the NBMA. If it is not within 391 the NBMA, then the router MUST respond to the NHRP request, 392 indicating its own IP and NBMA addresses as the correct termination 393 of the shortcut. This is because the actual NBMA border device is 394 not in a position to monitor the topology properly. 396 BGP routers within an NBMA which are supporting R2R NHRP SHOULD be 397 configured to know where the NBMA border is. In the absence of such 398 configuration, requests from other router SHOULD be terminated at the 399 BGP router, since it can not tell what will be crossing the border. 400 A BGP router supporting R2R NHRP may be configured to assume that all 401 of its neighbors are within the NBMA, and therefore not perform such 402 early termination. 404 7.2.2. Reachability Aggregation 406 BGP routers aggregate reachability. If the router aggregates 407 reachability that includes the NHRP target, only this router has the 408 visibility to some of the topology changes that can affect the 409 correctness of the route. Therefore, this router is a border router 410 for this NHRP request. 412 It must originate a new request, place the correct information in the 413 request, reeceive the response, and generate the correct response 414 towards the requester. This aggregating router must also monitor 415 routing in case of changes which affect the request. 417 If the router later on receives a Purge message for the NHRP 418 forwarding route, the router treats this event as if there was a 419 change in the NHRP forwarding route (even if the there was no changes 420 in the route). 422 It should be noted that this conditions applies if the router COULD 423 aggregate relevant routing information, even if it currently does 424 not. 426 7.3. Handling NHRP Request at the destination domain border router 428 When a border router receives an NHRP Request from a BGP speaker, and 429 the border router determines that all the destinations covered by the 430 NHRP target of the Request are within the (IGP) domain of that border 431 router, the border router determines the NHRP forwarding route for 432 the NHRP target carried by the Request. The newly formed Request 433 contains exactly the same NHRP target as the received Request; the 434 NHRP IGP Information indicates the IGP this router is using to select 435 the route to the destination. The newly originated Request is sent 436 to the next hop of the NHRP forwarding route. Once the border router 437 receives a Reply to its own Request, the border router uses the next 438 hop information from the Reply to construct its own Reply to the 439 source of the original NHRP Request. 441 If the border router later on receives a Purge message for the NHRP 442 forwarding route, the border router treats this event as if there was 443 a change in the NHRP forwarding route (even if the there was no 444 changes in the route). 446 8. More state, less messages 448 It should be possible to reduce the number of Purge messages and 449 subsequent NHRP messages (caused by the Purge messages) by 450 maintaining more state on the border routers at the source and 451 destination domains, and the BGP routers that perform aggregation 452 along the path from the source to the destination. 454 Specifically, on these routers it would be necessary to keep the 455 information about all the NHRP targets for which the routers maintain 456 the shortcut information. This way when such a router determines 457 that the NHRP forwarding route (for which the router maintains the 458 shortcut information) changes due to some local routing changes, the 459 router could check whether these local changes impact forwarding to 460 the destinations covered by the NHRP targets. Only for the targets 461 that are impacted by the changes the router would send Purge 462 messages. 464 Note that this mechanism (maintaining NHRP targets) precludes the use 465 of Address Prefix Extension - the shortcut will be determined only 466 for the destinations covered by the NHRP target (so, if the target is 467 a single IP address, then the shortcut would be determined only for 468 this address). 470 9. NHRP IGP Information Extension Format 472 0 1 2 3 473 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 0-3 |C|u| Type = 9 | Length = 4 477 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 4-7 | flags |b| Reserved | IGP ID 481 | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 C "Compulsory." If clear, and the NHS does not recognize the 486 type code, the extension mayb safely be ignored. For the 487 IGP Information extension, this bit is clear. 489 [Discussion. There is a deployment tradeoff against 490 robustness in the setting of the C bit.] 492 u Unused and must be set to zero 494 Type The extension type code. For the IGP Information 495 extension, this is 9. 497 Length the length in octets of the value. For this extension, 498 this is 4. 500 flags Other than the "b" flag, these are reserved, SHALL be set 501 to 0 on transmission, and SHALL be ignored on reception. 503 b This flag indicates whether the request (or a predecessor 504 thereof) was originated by a BGP speaker. Set (to 1) to 505 indicate that the BGP speaker has operated on this. 506 Clear (to 0) if not. 508 IGP ID This field indicates the IGP used by the request 509 originator. The currently defined values are: 511 1 = RIP 512 2 = RIPv2 513 3 = OSPF 514 4 = Dual IS-IS 516 10. Open issues 518 The mechanisms described in this document assume that certain routers 519 along a path taken by an NHRP Request would be required to maintain 520 state associated with the NHRP forwarding route associated with the 521 NHRP target carried by the Request. However, it is quite clear that 522 the router(s) may also lose this state. Further study of the impact 523 of losing the state is needed before advancing the use of NHRP for 524 establishing shortcuts among routers beyond Proposed Standard. 526 The mechanisms described in this document may result in a situation 527 where a router would be required to maintain NHRP peering with 528 potentially a fairly large number of other routers. Further study is 529 needed to understand the implications of this on the scalability of 530 the approach where NHRP is used to establish shortcuts among routers. 532 This document doesn't have a proof that the mechanisms described here 533 result in loop-free steady state forwarding when NHRP is used to 534 establish shortcuts among routers. Preliminary analysis indicates 535 that the mechanisms herein are sufficient. Further analysis should 536 be done as part of advancing beyond Proposed Standard. 538 11. Security Considerations 540 Security is provided in the base NHRP protocol, using hop-by-hop 541 authentication. There is no change to the fundemental security 542 capabilities provided therein when these extensions are used. It 543 should be noted that the assumption of transitive trust which is the 544 basis of such security may well be significantly weaker in an inter- 545 domain environment, and administrators of border routers should take 546 this into consideration. 548 12. References 550 [1] J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy., 551 "NBMA Next Hop Resolution Protocol", RFC-2332, USC/Information 552 Sciences Institute, April 1998. 554 [2] D. Cansever., "NHRP Protocol Applicability Statement", RFC-2333, 555 USC/Information Sciences Institute, April 1998 557 [3] S. Bradner., "Key words for use in RFCs to Indicate Requirement 558 Levels", RFC-2119, USC/Information Sciences Institute, March 1997. 560 13. Acknowledgements 562 To be supplied.