idnits 2.17.1 draft-guerin-issll-rsvp-shortcut-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-04-24) 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. ** 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 a Security Considerations 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([J96], Ber97a], [BB97,GB97,, [LKPC97]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 407: '..., then those VCs MUST be released. Th...' RFC 2119 keyword, line 417: '... SHOULD stop sending the RSVP contro...' RFC 2119 keyword, line 431: '... The old QoS VC MUST continue to be u...' RFC 2119 keyword, line 433: '... request MUST be answered with an er...' RFC 2119 keyword, line 434: '...ion, the request MUST be treated as if...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (30 July 1997) is 9765 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) -- Possible downref: Normative reference to a draft: ref. 'BB97' == Outdated reference: A later version (-04) exists of draft-ietf-issll-atm-imp-guide-01 == Outdated reference: A later version (-03) exists of draft-ietf-issll-atm-imp-req-00 == Outdated reference: A later version (-06) exists of draft-ietf-issll-atm-mapping-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'J96' == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-11 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R.Guerin/D.Kandlur/L.Li/V.Srinivasan 2 INTERNET DRAFT IBM 3 L.Berger 4 Fore 5 30 July 1997 7 Support of Shortcuts for RSVP Flows Over ATM 8 draft-guerin-issll-rsvp-shortcut-00.txt 10 Status of This Memo 12 This document is an Internet-Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months, and may be updated, replaced, or obsoleted by other documents 19 at any time. It is not appropriate to use Internet Drafts as 20 reference material, or to cite them other than as a "working draft" 21 or "work in progress." 23 To learn the current status of any Internet-Draft, please check 24 the "1id-abstracts.txt" listing contained in the internet-drafts 25 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Abstract 31 Support for RSVP flows across an ATM network has been defined in 32 [BB97, GB97, Ber97a]. Although the use of shortcuts was mentioned in 33 [BB97, Sec. 3.7], and [Ber97a, Sec. 3.6] the current specifications 34 do not address this case in sufficient details so as to allow 35 interoperable implementations. The purpose of this document is to 36 identify issues in using ATM shortcuts for RSVP flows. For purposes 37 of illustrations, the NHRP protocol [LKPC97] will be assumed as 38 the mechanism used to discover shortcuts, and a possible interface 39 between RSVP and NHRP will be outlined. However, it should be noted 40 that other shortcut mechanisms are possible, e.g., PAR [J96], and 41 the general conclusions of this document should also hold in such 42 cases. Since the issue of shortcut discovery is significantly more 43 complex in the multicast case, for which in most instances has not 44 been defined, e.g., NHRP, this document is limited to the case of 45 unicast flows. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Overview and Issue 1 54 1.1. General Design Principles . . . . . . . . . . . . . . . . 3 56 2. RSVP Shortcut Interactions 5 57 2.1. RSVP Control Message Handling . . . . . . . . . . . . . . 5 58 2.2. Data VC Operations . . . . . . . . . . . . . . . . . . . 7 59 2.3. Error Handling Scenarios . . . . . . . . . . . . . . . . 8 61 3. Sample RSVP-NHRP Interface 9 63 4. Interaction with MPOA 11 65 5. Example of RSVP Shortcut 12 67 1. Overview and Issue 69 In order to understand the implications of establishing and using 70 shortcuts for RSVP flows across ATM networks, it is helpful to first 71 review how shortcuts are established and used. For purposes of 72 illustration, we focus on the case of the NHRP protocol (Next-Hop 73 Routing Protocol) [LKPC97]. However, most of the conclusions would 74 also hold when using other shortcut establishment mechanisms, e.g., 75 PAR [J96]. 77 NHRP is a next hop discovery protocol, that allows progressive 78 discovery of the layer 2 addresses of layer 3 next hops for a given 79 network (IP) destination address. In other words, NHRP allows a 80 network layer protocol such as IP to propagate a query to determine 81 whether, for a given destination (or sets of destinations), some of 82 the network layer routing hops can be bypassed by establishing a 83 shortcut across the layer 2 (ATM) topology. This is illustrated in 84 Figure 1, where ATM switches are represented with triangles, while 85 rectangles are used for IP routers. 87 _ _ _ _ 88 |_|R2 |_|R3 |_|R4 |_|R5 89 \ \ \ / 90 \ \ \ / 91 _ _s1 \_s3 \_s5 \ _/ _s8 _ 92 R1|_|---/_\-------/_\---------/_\---------/_\----/_\-----|_|R6 93 \ | | / s7 / 94 \ --- --- / / 95 \ \ / / / 96 \ _s2 \ _ / s6_ / / 97 /_\--------/_\---------/_\------/ 98 s4 100 Routed path: R1-(s1-s3)-R2-(s3-s5)-R3-(s5-s7)-R4-(s7)-R5-(s7-s8)-R6 101 Shortcut: R1-(s1-s2-s4-s6-s8)-R6 103 Figure 1: Routed Path vs Shortcut. 105 Irrespective of whether they are obtained through NHRP or some 106 other means, the potential benefits of shortcuts are to off-load 107 network layer processing of the packets from the routing hops being 108 bypassed, and also to possibly achieve better delay and/or throughput 109 performance for the data flow between the source and the destination. 110 In the case of RSVP flows, another benefit is the opportunity to 111 better leverage the layer 2 topology to support QoS requirements, 112 i.e., improve the likelihood that the necessary resources (bandwidth 113 and buffer) are available. 115 There are two main aspects to the use of ATM shortcuts for 116 RSVP. The first concerns the internal (within the router or the 117 RSVP-ATM gateway) interactions between RSVP and the shortcut 118 establishment mechanism, e.g., NHRP. The second, and possibly more 119 important, aspect deals with the external flows associated with the 120 establishment of shortcuts, and in particular their coexistence with 121 existing uses of shortcut mechanisms, i.e., for non-RSVP flows. 123 In many implementations, the decision to establish a shortcut for 124 some best effort traffic flow is traffic dependent. For example, 125 a shortcut request is triggered only when the traffic volume to 126 the destination exceeds a certain threshold, and thus warrants the 127 overhead (signaling and support of an additional VC) of setting up 128 the shortcut. In addition, how long the shortcut remains in effect 129 is also typically traffic dependent, so that a shortcut will be taken 130 down if the amount of traffic falls below a given threshold, or 131 after some time-out period. This means that the "routes" associated 132 with shortcuts, in addition to violating network protocol rules by 133 crossing subnet boundaries, are also temporary in nature. As a 134 result, routes associated with shortcuts will normally NOT show-up in 135 the "standard" IP routing table, and will only be reflected in the 136 forwarding information base of the router. 138 The limited visibility, to IP routing, of shortcuts has some 139 implications for RSVP. Specifically, when RSVP queries IP routing 140 to obtain the NHOP to which to send a packet, the route that is 141 returned is the default (hop-by-hop) path and not the shortcut 142 path. As a result, RSVP control packets will flow on the default 143 hop-by-hop path, while the data packets of the associated flow will 144 be forwarded on the existing shortcut, if any, together with the rest 145 of the default traffic to that destination. However, if and when a 146 reservation is made and the classifier in the IP forwarding fastpath 147 is updated at the ingress router, the RSVP data packets will start 148 being forwarded on the routed path which is where the reservation 149 was made. In some instances, this may have the unfortunate effect 150 that the user may see lower performance (higher delay) once the 151 reservation is in place. This is clearly not desirable, and further 152 motivates the need for allowing RSVP flows to also use shortcuts. 154 As alluded to earlier, this requires the definition of an interface 155 between RSVP and the shortcut mechanism, that will support the 156 necessary interactions. In particular, RSVP, or the RSVP-ATM 157 gateway, must be able to query the shortcut mechanism, and to request 158 the establishment of a new shortcut VC. In addition, the management 159 of shortcuts for both RSVP and best-effort traffic to the same 160 destination needs to be coordinated, and this requires additional 161 interactions between RSVP and the shortcut mechanism. Before 162 proceeding with more detailed discussions on each of these aspects, 163 we briefly review some of the general design issues and choices in 164 using shortcuts for RSVP flows. 166 1.1. General Design Principles 168 The main design principle followed in this document to support 169 shortcuts for RSVP flows is: 171 Separate but consistent shortcuts for RSVP data and control 172 messages. 174 There are several implications of this principle. 176 1. Receipt of an RSVP PATH message will trigger the establishment 177 of a best-effort shortcut unless one is already in place for the 178 same destination. 180 Note that in the case where a shortcut is already in place, 181 it may be necessary to verify that this existing shortcut is 182 adequate, i.e., whether or not a more appropriate shortcut might 183 be available for the destination address of the RSVP flow. This 184 implies that for every new flow, RSVP should always check for 185 the most appropriate shortcut to the flow's destination. In 186 the case of NHRP, in order to ensure that the most appropriate 187 shortcut possible is indeed returned, e.g., that the query is 188 propagated as far as possible, some extensions to the current 189 NHRP operation are desirable. Specifically, it would be useful 190 to introduce and use QoS fields in NHRP queries (1) to carry the 191 traffic information (TSpec) present in the RSVP PATH message. 192 This information could then be used at each (NHRP) node as a 193 "hint" to keep forwarding the query, so as to yield the "longest" 194 possible shortcut consistent with the QoS requirements. For 195 example, a bandwidth threshold may be used to decide which flows 196 to forward over the hop-by-hop path and which to send over a 197 separate shortcut. 199 ---------------------------- 200 1. Note that such fields were present in earlier versions of the NHRP 201 draft, but were dropped because their use was not fully specified 202 at the time. 204 It should be noted that the availability of a best-effort 205 shortcut VC means that the data packets associated with the RSVP 206 flow will also be able, if permitted (more on this in Section 2), 207 to use the short and, therefore, bypass intermediate router hops 208 as well. 210 2. In order to allow the eventual establishment of a QoS shortcut 211 VC on which to forward the data packets of an RSVP flow, the 212 PATH messages must be forwarded over a shortcut VC with the same 213 endpoint. 215 3. Best-effort shortcuts should not be taken down as long as any 216 (associated) RSVP flow remains active, i.e., have a valid path 217 state. 219 This is required to ensure consistency between the forwarding of 220 RSVP control and data packets. It means that the best-effort 221 shortcut VC must stay in place as long as it is needed to forward 222 RSVP control messages. In particular, the best-effort shortcut 223 VC should not be taken down because of low traffic volume as is 224 often the case in current implementations of shortcut mechanisms, 225 e.g., NHRP. Note that a best-effort shortcut can be used to 226 forward RSVP control messages associated with multiple RSVP 227 flows, i.e., when the associated shortcut end-point is the same 228 for all the flows. As a result, the shortcut must remain in 229 place at least until all the flows have been removed. 231 4. Upon receipt of a RESV message, a new QoS shortcut VC is setup 232 with the same end-points as the existing best-effort shortcut, 233 but with the appropriate QoS characteristics based on the content 234 of the RESV message. 236 5. A QoS shortcut VC should remain active as long as the associated 237 RSVP reservation does. 239 Implicit here is the fact that "management" of a QoS shortcut 240 is closely coupled to the state of the associated RSVP flow. 241 However, responsibility for actually managing the QoS shortcut 242 VCs can lie either with RSVP or with the shortcut mechanism 243 itself. For example, in the case of NHRP which is already 244 responsible for managing best-effort shortcuts, one may want to 245 extend this to also include management of QoS VCs. On the other 246 hand, in order to easily support multiple shortcut mechanisms, 247 it might be desirable to keep management of QoS shortcuts under 248 the responsibility of RSVP, or rather of the "ATM gateway" 249 responsible for establishing VCs on behalf of RSVP. Note that in 250 this case, it is still necessary to maintain coordination between 251 the best-effort and QoS shortcut VCs as outlined above. 253 In the next two sections, we elaborate on the interactions between 254 RSVP and the shortcut mechanism, in terms of both external and 255 internal exchanges. In Section 2, we specify more precisely the 256 implications of RSVP shortcuts in terms of the associated message 257 flows between entities on each end of the shortcut. In Section 3, we 258 illustrate, for the case of NHRP, a possible interface between RSVP 259 and the shortcut mechanism. 261 2. RSVP Shortcut Interactions 263 This section covers the interactions between hosts and/or routers 264 that take place in order to enable the use of shortcuts for RSVP 265 flows. In particular, it describes how and which VCs are used by 266 RSVP control messages, e.g., PATH and RESV messages, how and when 267 shortcut VCs are established to support RSVP flows, and finally how 268 certain VC setup error scenarios are handled. 270 2.1. RSVP Control Message Handling 272 In order to properly coordinate the forwarding of RSVP data packets 273 on a shortcut VC with the associated RSVP control messages, it 274 is useful to distinguish between downstream and upstream RSVP 275 control messages. According to the RSVP specification [BZB+97], 276 downstream messages, e.g., PATH messages, flow from the sender to 277 the receiver(s), while upstream messages, e.g., RESV messages, 278 flow hop-by-hop (from next hop to previous hop) back towards the 279 sender(s). As mentioned earlier, in this draft we limit ourselves to 280 unicast flows (single ingress and egress points for the ATM network). 282 Ensuring consistent RSVP reservation states and forwarding of RSVP 283 data packets on a shortcut VC, requires proper coordination between 284 the shortcut end-points and the forwarding of RSVP control messages. 285 In particular, as mentioned in Section 1.1, it is key that downstream 286 messages, i.e., PATH messages, have previous and next hops that match 287 the end-points of the shortcut. For example, in Figure 1, when the 288 shortcut R1-R6 is used for an RSVP data flow, the associated RSVP 289 control messages sent by R1 must be sent directly to R6 without using 290 the intermediate routed path R2-R3-R4-R5. If messages passed in the 291 downstream direction are sent hop-by-hop and the data is sent via a 292 shortcut, the receiver may not be able to properly handle the data 293 and extra resources may be allocated in the intermediate routers R2, 294 R3, R4, and R5. This restriction does not apply to messages sent 295 in the upstream direction, i.e., RESV messages, that can be sent 296 on either the shortcut or the hop-by-hop paths (see [Ber97a] for 297 details). 299 Given the importance of ensuring that downstream control messages 300 are delivered directly to the same endpoint as that of the shortcut, 301 we now review the different cases that must be considered and the 302 appropriate actions for each of them. There are three different 303 scenarios that a sender (ATM ingress point) can face: 305 1. A shortcut to the (session) destination does not exist for 306 best-effort traffic, and establishment of such a best-effort 307 shortcut to this destination is administratively permitted. 309 2. A shortcut already exits for best-effort traffic to the (session) 310 destination. 312 3. A shortcut to the (session) destination does not exits for 313 best-effort traffic, and establishment of such a best-effort 314 shortcut to this destination is administratively prohibited. 316 Note that we assume that administrative control of shortcuts is part 317 of the shortcut support mechanisms, such as NHRP, and is outside the 318 scope of this document. Furthermore, it is assumed that RSVP can be 319 notified when a best-effort shortcut is administratively prohibited. 321 The first case occurs when no shortcut exists and the sender is 322 administratively permitted to create a shortcut VC for use by 323 best-effort data traffic to the same destination address as the RSVP 324 control message. In this case, there are two possible approaches 325 that the sender can follow. A first approach is to setup the 326 "best-effort" VC at the time the first control message (PATH) 327 arrives, and wait until the best-effort shortcut is established 328 before forwarding the message downstream. The second approach 329 is to immediately forward the control message (PATH) via the 330 hop-by-hop path, and to proceed in parallel with the establishment 331 of the best-effort shortcut. Once the "best-effort" shortcut is 332 established, forwarding of control messages can then be switched 333 over to the shortcut. Downstream RSVP processes will detect the 334 path change and update their internal state appropriately. This 335 latter approach has the disadvantage that additional resources may 336 be allocated along the hop-by-hop path prior to the shortcut being 337 established. In either case, the newly established shortcut VC must 338 be maintained for as long as there remains RSVP control traffic to be 339 forwarded downstream, i.e., the VC should not be timed out or taken 340 down for lack of activity as long as the RSVP PATH state remains in 341 effect. 343 The second case occurs when a shortcut already exists for use by 344 best-effort data traffic to the same destination address as an RSVP 345 control message, i.e., the entry in the forwarding information base 346 of the router, that corresponds to the destination address of the 347 RSVP message, indicates that it is a shortcut. In this case, the 348 first step that needs to be performed is to "revalidate" the existing 349 shortcut. As stated earlier, this revalidation is necessary as in 350 some instances the shortcut mechanism may select different end-points 351 for a shortcut depending on the nature of the traffic that is to 352 use the shortcut. Revalidation of the shortcut also depends on 353 the type of shortcut mechanism used. In case the shortcut is not 354 validated, the sender finds itself in a similar situation as that of 355 the previous case. Assuming the shortcut has been validated, the 356 sender can then simply forward downstream RSVP control messages on 357 the existing shortcut VC. However, as before, the sender must also 358 make sure that the existing best-effort shortcut is not released 359 while still being needed to forward RSVP control messages. 361 The third and last case occurs when no shortcut exists, and the 362 sender is administratively prohibited from creating a best-effort 363 shortcut VC to the same destination address as the RSVP control 364 messages. However, QoS shortcut VCs are allowed and could be used 365 by RSVP flows. For example, this could be the case when crossing 366 administrative domain boundaries. In order to enable the use of QoS 367 shortcuts by RSVP flows in such instances, it is necessary to create 368 a special VC to the shortcut endpoint for use solely by RSVP control 369 messages that are to be sent downstream. As in the first case, the 370 sender can forward the first PATH message downstream either before 371 or after the VC has been successfully established. Similarly, the 372 control shortcut VC must again be maintained for as long as there are 373 RSVP control messages to be passed downstream. 375 2.2. Data VC Operations 377 Shortcut data VCs are setup and maintained in essentially the same 378 fashion as described in [Ber97a, Ber97b]. The only but significant 379 difference is that the ATM called party used in VC setup matches 380 the shortcut endpoint. As in the case of hop-by-hop operation, the 381 setup of a QoS data VC is triggered by the receipt of the first RESV 382 message. The fact that a shortcut will be used can be detected by 383 realizing that the next hop, as per the IP source address in the RESV 384 message, is on a different subnet, and by the fact that a "control 385 shortcut VC" already exists to this next hop. When the RESV message 386 is received by RSVP, a QoS VC to the shortcut endpoint is then 387 initiated. 389 In establishing the QoS shortcut VC, the RSVP process should follow 390 the same recommendations as stated in [Ber97a], specifically using 391 independent VCs for each RSVP reservation. The RSVP process should 392 also follow the same recommendations and requirements as stated 393 in [Ber97b]. This includes the ability to handle changes in QoS 394 requests and negotiate appropriate encapsulation. 396 2.3. Error Handling Scenarios 398 There are a number of error scenarios that need to be handled by RSVP 399 when using shortcuts. 401 The first error scenario is when the shortcut VC used to forward RSVP 402 control messages is abnormally released and cannot be reestablished. 403 In this case there is no other choice but to send RSVP control 404 messages hop-by-hop. When this occurs and no RSVP associated QoS 405 VCs exists, no other special actions is required. However, when 406 this occurs AND there are RSVP associated QoS VCs (there could be 407 more than one), then those VCs MUST be released. The release of 408 the associated data VCs is required to maintain the synchronization 409 between forwarding and reservation states for the associated data 410 flows. 412 A second error scenario occurs when the setup of the QoS data VC 413 associated with an RSVP flow fails. In this case, a shortcut with 414 the required QoS is not available, but a best-effort VC has been 415 successfully established to forward the RSVP control messages. Since 416 the desired QoS cannot be satisfied using a shortcut, the sender 417 SHOULD stop sending the RSVP control messages over the best-effort 418 shortcut and start sending them on the hop-by-hop path. This will 419 eventually allow the reservation to be attempted on the hop-by-hop 420 path. The best-effort shortcut VC used for control messages may 421 be released or maintained based on its other uses. For example, 422 it may still be used to forward RSVP control messages associated 423 with other flows which did successfully setup a QoS shortcut to the 424 same endpoint. Note that the sender may want to regularly retry 425 establishing a shortcut based path, especially if the reservation is 426 also unsuccessful on the hop-by-hop path. 428 The last error scenario to consider is that of a VC setup failure 429 when processing a change in an RSVP reservation. This case is 430 handled exactly the same way as is described in [Ber97b, Section 431 2.4]. The old QoS VC MUST continue to be used. When the new 432 reservation is greater than the old reservation, the reservation 433 request MUST be answered with an error. When the new reservation is 434 less than the old reservation, the request MUST be treated as if the 435 modification was successful. Implementations SHOULD retry replacing 436 the too large VC after some appropriate elapsed time. 438 In the next section, we provide an example of a possible interface 439 between RSVP and the shortcut mechanisms, when NHRP is assumed for 440 the latter. This interface is only intended as a possible guideline 441 and not meant to imply specific implementations requirements. 443 3. Sample RSVP-NHRP Interface 445 An interface between RSVP and NHRP should allow determination of 446 appropriate shortcut endpoints for different RSVP flows, support 447 coordination between best-effort and QoS VCs used for the same flow, 448 and accommodate handling of error scenarios. In the context of the 449 interface outlined in this section, we assume that RSVP (the RSVP-ATM 450 gateway) is responsible for the establishment of QoS shortcut VCs. 451 As a result, interactions between NHRP and RSVP are limited to 452 dealing with best-effort VCs. 454 - RSVP_shortcut_resolve(flow_ID, IP_address, TSpec, return_code, 455 BE_VC_handle, endpoint_ATM_address) 457 This is a query from RSVP to NHRP to request the most appropriate 458 shortcut possible towards reaching IP_address. Note that if a 459 shortcut already exists to the destination, NHRP may need to 460 revalidate it based on the new TSpec specified in the call. 462 * flow_ID: identifies the flow for future reference. 464 * IP_address: unicast IP address of the destination specified 465 in the PATH message. 467 * TSpec the traffic specification for the RSVP flow. This 468 information may be carried in the QoS field of the NHRP 469 request. 471 * return_code: because resolution of the query and 472 establishment of a new VC, if necessary, will take 473 time, the return_code can take three different values: 474 success/pending/failed. 476 * BE_VC_handle: this value is only meaningful when return_code 477 = success, and identifies to RSVP the best-effort VC 478 associated with the flow. Implicit here is the fact that 479 both RSVP and NHRP are now aware that the states of the VC 480 associated with BE_VC_handle and of the RSVP flow identified 481 by flow_id need to be coordinated. Note that a best effort 482 VC could be associated with multiple flows, and NHRP could 483 return the same or different handles for each flow. 485 * endpoint_ATM_address: ATM address of the endpoint to which 486 the best-effort VC was established. RSVP will use this 487 address to subsequently request the setup of a QoS VC upon 488 receipt of an associated RESV message. 490 - NHRP_shortcut_resolve(flow_ID, return_code, BE_VC_handle, 491 endpoint_ATM_address) 493 This is an asynchronous response to an earlier query by RSVP, 494 i.e., one for which return_code = pending. 496 * flow_ID: used by RSVP to correlate the response with the 497 original query. 499 * return_code: is either success or failed. 501 * BE_VC_handle: in case return_code = success, identifies to 502 RSVP the best-effort VC associated with the flow. Again, 503 implicit here is the fact that both RSVP and NHRP are now 504 aware that the states of the VC associated with BE_VC_handle 505 and of the RSVP flow identified by flow_id need to be 506 coordinated. Note that a best effort VC could be associated 507 with multiple flows, and NHRP could return the same or 508 different handles for each flow. 510 * endpoint_ATM_address: ATM address of the endpoint to which 511 the best-effort VC was established. RSVP will use this 512 address to subsequently request the setup of a QoS VC upon 513 receipt of an associated RESV message. 515 - RSVP_shortcut_refresh (flow_id, BE_VC_handle, return_code) 517 Used by RSVP to notify NHRP that an existing best-effort shortcut 518 VC, previously established for a given RSVP flow, should be 519 maintained independent of the volume of traffic it carries. 520 Note that this function need not be supported through such an 521 interface, and could be provided through local status bits that 522 NHRP could query. 524 * flow_id: initially assigned by RSVP to identify the flow. 526 * BE_VC_handle: handle provided by NHRP after establishing the 527 best-effort VC. 529 * return_code: can be success or an error code (tbd) in case 530 RSVP is trying to refresh a non-existing VC. 532 - RSVP_shortcut_take_down (flow_id, BE_VC_handle) 533 Used by RSVP to notify NHRP that an existing best-effort shortcut 534 VC, associated with a given flow, can be taken down. This need 535 not trigger the actual take down of the VC in cases where the 536 same best-effort VC is used to carry control messages of multiple 537 RSVP flows, or if NHRP decides to keep the VC up to continue 538 carrying best-effort data traffic. However, in the latter case, 539 NHRP is responsible for removing any association between RSVP 540 flows and the best-effort VC. 542 * flow_id: initially assigned by RSVP to identify the flow. 544 * BE_VC_handle: handle provided by NHRP after establishing the 545 best-effort VC. 547 - NHRP_BE_VC_failure(BE_VC_handle, error_code) 549 Used by NHRP to notify RSVP of the failure of an existing 550 best-effort VC. RSVP is responsible for taking down all 551 associated QoS VCs. 553 * BE_VC_handle: handle originally used by NHRP to identify the 554 best-effort VC. 556 * return_code: indicates the type of failure if known. 558 4. Interaction with MPOA 560 In the ATM Forum's Multiprotocol Over ATM (MPOA) model, shortcuts are 561 established between MPOA Clients (MPCs) on edge devices, or between 562 an MPC and an NHRP Client (NHC). When an internetwork layer packet 563 (e.g., IP packet) arrives over a shortcut VC to an MPOA edge device, 564 the MPC looks up the internetwork layer destination address in the 565 packet in a local cache to obtain DLL information to place on the 566 packet. The DLL information is prepended to the packet and the frame 567 is transferred to a LAN Emulation client for further handling. When 568 using the scheme described in this draft for establishing shortcuts 569 with QoS, it is possible that multiple shortcuts may be established 570 to the same MPC with traffic from different RSVP flows to the same 571 IP destination. Furthermore, it may be desirable to place different 572 DLL headers for packets arriving over different VCs (e.g., with 573 different values of priority in the token ring header, or in the IEEE 574 802.1p header), depending on the QoS required for the flow. The MPOA 575 specification already allows for this possibility. The egress MPC 576 simply needs to assign a different "tag" for each RSVP flow that it 577 is terminating. This tag is carried in the packets arriving over 578 the shortcuts to the edge device, and may be used to index in to 579 different entries in the local cache. Thus, the scheme described in 580 this draft is compatible with MPOA as well. 582 It is for further study whether full PATH state needs to be stored on 583 the edge devices or not. The MPOA Server (MPS) may be able to store 584 the PATH state, thus allowing for building of simpler edge devices. 586 5. Example of RSVP Shortcut 588 In this last section, we briefly outline a possible set of events 589 involved in the establishment of a shortcut for an RSVP flow. 590 Referring to Figure 1, we assume a sending host H1 connected through 591 a series of networks and routers to router R1 (ingress router to 592 the ATM network), and a destination host H2 connected to router R6 593 (egress router from the ATM network) through again possibly a series 594 of routers and networks. 596 - Host H1 starts sending PATH messages. 598 - First PATH message arrives at R1 which extracts the IP address 599 of H2 and the TSpec of the flow and queries its local NHRP using 600 RSVP_shortcut_resolve(). 602 - NHRP generates an NHRP query for the IP address of host H2 and 603 specifies using the NHRP QoS field, that the query should be 604 resolved in the most specific and feasible manner, i.e., the ATM 605 address of router R6 should be returned. NHRP responds to the 606 RSVP query with a return_code = pending. 608 - NHRP receives a response to its query. It could either 609 correspond to an existing VC to R6 or require the establishment 610 of a new VC. If the latter, NHRP proceeds with setting-up a new 611 best-effort VC. 613 - NHRP informs, using NHRP_shortcut_resolve(), that the best effort 614 VC to R6 has been established (or not established) by returning 615 the appropriate return_code. In what follows, we assume the 616 best effort VC has been successfully established, so that 617 NHRP also returns the ATM address of R6 to RSVP and the handle 618 corresponding to the VC. 620 - RSVP starts forwarding PATH messages on the newly establish 621 shortcut VC to R6. Here we assume that R1 held back forwarding 622 of PATH messages until after the establishment of the best-effort 623 shortcut VC. Note that data packets for H2 will also be forwarded 624 on the shortcut VC. 626 - PATH message arrives at R6 with its PHOP set to R1. R6 creates 627 the appropriate path state and proceeds to forward the PATH 628 message towards H2. 630 - H2 receives the PATH message. It decides to make a reservation 631 and starts sending RESV messages. 633 - First RESV message arrives at R6 which (assuming the local 634 reservation is successful), which forwards it to R1 since it has 635 the IP address of R1 in its PHOP field. 637 - RESV message is received by RSVP at R1, which then requests the 638 establishment of a QoS VC to R6 using the ATM address returned by 639 NHRP in NHRP_shortcut_resolve(). The request specifies a service 640 class and traffic parameters based on the information contained 641 in the RESV message. 643 - Once notified of the success of the setup of the VC, RSVP 644 proceeds to update the classifier at R1 to ensure that RSVP data 645 packets are forwarded on the new VC. R1 also forwards the RESV 646 message towards H1. 648 - As long as the associated RESV state remains alive, RSVP at R1 649 keeps the QoS VC to R6 up and also makes sure that the associated 650 best-effort VC remains up. 652 - When the reservation is eventually taken down, say, by H2 issuing 653 a RESV_TEAR, RSVP at R1 takes down the QoS VC to R6 and removes 654 the associated classifier entry. Data packets start then being 655 forwarded on the best effort shortcut VC to R6. 657 - As long as the PATH state remains alive, RSVP at R1 keeps 658 refreshing the associated best-effort shortcut VC to R6 using 659 RSVP_shortcut_refresh(). 661 - When the PATH state is removed, e.g., by receiving a 662 PATH_TEAR initiated by H1, RSVP at R1 notifies NHRP using 663 RSVP_shortcut_take_down() with the flow_id and VC_handle 664 corresponding to the best effort shortcut VC associated with the 665 flow. NHRP can then decide to either take the VC down or to keep 666 it up. 668 Acknowledgment 670 The authors gratefully acknowledge inputs from Steve Nadas, Anoop 671 Ghanwani, Steven Blake, Girish Bhat, and Ed Bowen. 673 References 675 [BB97] S. Berson and L. Berger. IP Integrated Services with 676 RSVP over ATM (draft-ietf-issll-atm-support-03.txt). 677 INTERNET-DRAFT, Internet Engineering Task Force, ISSLL 678 Working Group, March 1997. 680 [Ber97a] L. Berger. RSVP over ATM Implementation Guidelines 681 (draft-ietf-issll-atm-imp-guide-01.ps,txt). 682 INTERNET-DRAFT, Internet Engineering Task Force, 683 ISSLL Working Group, July 1997. 685 [Ber97b] L. Berger. RSVP over ATM Implementation Requirements 686 (draft-ietf-issll-atm-imp-req-00.ps,txt). INTERNET-DRAFT, 687 Internet Engineering Task Force, ISSLL Working Group, July 688 1997. 690 [GB97] M. Garrett and M. Borden. Interoperation of 691 Controlled Load and Guaranteed Service with ATM 692 (draft-ietf-issll-atm-mapping-02.txt). INTERNET-DRAFT, 693 Internet Engineering Task Force, ISSLL Working Group, March 694 1997. 696 [J96] J. Jeffords (ed.). PNNI Augmented Routing (PAR) v1.0 697 Specification. ATM Forum BTD-PNNI-PAR-01.00, December 698 1996. 700 [LKPC97] J. V. Luciani, D. Katz, D. Piscitello, and 701 B. Cole. NBMA Next Hop Resolution Protocol NHRP 702 (draft-ietf-rolc-nhrp-11.txt). INTERNET-DRAFT, Internet 703 Engineering Task Force, ROLC Working Group, March 1997. 705 [BZB+97] R. Braden (Ed.), L. Zhang, S. Berson, S. Herzog, and 706 S. Jamin. Resource reSerVation Protocol (RSVP) version 707 1, functional specification (draft-ietf-rsvp-spec-16.ps). 708 INTERNET-DRAFT, Internet Engineering Task Force - RSVP WG, 709 June 1997. 711 Authors' Address 713 Roch Guerin Dilip Kandlur 714 IBM T.J. Watson Research Center IBM T.J. Watson Research Center 715 P.O. Box 704 P.O. Box 704 716 Yorktown Heights, NY 10598 Yorktown Heights, NY 10598 718 EMAIL: guerin@watson.ibm.com EMAIL: kandlur@watson.ibm.com 719 VOICE +1 914 784-7038 VOICE +1 914 784-7722 720 FAX +1 914 784-6205 FAX +1 914 784-6205 722 Liang Li Vijay Srinivasan 723 IBM Corporation IBM Corporation 724 P. O. Box 12195 P. O. Box 12195 725 Research Triangle Park, NC 27709 Research Triangle Park, NC 27709 727 EMAIL: lli@raleigh.ibm.com EMAIL: vijay@raleigh.ibm.com 728 VOICE: +1 919 254-5627 VOICE: +1 919 254-2730 729 FAX: +1 919 254-5483 FAX: +1 919 254-5410 731 Lou Berger 732 FORE Systems 733 6905 Rockledge Drive 734 Suite 800 735 Bethesda, MD 20817 737 EMAIL: lberger@fore.com 738 VOICE: +1 301 571 2534