idnits 2.17.1 draft-ogawa-receiver-shortcut-path-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 343: '... router MUST become the responder t...' RFC 2119 keyword, line 373: '...ields in the CIE MUST be ignored and S...' RFC 2119 keyword, line 404: '...f CIE Code is 0 then it MUST send this...' RFC 2119 keyword, line 405: '...h, otherwise this message MUST be sent...' RFC 2119 keyword, line 444: '...Protocol Address SHOULD be set to 0, b...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This message is used by a sender host to request a shortcut path. Unlike the NHRP Resolution Request, the nearest router or NHS of the destination simply forwards this message to the destination host. If the destination is outside of the NBMA subnet, then the egress router MUST become the responder to answer this request and it MUST not forward this request to the next NBMA subnet. -- 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 (March 1997) is 9876 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) == Unused Reference: '3' is defined on line 686, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1577 (ref. '1') (Obsoleted by RFC 2225) == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-11 -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-00 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jun Ogawa 2 Expires September 1997 (Fujitsu Laboratories LTD.) 3 Yao-Min Chen 4 (Fujitsu Laboratories of America INC.) 6 March 1997 8 The Receiver-Initiated Shortcut Path Protocol (RISP) 9 11 Status of This Memo. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check 25 the ``1id-abstracts.txt'' listing contained in the Internet- 26 Drafts Shadow Directories on ftp.is.co.za (Africa), 27 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (WE West Coast). 30 Abstract 32 This memo defines the Receiver Initiated Shortcut Path (RISP) 33 protocol for NBMA networks. The protocol extends the NHRP message 34 set by adding Callback Request and Reply messages to allow the 35 destination host (or its corresponding egress router) to establish 36 a shortcut path for a data flow, using the existing NBMA signaling 37 protocols. Because of this receiver-initiated mechanism, a 38 shortcut-capable network can use just the NBMA ARP servers, such as 39 the ATMARP servers, instead of the more complex Next Hop 40 Servers. This draft also describes how to extend NHRP with the new, 41 receiver-initiated mechanism. 43 1. Introduction 45 A main goal of the IP over NBMA Networks (ion) working group is to 46 define efficient address resolution mechanisms for establishing 47 NBMA paths suitable for IP flows. Towards this goal, Classical IP 48 over ATM [1] and Next-Hop Address Resolution Protocol (NHRP) [2] 49 are outputs from the working group that have received significant 50 attention. The strength of Classical IP over ATM is its simplicity 51 but it cannot establish shortcut paths across multiple logical IP 52 subnetworks. NHRP establishes the shortcuts but the complexity of 53 Next Hop Servers may prevent its rapid adoption. In this memo, we 54 describe a way to establish shortcut paths without the complexity 55 of Next Hop Servers. 57 RFC 1577 [1] defined the concept of Logical IP Subnetwork (LIS) 58 which is a separate administrative entity where hosts and routers 59 are configured within a closed IP subnetwork. In this memo, we 60 describe a protocol to establish shortcut paths without the 61 complexity of Next Hop Servers. 63 The protocol is called Receiver-Initiated Shortcut Path (RISP). It 64 works on an environment where an NBMA subnet is divided into 65 multiple Logical IP Subnetworks (LISs, see reference [1]). This is 66 the same environment considered by both Classical IP over ATM and 67 NHRP. 69 Below, we briefly review Classical IP over ATM and NHRP and then 70 introduce RISP as a simple method to establish inter-LIS shortcut 71 paths. 73 1.1 Classical IP over ATM 75 First of all, a client must register its IP address and ATM address 76 with an ATMARP Server using Inverse ATM Address Resolution Protocol 77 (InATMARP). A client connects to the ATMARP server using a 78 point-to-point VC. 80 In the case of Intra-LIS path establishment, a sender client 81 resolves the receiver's ATM address using the ATMARP server. Then 82 the sender client establishes a path and sends IP packets along it. 84 In the case of Inter-LIS, a sender client sends IP packets to a 85 router. The router transmits these packets to the receiver using the 86 ordinary routing table constructed by a routing protocol such as RIP 87 or OSPF. 89 Therefore, intermediate routers become bottleneck for the speedy 90 transmission of data packets. 92 1.2 Next Hop Resolution Protocol 94 First of all, a client host must register its Protocol and NBMA 95 addresses with an Next Hop Server (NHS) using an NHRP Registration 96 Request message. For example, if the internetwork-layer protocol is 97 IP and the underlying subnet-layer NBMA network is ATM, the client 98 registers its IP and ATM addresses with the NHS. 100 In both intra- and inter-LIS communications, a sender client sends 101 an NHRP Resolution Request to the nearest NHS to resolve the 102 destination NBMA address. If the NHS cannot resolve it, it forwards 103 the request to the destination using the ordinary routing table 104 because the NHS is also equipped with router function. Eventually, 105 the NHS (router) nearest to the destination resolves the NBMA 106 address. 108 Once the destination NBMA address is resolved, the sender 109 establishes a shortcut path to the receiver. Therefore, inter-LIS 110 communication under NHRP does not suffer the router bottleneck 111 problem in Classical IP over ATM. 113 NHRP also allows an intermediate NHS to cache the NBMA address of a 114 destination so that later the NHS can directly resolve a request 115 instead of forwarding it. 117 In addition, note that NHRP offers not only shortcut path 118 establishment but also a rich set of functions beyond what is 119 provided by Classical IP over ATM. Here we briefly mention a few. 121 1) An NHS can resolve the NBMA address for an equivalent class of 122 internetwork layer addresses using the prefix length field in an 123 NHRP message (See Section 5.2.0.1 of [2] for more details). This 124 is useful when several Protocol addresses share an NBMA address. 126 2) An NHS can resolve an NBMA address from a Protocol address using 127 the U bit (which indicates that the NBMA address is unique to the 128 Protocol address). 130 3) To invalidate the cached information at a station(e.g. NHC or 131 NHS), NHRP Purge Request is defined. This message facilitates the 132 coherency of the information cached at multiple stations. 134 However, the rich set of functions comes at the price of complexity 135 at NHSs, which we summarize below and discuss in more depth in 136 Appendix-A. 138 a) Along with the conventional router function, an NHS must maintain 139 a database for address resolution. In addition, all routers in 140 the NBMA network must be equipped with this function when using 141 NHRP in the network. 143 b) When a LIS has multiple routers (NHSs), they need a mechanism to 144 synchronize the cached information. SCSP [4] is such a mechanism 145 being drafted by the ion working group. 147 c) NHRP allows a transit NHS to cache the entries contained in the 148 received NHRP Resolution Replys (i.e., the resolved Protocol/NBMA 149 address mappings in the messages). Subsequently the NHS can 150 resolve an NHRP Resolution Request using the cached entries. 152 However, the NHS also needs to keep track of the source address 153 of the request (see Appendix-A.2 for a more thorough discussion 154 on this aspect). 156 In summary, the main reason for the complexity of NHS is that NHRP 157 requires that the routers also perform address resolution for both 158 intra- and inter-LIS communications. Consider a network that is 159 based on Classical IP over ATM. When it migrates to NHRP, 160 complexity incurred on all routers due to additional requirements in 161 a)- c). In some cases a network operator may not want the 162 complexity in spite of the benefits provided by NHRP. For example, 163 the operator may be satisfied with just the provision of "inter-LIS 164 shortcut paths" but rather uses Classical IP over ATM for intra-LIS 165 paths. For this kind of networks, this document describes a simple 166 way to establish shortcut paths without the need of inter-LIS 167 address resolution. 169 1.3 Receiver-Initiated Shortcut Path Protocol 171 The protocol adopts Classical IP over ATM for intra-LIS 172 communication and defines a receiver-initiated setup mechanism for 173 inter-LIS shortcut paths. Such a shortcut path is set up by the 174 following four phases. In the Request phase, a sender sends a 175 request along a routed (i.e., hop-by-hop) path. In the Respond 176 phase, a responder, which can be either a destination host or an 177 egress router, sets up a shortcut path back to the sender, and then 178 sends a responding packet along the path. In the Transmit phase, 179 data are transmitted between the sender and receiver through the 180 shortcut path. In the Close phase, either the sender or the 181 responder sends a release packet to its peer, which then tears down 182 the path. A complete specification of the protocol will be given in 183 Section 3, after we introduce terminology in Section 2. 185 The protocol can stand alone (without NHRP) as an inter-LIS shortcut 186 protocol, or its functionality can be integrated into NHRP. It can 187 also be used as a transit step for the migration of ATMARP-based 188 networks to NHRP networks, because it offers inter-LIS shortcut 189 paths with just ATMARP servers. If later a network requires the 190 richer set of functions provided by NHRP, it can migrate to NHRP. 191 For this reason, we choose a packet format closely tied to the NHRP 192 packet format. The packet format is described in Section 4, and the 193 migration is discussed in Section 5. 195 2. Terminology 197 A "RISP host" refers to a host machine that can process RISP 198 messages. Where there is no ambiguity, we will refer to a RISP host 199 simply as a "host". 201 A "RISP router" is a router performing conventional 202 forwarding/routing functions as well as being capable of handling 203 RISP messages including Callback Request, Callback Reply and Error 204 Indication. The routers described in this memo, unless otherwise 205 mentioned, refer to RISP routers. 207 3. Protocol Overview 209 Currently, we only consider an IP-over-ATM environment. However, it 210 is possible to generalize the draft for other NBMA networks. This is 211 currently under study. 213 The protocol does NOT use any servers for establishing a path across 214 multiple LISs, but only uses ATMARP servers for intra-LIS address 215 resolution. So, 217 1) for inter-LIS communication, a host does not need to know the NBMA 218 address of its destination before initialing communication, 219 2) a router does not need to maintain a database for the purpose of 220 address resolution, and 221 3) a destination host can refuse a shortcut path request. 223 Below, we specify the protocol by specifying how inter- and intra-LIS 224 communications are conducted. As we mentioned earlier, the messages 225 used by the protocol will follow the NHRP basic packet format. 226 Therefore, we add "NHRP" in front of these messages to indicate this 227 fact. 229 3.1 Inter-LIS Communication 231 By default, a source host sends IP packets to the destination 232 through routers (hop by hop). We call a path taken this way a 233 "routed" path. 235 If the host decides that a shortcut path is more suitable for a flow 236 than the routed path, it sends an NHRP Callback Request message to 237 the destination along the routed path. We refer to this host as the 238 requester for the NHRP Callback Request. 240 An NHRP Callback Request message has the IP and ATM addresses of its 241 requester. It also has a Request ID to uniquely identify the 242 message. 244 When the destination or its egress router (if the destination is not 245 on the NBMA subnet) receives the NHRP Callback Request, it starts 246 establishing a shortcut path back to the requester, using the NBMA 247 signaling such as UNI*. This signaling is possible because the ATM 248 address of the requester is contained in the NHRP Callback 249 Request. We call the destination host or egress router the responder 250 for the Callback Request. 252 If the NHRP Callback Request packet contains an error then the 253 responder sends the NHRP Error Indication with appropriate Error 254 Code as described in [2]. 256 As soon as the shortcut path is established, the responder sends an 257 NHRP Callback Reply along the path to the requester. 259 The NHRP Callback Reply message contains the IP and ATM addresses of 260 the responder. It also has a Request ID which is identical to the 261 Request ID of the NHRP Callback Request. 263 Upon receiving an NHRP Callback Reply, the requester verifies if the 264 Request ID in the message is the same as in the NHRP Callback 265 Request it issued. If they are the same, the shortcut path 266 establishment has completed. Otherwise, the shortcut path must be 267 terminated by the requester. 269 After the establishment, the requester re-directs its data packets 270 from the routed path to the shortcut path. 272 On the other hand, if the path establishment fails, the responder 273 sends an NHRP Callback Reply along the routed path. Such a failure 274 may occur because of lack of resources at the responder or some 275 layer-2 problem. In Section 4.2, we have a more thorough 276 discussion. 278 To terminate a shortcut path, either the requester or the responder 279 sends an NHRP Release Request message to its peer. When the peer 280 receives the message, it disconnects the shortcut path. 282 If the requester sends an NHRP Callback Request but does not receive 283 any NHRP Callback Reply or Error Indication messages with the 284 Request ID, it sends an NHRP Callback Request again with the same 285 Request ID. The interval between the NHRP Callback Requests and the 286 number of times for the re-transmission are for further study. 288 If the path establishment fails, the requester continues to send IP 289 packets through the routed path. 291 +-------+ +-------+ +-------+ +-------+ 292 | src |-------|Router |------|Router |------| dst | 293 | | +-------+ +-------+ | | 294 +-------+ +-------+ 295 (1) ------->------------->--------------> NHRP Callback Request 296 (hop by hop) 298 (2) <==================================== establish a shortcut 299 path 301 (3) <------------------------------------ NHRP Callback Reply 302 : 304 (4) <------------------------------------ NHRP Release Request 306 (5) The shortcut path terminates 308 Fig.1 Typical usage of RISP. 310 3.2 Intra-LIS 312 In the case of Intra-LIS address resolution, the protocol uses 313 Classical IP over ATM. Therefore, when a host wants to join a LIS, 314 it registers its IP and ATM addresses with an ATMARP server. 316 3.3 Authentication 318 The protocol also provides an authentication mechanism, which is 319 described in Appendix-B. The protocol has the option to work without 320 the mechanism. 322 3.4 Summary 324 The simplicity of the protocol lies in the fact that it does not 325 require address resolution function to establish an inter-LIS 326 shortcut path, because such a path is established by the receiver 327 using NBMA signaling. 329 4. Messages 331 The protocol requires that the NHRP to extend its message set and 332 assign packet type values(ar$op.type) to the new messages NHRP 333 Callback Request, NHRP Callback Reply, and NHRP Callback Release. 334 If a network merely uses the RISP functions, it only needs to 335 support these messages along with NHRP Error Indication. 337 4.1 NHRP Callback Request 339 This message is used by a sender host to request a shortcut path. 340 Unlike the NHRP Resolution Request, the nearest router or NHS of the 341 destination simply forwards this message to the destination host. If 342 the destination is outside of the NBMA subnet, then the egress 343 router MUST become the responder to answer this request and it MUST 344 not forward this request to the next NBMA subnet. 346 NHRP Callback Request's mandatory part is coded as described in 347 Section 5.2.0.1 of [2]. 349 The message specific meanings of the fields are as follows, 350 Flags - The flags field is coded as follows, 352 0 1 353 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |Q| unused | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Q 359 Set if the station sending the NHRP Resolution Request is a 360 router; clear if it is a host. 362 Zero or one CIE may be specified in an NHRP Callback Request. If a 363 CIE is specified then that entry carries the pertinent information 364 for the client sourcing the NHRP Callback Request. The usage of the 365 CIE is described below: 367 Maximum Transmission Unit 368 This field gives the maximum transmission unit for the source 369 station. A possible use of this field in the NHRP Callback 370 Request packet is for the requester to ask for a target MTU. In 371 lieu of that usage, the CIE must be omitted. 373 All other fields in the CIE MUST be ignored and SHOULD be set to 0. 375 All the Extension Parts of the NHRP can be used, but some of it may 376 be meaningless to the NHRP Callback Request (e.g., the NHRP Reverse 377 Transit NHS Record Extension). 379 4.2 NHRP Callback Reply 381 This message is used by a responder to reply to an NHRP Callback 382 Request. The message is sent along the shortcut path established for 383 the NHRP Callback Request if the path establishment is successful, 384 otherwise it is sent along the routed path. 386 NHRP Callback Reply's mandatory part is coded as described in 387 Section 5.2.0.1 of [2]. 389 The message specific meanings of the fields are as follows, 391 Flags - The flags field is coded as follows, 393 0 1 394 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 |Q| unused | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Q 400 Copied from the NHRP Callback Request. Set if the requester is 401 a router; clear if it is a host. 403 One CIE is specified in the NHRP Callback Reply. The CIE contains 404 the responder's information. If CIE Code is 0 then it MUST send this 405 message along the shortcut path, otherwise this message MUST be sent 406 along the routed path. 408 Code 409 If this field is set to 0 then this packet contains a positively 410 acknowledged NHRP Callback Reply. If this field contains any 411 other value then this means NAK for the shortcut 412 establishment. CIE Codes are defined temporary as follows: 414 0 - The shortcut path is established successfully. 416 The NHRP Callback Request is accepted by its responder, and the 417 shortcut path is established successfully. 419 32 - Not enough resource is available to establish the cut 420 through path. 422 The responder receives the NHRP Callback Request correctly, but 423 it does not have enough resources to establish the shortcut path 424 requested. 426 33 - The shortcut path establishment fails because of the 427 sublayer. 429 The responder receives the NHRP Callback Request correctly, but 430 it fails to establish the shortcut path after using the NBMA 431 signaling such as UNI*. 433 34 - Establishment the shortcut path is prohibited by the 434 administrator. 436 An administrator of the responder prohibits the shortcut path to 437 the responder. 439 Prefix Length and Maximum Transmission Unit fields are used as 440 described in Section 5.2.0.1 of [2]. 442 All other fields in the CIE, such as Holding Time, Cli Addr T/L, Cli 443 SAddr T/L, Cli Proto Len, Preference, Client NBMA Address, Client 444 NBMA Subaddress, Client Protocol Address SHOULD be set to 0, because 445 the NHRP Callback Reply is not used for the address resolution. 447 4.3 NHRP Release Request 449 The message is used by a host to ask its peer to disconnect the 450 shortcut path between them, if the two hosts are located at 451 different LISs. 453 When a requester or responder wants to release a shortcut path, it 454 sends this message to its peer along the shortcut path. When the 455 peer receives the message and is ready to release the path, it uses 456 NBMA signaling to disconnect the path. 458 This message facilitates a host to detect whether a path termination 459 is legal. Note that NHRP does not define any message for a host to 460 notify its peer about path termination. This makes it difficult to 461 distinguish whether the path is terminated by a peer or due to some 462 intermediate switching entity failure. Hence, the NHRP Release 463 Request message can be a useful addition to NHRP. 465 Note that it is possible to release a shortcut path without using 466 NHRP Release Request. 468 If this message is not received through a shortcut path across 469 multiple LISs, it must be discarded. Also a host can only send an 470 NHRP Release Request message along a path where it has received or 471 sent an NHRP Callback Reply, so that the NHRP Release Request 472 Message is not sent along a path established by Classical IP over 473 ATM. 475 Flags - The flags field is coded as follows, 477 0 1 478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | unused | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 No CIE is specified in the NHRP Release Request. 485 5. Migration to the "full-set" NHRP 487 We consider the "full-set" NHRP as the current NHRP proposal [2] plus 488 the functions defined in RISP. Adding the functions to NHRP has 489 following advantages. 491 First, a receiver can refuse a shortcut path request. For example, 492 an NHC may have a filter to determine which sender addresses are 493 allowed shortcut paths, or it may decide to accept or deny a shortcut 494 path request according to its load and resource level. This kind of 495 dynamic decision is difficult if done by an NHS. 497 Second, some networks may allow services charged on receivers. In 498 this case, it is desirable to let the receivers control the shortcut 499 path establishment. 501 When migrating to the full-set NHRP, an NHS must route/forward the 502 NHRP Callback Request/Reply messages to its destination unless the 503 NHS happens to be the egress router for the destination. 505 If an NHS receives an NHRP Callback Request destined for a host in 506 its LIS and does not have a cache for the host address, it MUST send 507 NHRP Error Indication packet with the Error Code 6(Protocol Address 508 Unreachable) to stop the requester from re-sending the NHRP Callback 509 Request. 511 6. Security Considerations 513 Security Considerations are not discussed in this memo. 515 7. Intellectual Property Considerations. 517 Fujitsu Laboratories Limited may seek patent or other intellectual 518 property protection for some or all of the technologies described in 519 this document. 521 Appendix-A Complexity of the NHRP Servers. 523 A-1: Necessity of the SCSP. 525 When a LIS has more than one router(e.g.NHS), all the routers 526 belonging to the LIS use SCSP to synchronize their cached 527 information. 529 <------- LIS -------> 531 +-------+ +-------+ 532 | NHS1 |------+-------+------| NHS2 | 533 +-------+ | | +-------+ 534 \ / 535 \ / 536 +-------+ 537 | NHC1 | 538 | | 539 +-------+ 541 (1) <------ NHRP Registration Request 542 (2) ------> NHRP Registration Reply 544 (3) <=====================> 545 Registration synchronization by SCSP 547 Fig.A-1: NHRP requires SCSP for cache synchronization 549 In the case of Fig.A-1, both NHS1 and NHS2 must be able to resolve 550 the ATM address of NHC1, but NHC1 only registers with NHS1. So NHS1 551 tells NHS2 about NHC1's IP/ATM address using SCSP. 553 A-2: Necessity of Memorizing NHRP Resolution Requests 555 NHRP allows that a transit NHS receiving an NHRP Resolution Reply 556 (e.g., NHS1 of Fig. A-2) caches its entries (the resolved IP/ATM 557 address in NHRP Resolution Reply). The destination of an NHRP 558 Resolution Reply (e.g., NHC1 of Fig. A-2) is allowed to cache too. 560 Consider the example in Fig. A-2. In order to purge the cached 561 Resolution Reply at NHS1 and NHC1 in Step (6), NHS2 has to remember 562 having forwarded NHRP Resolution Request in Step (1). 564 +-------+ +-------+ +-------+ +-------+ 565 | NHC1 |-------| NHS1 |------| NHS2 |------| NHC2 | 566 | (src) | +-------+ +-------+ | (dst) | 567 +-------+ +-------+ 569 (1) ------->-------------> NHRP Resolution Request 570 NHRP Resolution Request has cached at NHS2. 572 (2) <----------------<----- NHRP Resolution Reply 573 The content of NHRP Resolution Reply is cached at NHS1 and NHC1. 574 : 575 (3) -------> NHRP Resolution Request 577 (4) <------- NHRP Resolution Reply 578 : 579 (5) <----- NHRP Purge Request 581 (6) <-------<------------- NHRP Purge Request 583 Fig.A-2: NHRP Purge requires stations to memorize 584 earlier NHRP Resolution Requests 586 Appendix B The Authentication Mechanism for RISP 588 In the case of the NHRP, an NHC resolves the ATM address of a 589 destination using an NHRP Resolution Request message. Later, this 590 requester can establish the shortcut path to the same destination 591 without another NHRP Resolution Request because it already knows the 592 ATM address of the destination. Therefore, the intermediate routers 593 cannot authenticate each shortcut path. 595 If RISP stands alone as the inter-LIS shortcut protocol, 596 authentication of each short-cut path is straightforward. 598 A source may know the ATM address of a destination through a 599 previous shortcut path establishment. However, later if the source 600 sets up a shortcut path to the same destination (e.g., Step (6) in 601 Fig. B-1), it does not have a Request ID from the destination and so 602 it cannot send a proper NHRP Callback Reply along the path to the 603 destination and so the destination will disconnect the path (e.g., 604 Steps (7) and (8) in Fig. B-1). 606 +-------+ +-------+ +-------+ +-------+ 607 | src |-------|Router |------|Router |------| dst | 608 | | +-------+ +-------+ | | 609 +-------+ +-------+ 610 (1) ------->------------->--------------> NHRP Callback Request 611 (hop by hop) 613 (2) <==================================== establish a shortcut 614 path 616 (3) <------------------------------------ NHRP Callback Reply 617 : 618 (4) <------------------------------------ NHRP Release Request 620 (5) The shortcut path terminates 621 : 622 : 623 (6) ====================================> establish a shortcut 624 path 626 (7) Can not send an NHRP Callback Reply 628 (8) The shortcut path terminates by dst 630 Fig.B-1 A shortcut path without an NHRP Callback Request cannot be 631 authenticated. 633 The following authentication rules are only optional and its 634 adoption is a local decision matter; RISP can work without 635 implementing these rules. However, if RISP is integrated with NHRP, 636 these rules MUST NOT be adopted (see Chapter 5 for discussion about 637 the migration to the full set NHRP). 639 (1) A host that has a path without a corresponding NHRP Callback 640 Reply needs to check first whether the path is established by 641 Classical IP over ATM (i.e., whether the other end of the path 642 is within the same LIS). If it is, the host MUST accept IP 643 packets from the path, for backward compatibility with Classical 644 IP over ATM (because if the path is established by the Classical 645 IP over ATM for intra-LIS communication, no NHRP Callback Reply 646 is sent along the path). 648 To verify whether the path is established via Classical IP over ATM, 649 the host sends an InATMARP Request to the ATMARP server to acquire 650 the IP address of the remote host. For this to work, ATMARP server 651 MUST accept the InATMARP Request and reply it using information 652 cached (although current RFC1577 does not require this on ATMARP 653 servers). 655 If the address resolved is in the same LIS as the host, it knows 656 that the path is established by Classical IP over ATM and so accepts 657 IP packets sent along the path. Otherwise, we recommend that the 658 host terminate the path quietly. 660 (2) For hosts belonging to different LISs, the normal Request ID 661 authentication process MUST be followed. In other words, if a 662 requester has a shortcut path along which it never receives an 663 NHRP Callback Reply with the proper Request ID but receives some 664 other IP packets, the requester MUST terminate the path. 666 The details of this authentication mechanism is for further 667 study. For example, in the case of (1), the handling of the packets 668 that are received while the host communicates with its ATMARP server 669 is yet to be determined. Also, RISP requires an NHRP Callback 670 Request for each path establishment, while under NHRP, a host does 671 not need to send an NHRP Resolution Request if it already has the 672 destination NBMA address in its cache. Therefore, considering the 673 number of request packets that are passed through the routers, the 674 number of NHRP Callback Requests, under RISP, may be significantly 675 larger than the number of NHRP Resolution Requests under NHRP. We 676 are investigating whether this increase in packet count will be a 677 disadvantage of the RISP authentication mechanism. 679 References 681 [1] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. 683 [2] NBMA Next Hops Resolution Protocol (NHRP), James V. Luciani, 684 draft-ietf-rolc-nhrp-11.txt 686 [3] Classical IP to NHRP Transition, James V. Luciani, 687 raft-ietf-ion-transition-00.txt 689 [4] Server Cache Synchronization Protocol (SCSP), James V. Luciani, 690 Grenville Armitage, and Joel Halpern, draft-ietf-ion-scsp-00.txt. 692 Acknowledgments 694 We would like to thank David Richard and Steven A. Wright of 695 Fujitsu Network Communications Inc. and Walter Sotelo of Hal Computer 696 for insightful suggestions and comments. 698 Authors' Addresses 700 Jun Ogawa 701 Fujitsu Laboratories LTD. 702 4-1-1 Kamikodanaka Nakahara-ku Kawasaki 211-88 703 Japan 704 Phone: +81-44-754-2629 705 E-mail: ogawa@flab.fujitsu.co.jp 707 Yao-Min Chen 708 Fujitsu Laboratories of America, INC. 709 3350 Scott Blvd.,Bldg.#34, Santa Clara, CA 95054-3104 710 USA 711 Phone: +1-408-567-4513 712 E-mail: ychen@fla.fujitsu.com