idnits 2.17.1 draft-berger-rsvp-over-atm-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-19) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (June 11, 1996) is 10174 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) -- Looks like a reference, but probably isn't: 'Image' on line 382 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1577 (ref. '6') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1483 (ref. '9') (Obsoleted by RFC 2684) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. Berger 2 Expiration: December 11, 1996 FORE Systems 3 File: draft-berger-rsvp-over-atm-00.txt 5 RSVP Over ATM: 6 Framework and UNI 3.0/3.1 Method 8 June 11, 1996 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 months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This note presents a method for running RSVP over ATM switched 31 virtual circuits (SVCs). It presents an overall approach to the 32 problem, as well as a specific method for running over today's ATM 33 networks. The note includes a review of major related issues, an 34 overview of the proposed approach, and a specific method usable with 35 UNI 3.0 and 3.1. This note is intended to be used as a basis for 36 discussion in the IETF ISSLL working group. 38 Author's Note 40 This note is an initial (rough) draft and is expected to be changed 41 and extended based on discussions in the ISSLL working group. All 42 comments and contributions are welcomed. 44 The postscript version of this document contains figures that are not 45 included in the text version, so it is best to use the postscript 46 version. Figures will be converted to ASCII in the next version. 48 1. Introduction 50 This note discusses running IP over ATM in an environment where SVCs 51 are used to support QoS flows and RSVP is used as the internet level 52 QoS signaling protocol. It begins with a general discussion on issues 53 that are key to running RSVP over ATM. Some of these issues have been 54 discussed in related material, others have not been widely discussed. 55 All of the discussed issues must be addressed by any RSVP over ATM 56 solution. 58 In Section 4, this note presents a specific RSVP over ATM solution. 59 It specifies a method for running RSVP over ATM UNI 3.x (3.0 and 60 3.1). This note covers key aspects to running RSVP over UNI 3.x and 61 includes an explicit set of processing rules and required RSVP 62 related changes. (Changes are in the message processing and RSVP 63 interface areas.) The defined method conforms to a framework that 64 permits interoperability between simple, or baseline, implementations 65 and more sophisticate, full-featured, implementations. The framework 66 is described in Section 3 of this note. 68 The described framework is a general approach to running RSVP over 69 ATM. The framework is intended to provide a structure to multiple 70 specific RSVP over ATM specifications. Each specification will match 71 technology or standardization evolution, e.g UNI 3.x and 4.x. The 72 framework is also intended to allow interoperability between 73 implementations that use different approaches in mapping RSVP to ATM. 74 This allows for evolution without requiring uniform deployment. It 75 also permits the specification of basic functionality, while allowing 76 for more sophisticated options. 78 2. Issues 80 The general issues related to running RSVP [1] over ATM have been 81 covered in numerous papers including [2], [3], and [4]. This section 82 will review, and introduce two new key issues that must be addressed 83 by any RSVP over ATM solution. The issues that will be covered are: 85 * VC Usage 86 * Heterogeneity 87 * Routing 88 * QoS Renegotiation 89 * Encapsulation 90 * Best-Effort Receivers 92 Additionally, there are several longer-term issues related to 93 emerging technologies and scaling that will be important to future 94 RSVP over ATM solutions. Lastly, the mapping of INT-SERV QoS classes 95 and parameters is considered to be outside the scope of issues 96 related to running RSVP, the protocol, over ATM and is therefore not 97 addressed in this section or this note. It is expected that this last 98 area will be covered in other drafts. 100 2.1 Issue: VC Usage 102 There is a basic need to map from IP and RSVP to ATM virtual circuits 103 (VCs). In the permanent virtual circuit (PVC) environment, this is 104 really a non-issue since PVCs are typically used as point-to-point 105 link replacements. LAN Emulation [5], Classical IP [6] and, more 106 recently, NHRP [7] discuss mapping IP traffic onto ATM SVCs, but they 107 only cover a single QoS class, i.e., best effort traffic. When QoS is 108 introduced, VC mapping must be revisited. For RSVP controlled QoS 109 flows, there are two main issues: VCs to be used for RSVP (control) 110 traffic, and VCs to use for QoS data flows. 112 RSVP control traffic is used to install state and request allocation 113 of resources, it is not used to deliver any user data. As a control 114 protocol, it is important for RSVP traffic to be delivered with some 115 assurance of reliability. To that end, RSVP includes a soft-state, 116 retry mechanism. This mechanism allows state to be maintained even 117 when some RSVP messages are not delivered. When running RSVP over ATM 118 it is critical for RSVP traffic to receive adequate service so that 119 QoS state is installed and maintained. 121 The second VC usage issue is data flow to VCs mapping. In the Classic 122 IP over ATM and current NHRP models a single VC is used for all 123 traffic between two ATM attached hosts (routers and end-stations). It 124 is likely that such a single VC will not be adequate or optimal when 125 supporting data flows with multiple QoS types. RSVP's basic purpose 126 is to install support for flows with multiple QoS types, so it is 127 essential for any RSVP over ATM solution to address VC usage for QoS 128 data flows. RSVP reservation styles will also need to be taken into 129 account in any VC usage strategy. 131 There is also the lesser VC usage issue of reuse of VC reverse paths. 132 ATM point-to-point VCs allow for bi-directional data flow. The 133 reverse path could be used for best effort or QoS traffic. Bi- 134 directional VCs could even be used to provide true receiver initiated 135 reservations (reverse path of VC would be forward path for IP data.) 136 Use of VC reverse paths will need to be addressed as part of a VC 137 usage strategy. 139 2.2 Issue: Heterogeneity 141 There are several types of related heterogeneity. One type is that 142 multiple receivers may request different Rspecs within a single 143 session. This means that the amount of requested resources may differ 144 on a per next hop basis, see figure 1. Optimally, only the resources 145 requested will be allocated. This is not possible with current ATM 146 UNI since both UNI 3.x and UNI 4.0 require the same QoS allocations 147 on all leafs of a point-to-mulitpoint VC. It is possible that a 148 future version of UNI will support multiple QoS parameters within a 149 single VC, but this is not yet the case. A RSVP over ATM solution 150 will need to support heterogeneous receivers within a single service 151 class even though ATM does not currently provide such support 152 directly. 154 [Image] 156 Figure 1: Heterogeneous RSVP Receivers 158 There is also the possibility that there will be RSVP requests for 159 different service classes within a single RSVP session. This case is 160 not permitted in RSVP version one, so this issue does not need to be 161 addressed by RSVP over ATM solutions. Similarly, there is the 162 possibility that there will be requests for multiple reservation 163 styles within a single session. This case is also not allowed by RSVP 164 version one. While RSVP based requests for multiple service classes 165 are not allowed, there remains a requirement to be able to support a 166 single RSVP requested QoS class along with non-QoS traffic. This 167 means that any RSVP over ATM solution must always support the 168 default, best-effort, service class along with a requested QoS 169 service class. 171 2.3 Issue: Routing 173 This section will discuss two routing related issues. The first 174 routing related issue is dealing with ATM short-cuts. As shown in 175 figure 2, short-cuts [7] allow ATM attached routers and hosts to 176 directly establish VCs across LIS boundaries, i.e., the VC end-points 177 are on different IP sub-nets. This model of VC establishment poses 178 several issues when running with RSVP. The key issues are dealing 179 with established best-effort short-cuts, when to establish short- 180 cuts, and QoS only short-cuts. These issues will need to be addressed 181 by all RSVP implementations, furthermore it may be desirable to 182 permit different interoperable strategies for dealing with short- 183 cuts. 185 [Image] 187 Figure 2: ATM Short-Cuts 189 The second routing related issue is dealing with multicast servers. 190 Two models are planned for IP multicast data distribution over ATM, 191 see [8]. In one model data, senders establish point-to-multipoint VCs 192 to all ATM attached destinations, and data is then sent over these 193 VCs. This model is often called "multicast mesh" mode distribution. 194 In the second model, senders send data over point-to-point VCs to a 195 central point and the central point relays the data onto point-to- 196 mulitpoint VCs that have been established to all receivers of the IP 197 multicast group. This model is often refereed to as "multicast 198 server" mode distribution. Figure 3 shows data flow for both modes of 199 IP multicast data distribution. Both modes of data distribution will 200 need to be addressed for a complete RSVP over ATM solution. 202 [Image] 204 Figure 3: IP Multicast Data Distribution Over ATM 206 2.4 Issue: QoS Renegotiation 208 QoS renegotiation when using ATM UNI 3.x and UNI 4.0 is problematic. 209 The basic issue is that RSVP allows for changes in a flow's QoS 210 parameters and QoS is fixed at VC setup time for both ATM UNI 3.x and 211 UNI 4.0. There are several options for dealing with this mismatch in 212 service. A specific approach will need to be specified by any RSVP 213 over ATM solution. 215 2.5 Issue: Encapsulation 217 One issue that has not been generally discussed is encapsulation. 218 There are two encapsulation options for running IP over ATM, and it 219 may even be desirable to support RSVP over both options. The first 220 option is described in RFC 1483 [9] and is the option that has been 221 generally assumed to be the one that will be used with RSVP. 223 The second option is LAN Emulation, as described in [5]. While RSVP 224 over LANE has not been generally discussed, LANE is commonly used in 225 the ATM LAN environment. It is likely that initial RSVP over ATM 226 solutions will only support RFC 1483 encapsulation. While this is the 227 case, it may be desirable to also define RSVP over ATM over LANE. 228 LANE encapsulation has the added issue that LANE does not include a 229 QoS signaling interface. If LANE encapsulation is needed, LANE QoS 230 signaling would first need to be defined. 232 2.6 Issue: Best-Effort Receivers 234 [Image] 236 Figure 4: Types of Multicast Receivers 238 Another issue that has not been generally discussed is dealing with 239 best-effort receivers. In any IP multicast group, it is possible that 240 some receivers will request QoS (via RSVP) and some receivers will 241 not, see figure 4. In shared media, like Ethernet, receivers that 242 have not requested resources can be given a free ride without almost 243 any effort or complications. This is not the case with ATM. In ATM 244 networks, the end-points of each VC must be explicitly added. There 245 may be costs associated with adding the best-effort receiver, and 246 there might not be adequate resources to add the non-QoS receiver. 247 While this issue is not strictly an RSVP issue, it is an issue that 248 must be addressed by any RSVP over ATM solution. 250 2.7 Future Issues 252 There are several issues that will become increasingly important to 253 solve as time passes. These issues are not likely to be critical for 254 initial RSVP over ATM solutions. The first issue is dealing with QoS 255 based routing protocols. Standard versions of QoS routing protocols 256 do not yet exist, but there have been private versions as well as 257 discussions related to standardization efforts. So, in the not too 258 distant future it will be likely that RSVP over ATM solutions will 259 need to operate in an enhanced routing environment. There may or may 260 not be additional issues related to running in such an environment. 261 Identification of specific issues will need to wait until such 262 protocols are brought into the IETF. 264 Another issue will be running RSVP over ATM UNI 4.0. Initial RSVP 265 over ATM solutions are likely to be aimed at UNI 3.x. This will be 266 sufficient for today's ATM networks, but support of UNI 4.0 will also 267 be needed. The key change that may impact an RSVP over ATM solution 268 is the introduction of multipoint-to-multipoint VCs. UNI 4.0 will 269 also allow different service class mappings, but this is more of an 270 INT-SERV issue. 272 The last issue that will need to be solved is scaling. There are two 273 dimensions of scaling. The first dimension is number of receivers in 274 a single session. Scaling number of receivers may trigger RSVP 275 message implosion as well as ATM signaling limitations (e.g., limits 276 on rate of add parties). The second dimension of scaling is number of 277 sessions. The key ATM related implication of large number of sessions 278 is the number of VCs and associated (buffer and queue) memory. The 279 numbers of flows and sessions supported by an RSVP over ATM solutions 280 is likely to change over time, so a solution that is adequate for 281 initial RSVP over ATM may not be adequate in the longer term. It will 282 be increasingly important to address both of these dimensions of 283 scaling as use of deployment and use of RSVP over ATM increases. 285 2.8 Non-Issue: Receiver Vs Sender Initiation 286 There is an apparent mismatch between RSVP and ATM. Specifically, 287 RSVP control is receiver oriented and ATM control is sender oriented. 288 (This is critical in ATM point-to-multipoint VCs, less so for bi- 289 directional point-to-point VCs.) This initially may seem like a major 290 issue, but slightly deeper analyses shows this to be a non-issue. 291 While RSVP reservation (RESV) requests are generated at the receiver, 292 actual allocation of resources takes place at the sub-net sender. 293 This is true for all sub-net technologies. As is shown in figure 5, 294 VCs are always initiated by the ATM "sender". Note that the ATM 295 sender may be a router or an end-station. 297 [Image] 299 Figure 5: RSVP Resource Allocation 301 3. Solution Overview 303 This section describes a framework that allows for evolution of RSVP 304 over ATM solutions as well as variability in implementation. The 305 framework supports multiple specific solutions that may be used to 306 integrate with evolving IETF and ATM forum standards. It also 307 minimizes interoperability interdependencies and allows for 308 interoperability between somewhat different approaches to running 309 RSVP over ATM. This framework addresses VC usage and routing 310 interactions 312 The rest of this section describes the framework and also covers 313 possible issues that need to be addressed in the short, medium, and 314 long terms. Section 4 provides a framework compliant method for 315 running RSVP over ATM UNI3.x. 317 3.1 Framework 319 3.1.1 VC Usage 321 The most significant aspect of the solution framework is VC usage by 322 RSVP and associated (QoS) data flows. Figure 6 represents the 323 proposed model for data flow VC initiation. For data flows, sub-net 324 senders establish all QoS VCs and that the sub-net receiver always 325 accept incoming VCs. This means that receivers will never initiate 326 reservations via the reverse path mechanism provided by point-to- 327 point VCs. This model is consistent with RSVP version one processing 328 rules and allows senders to use different flow to VC mappings and 329 even QoS renegotiation techniques without necessitating any change in 330 receivers. Additionally, receivers are restricted from using the 331 reverse path provided by point-to-point VCs, since this is a special 332 case that cannot be used to support multicast flows. 334 [Image] 336 Figure 6: Data Flow VC Initiation 338 Figure 7 shows the proposed model for VC usage by RSVP control. RSVP 339 control (messages) will always be sent over the best effort data 340 path. This approach is the most efficient and satisfies RSVP 341 reliability requirements. This approach minimizes VC requirements 342 since the best effort data path will need to exist in order for RSVP 343 sessions to be established and in order for RSVP reservations to be 344 initiated. Best effort paths will also be used for data distribution 345 while RSVP reservations are not in place. The reliability of the best 346 effort data path will also be adequate since RSVP allows for a 347 certain amount of packet loss without any loss of state 348 synchronization. 350 [Image] 352 Figure 7: RSVP Control Message VC Usage 354 3.1.2 Routing 356 The second critical aspect of the solution framework is dealing with 357 IP routing issues. The proposed solution is for both RSVP control and 358 QoS data flows to just follow IP routing. This means that there is no 359 route pinning (per [1].) It also means that short-cut paths are 360 supported. Initial RSVP over ATM solutions may only follow existing 361 short-cuts, but the framework supports QoS triggered short-cuts or 362 even per flow short-cuts. 364 The handling of short cuts has been raised as an issue. The area of 365 concern is that a down-stream short-cut may not have a matching up- 366 stream short-cut, and that this would result in PATH and RESV 367 messages following different paths. This asymmetric RSVP control 368 scenario is shown in figure 8. More detailed examination shows this 369 to be a non-issue. RSVP includes mechanisms to detect and handle RESV 370 messages arriving at the wrong router and the wrong interface. For 371 messages arriving at the wrong router, [1] states: "... IP 372 destination address does not match any of the interfaces of the local 373 interfaces, then forward the message to IP destination address ..." 374 For RESV messages arriving at the wrong interface, [1] states: "The 375 logical outgoing interface OI is taken from the LIH in the NHOP 376 object .... [or] it can be learned from the interface matching the IP 377 destination address." Since incoming interface is not used in RESV 378 processing there is no issue. So, both cases are covered by RSVP 379 processing rules and there is no RSVP issue with supporting ATM 380 short-cuts. 382 [Image] 384 Figure 8: Asymmetric RSVP Message Forwarding With ATM Short-Cuts 386 3.2 Non-RSVP Protocol Issues 388 As IETF and ATM Forum protocols evolve it will be necessary to update 389 specific approaches taken to support RSVP over ATM. The framework 390 described above permits an interoperable evolution of RSVP over ATM 391 specifications and implementations. This section presents a view of 392 how some protocol aspects will change and how those changes may 393 impact RSVP over ATM solutions. The relevant IP over ATM and ATM 394 protocol aspects that are highlighted are encapsulation, multicast, 395 QoS renegotiation, heterogeneous flows/VCs, and short-cuts. Protocol 396 evolution is broken down into short-term (now), medium-term, and 397 long-term. The short term is focused on current and soon to be issued 398 standards and will be the basis for the RSVP over ATM solution 399 specified in section 4. The medium term is focused on emerging 400 standards such as UNI4.x. The long term is focused on new QoS related 401 requirements for standards. 403 Issue Short-Term Medium-Term 405 Encapsulation RFC 1483 407 Multicast 408 Signaling UNI 3.x UNI 4.0 409 Data Mesh 410 Distribution 412 QoS 413 Renegotiation 415 Heterogeneous 416 VCs 418 Short-cut VCs NHRP QoS NHRP 420 Table 1: Possible Related Protocol Developments 422 Table 1 presents today's RSVP over ATM relevant protocols and some 423 related future protocol developments. For the foreseeable future 424 encapsulation will be based on RFC 1483. This is really the only 425 option since LANE does not support any QoS signaling or control. For 426 multicast, there are two relevant issues: signaling and distribution 427 mode. Today's ATM networks support UNI 3.0 and 3.1 signaling, UNI 4.0 428 signaling will soon be complete and it's support will be required. 429 For multicast data distribution, only point-to-multipoint VCs can be 430 used to allocate resources for RSVP controlled QoS flows until the 431 time when MARS is extended to provide some form of QoS control for 432 multicast servers (MCS). Neither QoS renegotiation nor heterogeneous 433 point-to-multipoint VCs are supported by either UNI 3.x or 4.0. 434 Lastly, for short-cuts, until use of the NHRP QoS options is 435 specified it is likely that all short-cuts will be done solely on a 436 per destination basis. 438 3.2.1 Long-Term Issues 440 The long-term will be driven by future non-RSVP protocol 441 developments. These developments are likely to be somewhat driven by 442 internet QoS signaling (i.e., RSVP) over ATM requirements. This 443 section discusses areas in today's IP over ATM and ATM Forum 444 protocols that if extended would benefit RSVP over ATM. Issues 445 related to NHRP, MARS, UNI, and LANE are covered. The discussion only 446 covers the (RSVP) protocol related issues. INT-SERV related issues 447 are outside the scope of this document. 449 3.2.1.1 NHRP 451 The Next-Hop Resolution Protocol, or NHRP, is being developed to 452 support short-cut VC establishment. When using RSVP it may be 453 desirable to establish multiple short-cut VCs, to use these VCs for 454 specific QoS flows, and to use the hop-by-hop path for other QoS and 455 non-QoS flows. The current NHRP specification [7] does not preclude 456 such an approach, but nor does it explicitly support it. We believe 457 that explicit support of flow based short-cuts would improve RSVP 458 over ATM solutions. We also believe that such support may require the 459 ability to include flow information in the NHRP request, but this is 460 an area for further study. 462 3.2.1.2 MARS 464 In the MARS model, data distribution may be handled either by point- 465 to-multipoint VCs or via a multicast server (MCS). When using RSVP, 466 it is desirable to establish VCs with specific QoS. Establishing such 467 VCs is readily done when using point-to-multipoint VCs, but is more 468 complicated when using multicast servers. When using a multicast 469 server, the sub-network sender could establish a point-to-point VC 470 with a specific QoS to the server, but there is not current mechanism 471 for the MCS to establish anything other than an UBR VC. In order to 472 support RSVP over a MARS-MCS it will be necessary to provide QoS 473 extensions to MARS. 475 3.2.1.3 ATM UNI 477 As discussed in [3], there are two issues related to current ATM UNI 478 specifications. Neither UNI3.x nor UNI 4.0 support QoS renegotiation 479 or heterogeneous point-to-multipoint VCs. Support of either of these 480 features would benefit running RSVP over ATM. QoS renegotiation would 481 be particularly beneficial since the only option available today for 482 changing VC QoS parameters is replacing the VC. 484 3.2.1.4 LANE 486 Although running RSVP over LANE is not considered to be critical at 487 this time, it may become desirable at some point in the future. If 488 LANE was used to support RSVP controlled flows, it would be desirable 489 for VCs to be establish with specific QoS for those flows. LANE 490 currently does not include any ability to signal QoS requirements or 491 to control QoS used for established VCs. So, if RSVP was to be run 492 over LANE, LANE would need to be extend to provide a QoS signaling 493 interface. Such extensions would also need to ensure proper QoS 494 allocation for multicast traffic. 496 4. RSVP Over ATM UNI 3.x 498 This section describes a method for running RSVP over ATM UNI 3.x. 499 The presented method is consistent with the framework described in 500 the previous section. This method is targeted at today's ATM 501 technology and networks. The key areas of the approach are 502 encapsulation, VC management, and multicasting. The approach also 503 requires changes to RSVP's interfaces and processing rules. 505 4.1 Encapsulation 507 Since RSVP is a signaling protocol used to control flows of IP data 508 packets, encapsulation for both RSVP packets and associated IP data 509 packets must be defined. While it is possible to use different 510 encapsulations for each, this does not seem to make sense. So, the 511 same encapsulation will be used for RSVP and the flows of IP data 512 packets controlled by RSVP. As previously mentioned, RFC1483 and LANE 513 are two defined encapsulation options for IP over ATM. Currently LANE 514 doesn't have a QoS control interface. So, since QoS control is needed 515 to make RSVP over ATM useful, RFC 1483 encapsulation must be used by 516 RSVP over ATM. This is the same encapsulation used by Classical IP 517 and NHRP. 519 4.2 VC Management 521 This section specifies a baseline solution for management of VCs 522 associated with QoS data flows. The described solution will 523 interoperate with other framework compliant solutions. The general 524 approach taken in developing this method was to use mechanisms that 525 matched today's standards and technology. As described in Section 3, 526 VCs will always be initiated and controlled by the sub-net sender. 527 When establishing and maintaining VCs, the sub-net sender will need 528 to deal with several complicating factors including multiple QoS 529 flows, requests for QoS changes, ATM short-cuts, and several 530 multicast issues. 532 4.2.1 Flow to VC Mapping 534 There are multiple options for mapping flows onto VCs, see [2] for a 535 more general discussion. The key issue to be addressed is providing 536 requested QoS downstream. While it is possible to send multiple flows 537 and multiple distinct reservations (FF) over single VCs, 538 implementation of such approaches is still a matter for research. So, 539 baseline RSVP over ATM implementations must allow for the use of a 540 single VC to support each RSVP reservation. By using independent VCs 541 per reservation, delivery of requested resources to the associated 542 QoS data flow can be assured. This approach does not preclude, but 543 does not specify, support for multiple flows per VC. 545 An RSVP reservation is characterized in [1] by the Traffic Control 546 State Block, or TCSB. In the approach where each reservation maps to 547 its own VC, the RSVP traffic control function "TC_AddFlowspec" will 548 translate into an ATM call setup. The "TC_DelFlowspec" control 549 function will translate into an ATM call release. The traffic control 550 interface will need to be extended to include end-point 551 identification. 553 4.2.2 QoS Renegotiation 555 UNI 3.x does not support any modifications to QoS parameters after VC 556 setup. During normal RSVP processing it is possible for the 557 requested resources to be increased or decreased. The RSVP traffic 558 control function "TC_ModFlowspec" is used to request a change in 559 allocated resources. Since UNI 3.x does not support such changes 560 directly, RSVP nodes must compensate. 562 The proposed approach for supporting changes in RSVP reservations is 563 to attempt to replace an existing VC with a new appropriately sized 564 VC. During setup of the replacement VC, the old VC is left in place 565 and unmodified. The old VC is left unmodified to minimize 566 interruption of QoS data delivery. Once the replacement VC is 567 established, data transmission is shifted to the new VC, and the old 568 VC is then closed. 570 If setup of the replacement VC fails, then the old QoS VC should 571 continue to be used. When the new reservation is larger than the old 572 reservation, the reservation request should be answered with an 573 error. When the new reservation is smaller than the old reservation, 574 the request should treated as if the modification was successful. 575 While leaving the larger allocation in place is suboptimal, it 576 maximizes delivery of service to the user. Implementations should 577 retry replacing the too large VC after some appropriate elapsed time. 579 One additional issue is that only one QoS change can be processed at 580 one time per reservation. If the (RSVP) requested QoS is changed 581 while the first replacement VC is still being setup, then the 582 replacement VC is closed and the whole VC replacement process is 583 restarted. 585 4.2.3 Short-Cuts 587 As previously discussed ATM short-cuts do not pose any problem for 588 RSVP. The only issue that needs to be addressed by the baseline RSVP 589 over ATM solution is when to establish a short-cut for a QoS data 590 flow. The proposed approach is to simply follow best-effort traffic. 591 When a short-cut has been established for best-effort traffic to a 592 destination or next-hop, that same end-point should be used when 593 setting up RSVP triggered VCs for QoS traffic to the same destination 594 or next-hop. This will happen naturally when PATH messages are 595 forwarded over the best-effort short-cut. 597 4.3 Multicast 599 There are several aspects to running RSVP over ATM that are 600 particular to multicast sessions. These issues result from the nature 601 of ATM point-to-multipoint connections. The baseline RSVP over ATM 602 solution addresses next-hops requesting different QoS values, and 603 handling of best-effort receivers. The last issue is not strictly 604 RSVP issues, but needs to be addressed in a complete RSVP over ATM 605 solution. 607 4.3.1 Heterogeneous Flows 609 As discussed in Section 2.2, multiple next-hops (or receivers) may 610 request different resources within a single session. The current RSVP 611 specification does address this case, but not within an ATM specific 612 context. The current processing rules and traffic control interface 613 describe a model where the largest requested reservation is used in 614 resource allocation, and traffic is delivered at the higher rate to 615 all next-hops. The simplest approach for RSVP over ATM will be to 616 emulate this approach even though this approach may be undesirable in 617 certain circumstances. So, baseline RSVP over ATM implementations 618 must be able to support heterogeneity in QoS requests by providing 619 the largest requested QoS to all next hops. Baseline implementations, 620 may also support heterogeneity through some other mechanism, e.g., 621 using multiple appropriately sized VCs. 623 There is an interesting interaction between heterogeneous flows and 624 QoS renegotiation that is worth mentioning. In the case where a RESV 625 message is received from a new next-hop and the requested resources 626 are larger than any existing reservation, both QoS renegotiation and 627 heterogeneity will need to be addressed. The question is whether to 628 first add the new next-hop or to change to the new QoS. This is a 629 fairly straight forward special case. Since the older, smaller 630 reservation does not support the new next-hop, the QoS renegotiation 631 process should be initiated. Since the new QoS is only needed by the 632 new next-hop, it should be the first end-point of the new VC. 634 4.3.2 Best-Effort Receivers 636 In any IP multicast group, some end-points will issues RSVP 637 reservation requests and some will not. Those who don't, are best- 638 effort receivers and there is no requirement to provide them improved 639 service delivery. In ATM, providing them better than best-effort 640 service may actually be the opposite of what the user desires since 641 in providing ATM QoS, there may be charges incurred or resources that 642 are wrongfully allocated. 644 Two possible approaches to this problem are using a single QoS VC or 645 using multiple VCs. In the single VC approach even the best-effort 646 receivers use the RSVP triggered QoS VC. This case optimizes host and 647 network resources. While this approach is simple to implement, it 648 may incur extra charges or may cause the best-effort receiver to not 649 receiver some traffic because the QoS VC setup failed. The multiple 650 VC approach ensures proper QoS delivery of data. It uses a QoS VC and 651 a best-effort VC. The QoS VC is used solely for RSVP controlled end- 652 points. The best-effort VC is used for all other end-points. The 653 best-effort VC does not include the RSVP controlled end-points in 654 order to avoid data duplication. The sender must duplicate packets 655 destined to the IP multicast group, placing one copy on each VC. 656 This approach uses more VCs, and sender processing and link 657 resources, but it assures proper handling of the traffic on the ATM 658 network. 660 Unfortunately, neither of these approaches is the right answer for 661 all cases. For some networks, e.g. LANs, it is likely that the single 662 VC approach will be desired. In other networks, e.g. public WANs, it 663 is likely that the multiple approach will be desired. The framework 664 discussed in section 3 permits each sub-network sender (router, or 665 host) to choose how traffic is mapped onto VCs. For this reason, 666 baseline RSVP over UNI3.x implementations must support best-effort 667 multicast receivers either using the single QoS VC or the multiple VC 668 approach. Implementations should support both approaches and provide 669 the ability to select which method is actually used, but are not 670 required to do so. 672 4.4 RSVP Changes 674 To support ATM there are several changes required to the RSVP 675 specification, [1]. These changes do not alter any protocol formats 676 or behavior. The same RSVP messages are sent and processed over ATM 677 as with any other sub-network technology. The changes required to run 678 over ATM are only internal and are required to ensure proper ATM VC 679 management. The traffic control and routing interfaces need to be 680 extended to include end-point identification, and message processing 681 rules need to be changed to trigger VC initiation. 683 4.4.1 Traffic Control Interface 685 The RSVP specification contains a description of a generic traffic 686 control interface. The specified interface is adequate when running 687 over point-to-point (e.g., PPP) or broadcast (e.g., Ethernet) sub- 688 networks, but not when running over ATM. Specifically, the interface 689 does not include the ability to identify next-hops when establishing 690 or modifying reservations. Two calls need to be extended to include 691 next-hop identification. Since described extensions can be used with 692 point-to-point and broadcast network technologies, a single traffic 693 control interface can be used for all network types. 695 * Make a Reservation 697 Call: TC_AddFlowspec( Interface, TC_Flowspec, 698 TC_Tspec, Police_Flags, Next_Hop_List ) 699 -> RHandle [, Fwd_Flowspec] 701 The new parameter, Next_Hop_List, contains one or more IP addresses 702 each of which are be associated with the requested reservation. The 703 traffic control module should establish a new reservation with the 704 specified flowspec to all listed next-hop addresses. Typically all 705 next-hops will be on the same sub-net as the sender. The one 706 exception to this case is when (NHRP) short-cuts are being used. 708 When Interface is an ATM interface, each TC_AddFlowspec call will 709 trigger setup of a new VC. The end-points of the VC will be 710 identified by Next_Hop_List. When there are more than one next-hops 711 listed, next-hops not include in initial VC setup must be added via 712 the "add party" request. The QoS service class and traffic 713 parameters will be set according to (the to be defined) INT-SERV to 714 ATM mappings. All return (reverse path) traffic parameters will be 715 set to zero (0), even for point-to-point calls. 717 * Modify Reservation 719 Call: TC_ModFlowspec( Interface, RHandle, TC_Flowspec, 720 Sender_Tspec, Police_flags, 721 Next_Hop_List ) 722 [ -> Fwd_Flowspec ] 724 Next_Hop_List contains the full list of next-hop addresses. 725 Omission of a previously listed addresses indicates that those 726 next-hops should be dropped from the reservation. Addition 727 addresses should be added to the reservation. It is valid for 728 both TC_FlowSpec and Next_Hop_List to indicate reservation 729 modifications. 731 When Interface is an ATM interface, the TC_ModFlowspec call will 732 need to check for two types of change, change in next-hops and 733 change in QoS. To check for change in next-hops, the list of 734 existing VC end-points should be compared with Next_Hop_List. 735 Any end-points not listed in Next_Hop_List should be dropped 736 from the VC via the "drop party" request. Any next-hops that 737 are not already end-points of the VC should be add via the "add 738 party" request. 740 When a QoS change is requested, a new VC should be established 741 to all listed entries in Next_Hop_List. Once all next-hops have 742 been added to the new VC, data forwarding should be set to use 743 the new VC, and the old VC should be released (closed). If all 744 next-hops cannot be added, then the new VC should be closed, and 745 failure should be returned. 747 It is valid for both QoS and Next_Hop_List to be changed in a 748 single call. In this case, any end-points of the existing VC not 749 listed in Next_Hop_List should be dropped from the old VC before 750 starting setup of the new VC. This ensures proper next-hop 751 handling even when setup of the new VC fails. 753 4.4.2 Routing Interface 755 As with Traffic Control, the routing interface needs to be extended 756 to include next-hop identification. Again the described extensions 757 can be used with point-to-point and broadcast network technologies. 759 * Route Query 761 Ucast_Route_Query( [ SrcAddress, ] DestAddress, 762 Notify_flag ) 763 -> OutInterface, Next_Hop 765 Mcast_Route_Query( [ SrcAddress, ] DestAddress, 766 Notify_flag ) 767 -> [ IncInterface, ] OutInterface_list, 768 Next_Hop_List 770 The Next_Hop return value contains the IP address of the 771 next-hop to be used on OutInterface. Next_Hop_List contains a 772 per OutInterface list of next-hop IP addresses. In the case of 773 ATM, it is expected that unicast information will be obtained 774 from standard routing or NHRP [7], and that multicast 775 information will be obtained either via MARS [8] or directly 776 from a multicast routing protocol, e.g., MOSPF. 778 * Route Change Notification 780 Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress, 781 OutInterface, 782 Next_Hop 784 Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, 785 [ IncInterface, ] OutInterface_list, 786 Next_Hop_List 788 The new parameters are used to indicated changes in next-hop 789 information. 791 4.4.3 Processing Rules 793 This section lists changes to the processing rules contained in [1]. 794 The changes are limited to traffic control processing, and are fairly 795 minor. While the processing rules are being changed to support RSVP 796 over ATM, the same rules can be used to run RSVP over any network 797 technology. 799 4.4.3.1 TCSB - Traffic Control State Block 801 There is only one parameter that needs to be added to the TCSB and 802 this mirrors the changes made to the traffic control interface. The 803 addition to the TCSB is: 805 * Next_Hop_List, the list of next hops associated with the current 806 reservation. 808 4.4.3.2 Update Traffic Control Processing 810 The traffic control processing needs to be extended to support 811 changes in next-hops. This is a fairly minor change. The following is 812 the complete traffic control processing, most of which is directly 813 copied from [1]. All changes/additions are noted with a horizontal 814 bar (|) in the left column. 816 UPDATE TRAFFIC CONTROL 818 The sequence is invoked by many of the message arrival sequences 819 to set or adjust the local traffic control state in accordance 820 with the current reservation and path state. An implicit 821 parameter of this sequence is the `active' RSB. 823 If the result is to modify the traffic control state, this 824 sequence notifies any matching local applications with a 825 RESV_EVENT upcall. If the state change is such that it should 826 trigger immediate Resv refresh messages, it also turns on the 827 Resv_Refresh_Needed flag. 829 | Initially the Next_Hop_List is empty. 831 o Compute the traffic control parameters using the following 832 steps. 834 1. Consider the set of RSB's matching SESSION, 835 Filter_spec_list, and OI from the active RSB. 836 Initially the local flag Is_Biggest is off. 838 - Compute the effective kernel flowspec, 839 TC_Flowspec, as the LUB of the FLOWSPEC values in 840 these RSB's. 842 - Compute the effective traffic control filter spec 843 (list) TC_Filter_Spec* as the union of the 844 Filter_spec_lists from these RSB's. 846 - If the active RSB has a FLOWSPEC larger than all 847 the others, turn on the Is_Biggest flag. 849 | - Add each RSB's next hop IP address to 850 | Next_Hop_List. 852 2. Scan all RSB's matching session and Filtss, for all 853 OI. Set TC_B_Police_flag on if TC_Flowspec is smaller 854 than, or incomparable to, any FLOWSPEC in those RSB's. 856 3. Locate the set of PSBs (senders) whose 857 SENDER_TEMPLATEs match Filter_spec_list in the active 858 RSB and whose OutInterface_list includes OI. 860 4. Set TC_E_Police_flag on if any of these PSBs have 861 their E_Police flag on. Set TC_M_Police_flag on if it 862 is a shared style and there is more than one PSB in 863 the set. 865 5. Compute Path_Te as the sum of the SENDER_TSPEC objects 866 in this set of PSBs. 868 o Search for a TCSB matching SESSION and OI; for distinct 869 style (FF), it must also match Filter_spec_list. 871 If none is found, create a new TCSB. 873 o If TCSB is new: 875 1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, 876 | Next_Hop_List, and the police flags into TCSB. 878 2. Turn the Resv_Refresh_Needed flag on and make the 879 traffic control call: 881 TC_AddFlowspec( OI, TC_Flowspec, 882 | Path_Te, police_flags, Next_Hop_List) 883 -> Rhandle, Fwd_Flowspec 885 3. If this call fails, build and send a ResvErr message 886 specifying "Admission control failed" and with the 887 InPlace flag off. Delete the TCSB, delete any 888 RESV_CONFIRM object from the active RSB, and return. 890 4. Otherwise (call succeeds), record Rhandle and 891 Fwd_Flowspec in the TCSB. For each filter_spec F in 892 TC_Filter_Spec*, call: 894 TC_AddFilter( OI, Rhandle, Session, F) 895 -> Fhandle 897 and record the returned Fhandle in the TCSB. 899 o Otherwise, if TCSB is not new but no effective kernel 900 flowspec TC_Flowspec was computed earlier, then: 902 1. Turn on the Resv_Refresh_Needed flag. 904 2. Call traffic control to delete the reservation: 906 TC_DelFlowspec( OI, Rhandle ) 908 3. Delete the TCSB and return. 910 o Otherwise, if TCSB is not new but the TC_Flowspec, Path_Te, 911 | police flags and/or Next_Hop_List just computed differ from 912 corresponding values in the TCSB, then: 914 1. If the TC_Flowspec and/or Path_Te values differ, turn 915 the Resv_Refresh_Needed flag on. 917 2. Call traffic control to modify the reservation: 919 TC_ModFlowspec( OI, Rhandle, TC_Flowspec, 920 | Path_Te, police_flags, Next_Hop_List ) 921 -> Fwd_Flowspec 923 3. If this call fails, build and send a ResvErr message 924 specifying "Admission control failed" and with the 925 InPlace bit on. Delete any RESV_CONFIRM object from 926 the active RSB and return. 928 4. Otherwise (the call succeeds), update the TCSB with 929 the new values and save Fwd_Flowspec in the TCSB. 931 o If the TCSB is not new but the TC_Filter_Spec* just 932 computed differs from the FILTER_SPEC* in the TCSB, then: 934 1. Make an appropriate set of TC_DelFilter and 935 TC_AddFilter calls to transform the Filter_spec_list 936 in the TCSB into the new TC_Filter_Spec*. 938 o If the active RSB contains a RESV_CONFIRM object, then: 940 1. If the Is_Biggest flag is on, move the RESV_CONFIRM 941 object into the TCSB and turn on the 942 Resv_Refresh_Needed flag. (This will later cause the 943 Resv REFRESH sequence to be invoked, which will either 944 forward or return the RESV_CONFIRM object, deleting it 945 from the TCSB in either case). 947 2. Otherwise, create and send a ResvConf message to the 948 address in the RESV_CONFIRM object. Include the 949 RESV_CONFIRM object in the ResvConf message. The 950 ResvConf message should also include an ERROR_SPEC 951 object whose Error_Node parameter is IP address of OI 952 from the TCSB and that specifies "No Error". 954 o If the Resv_Refresh_Needed flag is on and the RSB is not 955 from the API, make a RESV_EVENT upcall to any matching 956 application: 958 Call: ( session-id, RESV_EVENT, 959 style, Flowspec, Filter_spec_list 960 [ , POLICY_DATA] ) 962 where Flowspec and Filter_spec_list come from the TCSB and 963 the style comes from the active RSB. 965 o Return to the event sequence that invoked this one. 967 5. Security Considerations 969 Security issues are not addressed in this memo. 971 6. References 973 [1] Braden, R., Zhang, L., Estrin, D., Herzog, S., and S. Jamin, 974 "Resource ReSerVation Protocol (RSVP) - Version 1 Functional 975 Specification", Internet Draft. 977 [2] Berson, S., "Classical RSVP and IP over ATM", Proceedings INET96. 979 [3] Borden, M., Crawley , E., Krawczyk, J, Baker, F., and Berson, S., 980 "Issues for RSVP and Integrated Services over ATM", Internet Draft. 982 [4] Onvural, R., Srinivasan, V., "A Framework for Supporting RSVP 983 Flows Over ATM Networks", Internet Draft. 985 [5] The ATM Forum, "LAN Emulation Over ATM Specification", Version 986 1.0 988 [6] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, December, 989 1993. 991 [7] Katz, D., Piscitello, D., Cole, B., Luciani, J., "NBMA Next Hop 992 Resolution Protocol (NHRP)", Internet Draft. 994 [8] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM 995 Networks", Internet Draft. 997 [9] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation 998 Layer 5", RFC 1483, July 1993. 1000 7. Author's Address 1002 Lou Berger 1003 FORE Systems 1004 6905 Rockledge Drive 1005 Suite 800 1006 Bethesda, MD 20817 1008 Phone: 301-571-2534 1009 EMail: lberger@fore.com