idnits 2.17.1 draft-ietf-tsvwg-rsvp-bw-reduction-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 859. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 875), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 213 has weird spacing: '...). The reser...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'XXXX' on line 614 == Unused Reference: '12' is defined on line 815, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 818, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-lefaucheur-rsvp-ipsec-01 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group James Polk 3 Internet Draft Subha Dhesikan 4 Expiration: July 24th, 2005 Cisco Systems 5 File: draft-ietf-tsvwg-rsvp-bw-reduction-02.txt January 24th, 2005 7 A Resource Reservation Protocol Extension for the 8 Reduction of Bandwidth of a Reservation Flow 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 24th, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). All Rights Reserved. 39 Abstract 41 This document proposes an extension to the Resource Reservation 42 Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an 43 existing reservation. This mechanism can be used to affect 44 individual reservations, aggregate reservations or other forms of 45 RSVP tunnels. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Individual Reservation Reduction Scenario . . . . . . . . . . 4 52 3. RSVP Aggregation Overview . . . . . . . . . . . . . . . . . . 5 53 3.1 RSVP Aggregation Reduction Scenario . . . . . . . . . . . 7 54 4. Requirements for Reservation Reduction . . . . . . . . . . . 8 55 5. RSVP Bandwidth Reduction Solution . . . . . . . . . . . . . . 9 56 5.1 Partial Preemption Error Code . . . . . . . . . . . . . 9 57 5.2 Error Flow Descriptor . . . . . . . . . . . . . . . . . 10 58 5.3 Individual Reservation Flow Reduction . . . . . . . . . 10 59 5.4 Aggregation Reduction of Individual Flows . . . . . . . 10 60 5.5 RSVP Flow Reduction involving IPSec Tunnels . . . . . . 11 61 5.6 Reduction of Multiple Flows At Once . . . . . . . . . . 11 62 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 63 7. Security Considerations . . . . . . . . . . . . . . . . . . 12 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 66 Appendix. Walking Through the Solution . . . . . . . . . . . . . 13 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 10.1 Normative References . . . . . . . . . . . . . . . . . . 16 69 10.2 Informational References . . . . . . . . . . . . . . . . 17 70 Author Information . . . . . . . . . . . . . . . . . . . . . 17 72 1. Introduction 74 This document proposes an extension to the Resource Reservation 75 Protocol (RSVP) [1] to allow an existing reservation to be reduced 76 in allocated bandwidth in lieu of tearing that reservation down when 77 some of that reservation's bandwidth is needed for other purposes. 78 Several examples exist in which this mechanism may be utilized. 80 The bandwidth allotted to an individual reservation may be reduced 81 due to a variety of reasons such as preemption, etc. In such cases, 82 when the entire bandwidth allocated to a reservation is not 83 required, the reservation need not be torn down. The solution 84 described in this document allows endpoints to negotiate a new 85 (lower) bandwidth that falls at or below the specified new bandwidth 86 maximum allocated by the network. Using a voice session as an 87 example, this indication in RSVP could lead endpoints, using another 88 protocol such as Session Initiation Protocol (SIP) [9], to signal 89 for a lower bandwidth codec and retain the reservation. 91 With RSVP aggregation [2], two aggregate flows with differing 92 priority levels may traverse the same router interface. If that 93 router interface reaches bandwidth capacity and is then asked to 94 establish a new reservation or increase an existing reservation the 95 router has to make a choice: deny the new request (because all 96 resources have been utilized) or preempt an existing lower priority 97 reservation to make room for the new or expanded reservation. 99 If the flow being preempted is an aggregate of many individual 100 flows, this has greater consequences. While [2] clearly does not 101 terminate all the individual flows if an aggregate is torn down, 102 this event will cause packets to be discarded during aggregate 103 reservation reestablishment. This document describes a method where 104 only the minimum required bandwidth is taken away from the lower- 105 priority aggregated reservation and the entire reservation is not 106 preempted. This has the advantage that only some of the microflows 107 making up the aggregate are affected. Without this extension, all 108 individual flows are affected and the deaggregator will have to 109 attempt the reservation request with a reduced bandwidth. 111 RSVP tunnels utilizing IPSec [8] also require an indication that 112 the reservation must be reduced to a certain amount (or less). RSVP 113 aggregation with IPSec Tunnels is being defined in [11], which 114 should be able to take advantage of the mechanism created here in 115 this specification. 117 Note that when this document refers to a router interface being 118 "full" or "at capacity", this does not imply that all of the 119 bandwidth has been used, but rather that all of the bandwidth 120 available for reservation(s) via RSVP under the applicable policy 121 has been used. Policies for real-time traffic routinely reserve 122 capacity for routing and inelastic applications, and may distinguish 123 between voice, video, and other real time applications. 125 Explicit Congestion notification (ECN) [10] is an indication that 126 the transmitting endpoint must reduce its transmission. It does not 127 provide sufficient indication to tell the endpoint by how much the 128 reduction should be. Hence the application may have to attempt 129 multiple times before it is able to drop its bandwidth utilization 130 below the available limit. Therefore, while we consider ECN to be 131 very useful for elastic applications, it is not sufficient for the 132 purpose of inelastic application where an indication of bandwidth 133 availability is useful for codec selection. 135 Section 2 will discuss the individual reservation flow problem 136 while Section 3 will discuss the aggregate reservation flow 137 problem space. Section 4 lists the requirements for this extension. 138 Section 5 details the protocol changes necessary in RSVP to create a 139 reservation reduction indication. And finally, there is an appendix 140 with a walk-through example of how this extension modifies RSVP 141 functionality in an aggregate scenario. 143 This document is intended to be classified as an 'update' to RFC 144 2205 [1], as this mechanism affects the behaviors of the ResvErr and 145 ResvTear indications defined in that document. 147 1.1 Conventions used in this document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [4]. 153 2. Individual Reservation Reduction Scenario 155 Figure 1 is a network topology that is used to describe the benefit 156 of bandwidth reduction in an individual reservation. 158 +------------+ +------------+ 159 | |Int 1 | |Int 7 | | 160 Flow 1===> | +----- | |------+ | Flow 1===> 161 | R1 |Int 2 |===========>|Int 8 | R2 | 162 | | |:::::::::::>| | | 163 Flow 2:::> | +----- | |------+ | Flow 2:::> 164 | |Int 3 | |Int 9 | | 165 +------------+ +------------+ 167 Figure 1. Simple Reservation Flows 169 Figure 1. Legend/Rules: 171 - Flow 1 priority = 300 172 - Flow 2 priority = 100 173 - Both flows are shown in the same direction (left to 174 right). Corresponding flows in the reverse direction are 175 not shown for diagram simplicity 177 RSVP is a reservation establishment protocol in one direction only. 178 This split path philosophy is because the routed path from one 179 device to the other in one direction might not be the routed path 180 for communicating between the same two endpoints in the reverse 181 direction. End-systems must request 2 one-way reservations if that 182 is what is needed for a particular application (like voice calls). 183 Please refer to [1] for the details on how this functions. This 184 example only describes the reservation scenario in one direction for 185 simplicity sake. 187 Figure 1. depicts 2 routers, (R1 and R2) initially with only one 188 flow (Flow 1). The flows are forwarded from R1 to R2 via 189 interface 2. For this example, let us say that flow 1 and flow 2 190 each require 80 units of bandwidth (such as for the codec G.711 with 191 no silence suppression). Let us also say that the RSVP bandwidth 192 limit for interface 2 of R1 is 100 units. 194 As described in [3], a priority indication is established for each 195 flow. In fact, there are two priority indications: 197 1) one to establish the reservation, and 198 2) one to defend the reservation. 200 In this example, flow 1 and flow 2 have an 'establishing' and a 201 'defending' priority of 300 and 100 respectively. Flow 2 will have 202 a higher establishing priority than flow 1 has for its defending 203 priority. This means that when flow 2 is signaled, and if no 204 bandwidth is available at the interface, flow 1 will have to 205 relinquish bandwidth in favor of the higher priority request of flow 206 2. The priorities assigned to a reservation are always end-to-end, 207 and not altered by any routers in transit. 209 Without the benefit of this specification, flow 1 will be preempted. 210 This specification makes it possible for the ResvErr message to 211 indicate that 20 units are still available for a reservation to 212 remain up (the interface's 100 units maximum minus flow 2's 80 213 units). The reservation initiating node (router or end-system) for 214 Flow 1 has the opportunity to re-negotiate (via call signaling) for 215 acceptable parameters within the existing and available bandwidth 216 for the flow (for example, it may decide to change to using a codec 217 such as G.729) 219 The problems avoided with the partial failure of the flow are: 221 - Reduced packet loss which is resulted as flow 1 attempts to 222 re-establish the reservation for a lower bandwidth. 224 - Inefficiency caused by multiple attempts until flow 1 is able to 225 request bandwidth equal to or lower than what is available. If 226 flow 1 is established with much less than what is available then 227 it leads to inefficient use of available bandwidth. 229 3. RSVP Aggregation Overview 231 The following network overview is to help visualize the concerns 232 that this specification addresses in RSVP Aggregates. Figure 2 233 consists of 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9, 234 A, B, C, D, and E). Initially there will 5 flows per aggregate 235 (flow 9 will be introduced to cause the problem we are addressing in 236 this document),with 2 aggregates (X & Y); (1 through 5) in aggregate 237 X and (A through E) in aggregate Y. These 2 aggregates will cross 238 one router interface utilizing all available capacity (in this 239 example). 241 RSVP aggregation [per 2] is no different from an individual 242 reservation with respect to being unidirectional. 244 Aggregator of X Deaggregator of X 245 | | 246 V V 247 +------+ +------+ +------+ +------+ 248 Flow 1-->| | | | | | | |--> Flow 1 249 Flow 2-->| | | | | | | |--> Flow 2 250 Flow 3-->| |==>| | | |==>| |--> Flow 3 251 Flow 4-->| | ^ | | | | ^ | |--> Flow 4 252 Flow 5-->| | | | | | | | | |--> Flow 5 253 Flow 9 | R1 | | | R2 | | R3 | | | R4 | Flow 9 254 +------+ | +------+ +------+ | +------+ 255 | || || | 256 Aggregate X-->|| Aggregate X ||<--Aggregate X 257 || | || 258 +--------------+ | +--------------+ 259 | |Int 7 | | |Int 1 | | 260 | +----- | V |------+ | 261 | R10 |Int 8 |===========>|Int 2 | R11 | 262 | | |:::::::::::>| | | 263 | +----- | ^ |------+ | 264 | |Int 9 | | |Int 3 | | 265 +--------------+ | +--------------+ 266 .. | .. 267 Aggregate Y--->.. Aggregate Y ..<---Aggregate Y 268 | .. .. | 269 +------+ | +------+ +------+ | +------+ 270 Flow A-->| | | | | | | | | |--> Flow A 271 Flow B-->| | V | | | | V | |--> Flow B 272 Flow C-->| |::>| | | |::>| |--> Flow C 273 Flow D-->| | | | | | | |--> Flow D 274 Flow E-->| R5 | | R6 | | R7 | | R8 |--> Flow E 275 +------+ +------+ +------+ +------+ 276 ^ ^ 277 | | 278 Aggregator of Y Deaggregator of Y 280 Figure 2. Generic RSVP Aggregate Topology 282 Figure 2 legend/rules: 284 - Aggregate X priority = 100 285 - Aggregate Y priority = 200 286 - All boxes are Routers 287 - Both aggregates are shown in the same direction (left to 288 right). Corresponding aggregates in the reverse direction are 289 not shown for diagram simplicity 291 The path for aggregate X is: 293 R1 => R2 => R10 => R11 => R3 => R4 295 where aggregate X starts in R1, and deaggregates in R4. 297 Flows 1, 2, 3, 4, 5 and 9 communicate through aggregate A 299 The path for aggregate Y is: 301 R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8 303 where aggregate Y starts in R5, and deaggregates in R8. 305 Flows A, B, C, D and E communicate through aggregate B 307 Both aggregates share one leg or physical link: between R10 and 308 R11, thus they share one outbound interface: Int8 of R10, where 309 contention of resources may exist. That link has an RSVP capacity 310 of 800kbps. RSVP signaling (messages) is outside this 800kbps in 311 this example, as is any session signaling protocol like SIP. 313 3.1 RSVP Aggregation Reduction Scenario 315 Figure 2 shows an established aggregated reservation (aggregate X) 316 between the routers R1 and R4. This aggregated reservation 317 consists of 5 microflows (flow 1, 2, 3, 4, 5). For the sake of this 318 discussion, let us assume that each flow represents a voice call and 319 requires 80kb (such as for the codec G.711 with no silence 320 suppression). Aggregate X request is for 400kbps (80kbps * 5 flows). 321 The priority of the aggregate is derived from the individual 322 microflows that it is made up of. In the simple case, all flows of a 323 single priority are bundled as a single aggregate (another priority 324 level would be in another aggregate, even if traversing the same 325 path through the network). There may be other ways in which the 326 priority of the aggregate is derived, but for this discussion it 327 is sufficient to note that each aggregate contains a priority (both 328 hold and defending priority). The means of deriving the priority is 329 out of scope for this discussion. 331 Aggregate Y, in Figure 2, consists of flows A, B, C, D and E and 332 requires 400kbps (80kbps * 5 flows), and starts at R5 and ends 333 R8. This means there are two aggregates occupying all 800kbps of 334 the RSVP capacity. 336 When Flow 9 is added into aggregate X, this will occupy 80kbps more 337 than Int8 on R10 has available (880k offered load vs. 800k capacity) 338 [1] and [2] create a behavior in RSVP to deny the entire aggregate Y 339 and all its individual flows because aggregate X has a higher 340 priority. This situation is where this document focuses its 341 requirements and calls for a solution. There should be some means 342 to signal to all affected routers of aggregate Y that only 80kbps is 343 needed to accommodate another (higher priority) aggregate. A 344 solution that accomplishes this reduction instead of a failure 345 could: 347 - reduce significant packet loss of all flows within aggregate Y 349 During the re-reservation request period of time no packets will 350 traverse the aggregate until it is reestablished. 352 - reduces the chances that the reestablishment of the aggregate 353 will reserve an inefficient amount of bandwidth, causing the 354 likely preemption of more individual flows at the aggregator 355 than would be necessary had the aggregator had more information 356 (that RSVP does not provide at this time) 358 During reestablishment of the aggregation in Figure 2. (without any 359 modification to RSVP), R8 would guess at how much bandwidth to ask 360 for in the new RESV message. It could request too much bandwidth, 361 and have to wait for the error that not that much bandwidth was 362 available; it could request too little bandwidth and have that 363 aggregation accepted, but this would meant that more individual 364 flows would need to be preempted outside the aggregate than were 365 necessary, leading to inefficiencies in the opposite direction. 367 4. Requirements for Reservation Reduction 369 The following are the requirements to reduce the bandwidth of a 370 reservation. This applies to both individual and aggregate 371 reservations: 373 Req#1 - MUST have the ability to differentiate one reservation from 374 another. In the case of aggregates, it MUST distinguish one 375 aggregate from other flows. 377 Req#2 - MUST have the ability to indicate within an RSVP error 378 message (generated at the router with the congested 379 interface) that a specific reservation (individual or 380 aggregate) is to be reduced in bandwidth. 382 Req#3 - MUST have the ability to indicate within the same error 383 message the new maximum amount of bandwidth that is 384 available to be utilized within the existing reservation, 385 but no more. 387 Req#4 - MUST NOT produce a case in which retransmitted reduction 388 indications further reduce the bandwidth of a reservation. 389 Any additional reduction in bandwidth for a specified 390 reservation MUST be signaled in a new message. 392 RSVP messages are unreliable and can get lost. This specification 393 should not compound any error in the network. If a reduction 394 message were lost, another one needs to be sent. If the receiver 395 ends up receiving two copies to reduce the bandwidth of a 396 reservation by some amount, it is likely the router will reduce the 397 bandwidth by twice the amount than was actually called for. This 398 will be in error. 400 5. RSVP Bandwidth Reduction Solution 402 When a reservation is partially failed, a ResvErr (Reservation 403 Error) message is generated just as it is done currently with 404 preemptions. The error spec object and the preemption_pri policy 405 object are included as well. Very few additions/changes are needed 406 to the ResvErr message to support partial preemptions. A new error 407 sub code is required and is defined in section 5.1. The error 408 flowspec contained in the ResvErr message indicates the flowspec 409 that is reserved and this flowspec may not match or be less than the 410 original reservation request. This is defined in section 5.2. 412 A comment about RESV message not using a reliable transport. This 413 document recommends that ResvErr message be made reliable by 414 implementing mechanisms in [6]. 416 The current behavior in RSVP requires a ResvTear message to be 417 transmitted upstream when the ResvErr message is transmitted 418 downstream (per [1]). This ResvTear message terminates the 419 reservation in all routers upstream of the router where the failure 420 occurred. This document requires that the ResvTear is only 421 generated when the reservation is to be completely removed. In cases 422 where the reservation is only to be reduced, routers compliant with 423 this specification requires that the ResvTear message MUST NOT be 424 sent. 426 An appendix has been written to walk through the overall solution to 427 the problems presented in sections 2 and 3. There is mention of 428 this ResvTear transmission behavior within the appendix. 430 5.1 Partial Preemption Error Code 432 The ResvErr message generated due to preemption includes the Error 433 Spec object as well as the Preemption Priority Policy object. The 434 format of Error-spec objects is defined in [1]. The error code 435 listed in the ERROR_SPEC object for preemption [5] currently is as 436 follows: 438 Errcode = 2 (Policy Control Failure) and 439 ErrSubCode = 5 (ERR_PREEMPT) 441 The following error code is suggested in the Error_spec object for 442 partial preemption: 444 Errcode = 2 (Policy Control Failure) and 445 ErrSubCode = X (ERR_PARTIAL_PREEMPT) 447 Where 'X' is the number assigned by IANA for this error code 449 There is also an error code in the preemption-pri policy object. 450 This error code takes a value of 1 to indicate that the admitted 451 flow was preempted [3]. The same error value of 1 may be used for 452 the partial preemption case as well. 454 5.2 Error Flow Descriptor 456 The error flow descriptor is defined in [1] & [7]. In the case of 457 partial failure, the flowspec contained in the error flow 458 descriptor indicates the highest average and peak rates that the 459 preempting system can accept in the next RESV message. The 460 deaggregator must reduce its reservation to a number less than or 461 equal to that, whether by changing codecs, by dropping reservations, 462 or some other mechanism. 464 5.3 Individual Reservation Flow Reduction 466 When a router requires part of the bandwidth that has been allocated 467 to a reservation be used for another flow, the router engages in the 468 partial-reduction of bandwidth as described in this document. The 469 router sends a ResvErr downstream to indicate the partial error with 470 the error code and sub code as described in section 5.1. The 471 flowspec contained in the ResvErr message will be used to indicate 472 the bandwidth that is currently allocated. 474 The requesting endpoint that receives the ResvErr can then negotiate 475 with the transmitting endpoint to lower the bandwidth requirement 476 (by selecting another lower bandwidth codec, for example). After the 477 negotiations, both endpoints will issue the RSVP PATH and RESV 478 message with the new, lowered bandwidth. 480 5.4 Aggregation Reduction of Individual Flows 482 When a partial-failure occurs in a aggregation scenario, the 483 deaggregator receives the ResvErr message with the reduction 484 indication from a router in the path of the aggregate. It then 485 decides whether one or more individual flows from the aggregate are 486 to be affected by this ResvErr message. The following choices are 487 possible: 489 o If that (deaggregator) router determines one or more individual 490 flow(s) are to partially failed, then it sends a ResvErr message 491 with a reduced bandwidth indication to those individual flow(s). 492 This is as per the descriptions in the previous section (5.3). 494 o If that (deaggregator) router determines one individual flow is to 495 be preempted to satisfy the aggregate ResvErr, it determines which 496 flow is affected. That router transmits a new ResvErr message 497 downstream per [3]. That same router transmits a ResvTear message 498 upstream. This ResvTear message of an individual flow does not 499 tear down the aggregate. Only the individual flow is affected. 501 o If that (deaggregator) router determines multiple individual flows 502 are to be preempted to satisfy the aggregate ResvErr, it chooses 503 which flows are affected. That router transmits a new ResvErr 504 message downstream as per [3] to each individual flow. The router 505 also transmits ResvTear messages upstream for the same individual 506 flows. These ResvTear messages of an individual flow do not tear 507 down the aggregate. Only the individual flows are affected. 509 In all cases, the Deaggregator lowers the bandwidth requested in the 510 Aggregate Resv message to reflect the change. 512 Which particular flow or series of flows within an aggregate are 513 picked by the deaggregator for bandwidth reduction or preemption is 514 outside the scope of this document. 516 5.5 RSVP Flow Reduction involving IPSec Tunnels 518 RFC 2207 (per [8]) specifies how RSVP reservations function in IPSec 519 data flows. The nodes initiating the IPSec flow can be an end- 520 system like a computer, or it can router between two end-systems, or 521 it can be an in-line bulk encryption device immediately adjacent to 522 a router interface, [11] directly addresses this later scenario. 524 The methods of identification of an IPSec with reservation flow are 525 different than non-encrypted flows, but how the reduction mechanism 526 specified within this document functions is not. 528 An IPSec with reservation flow is, for all intents and purposes, 529 considered an individual flow with regard to how to reduce the 530 bandwidth of the flow. Obviously an IPSec with reservation flow can 531 be a series of individual flows or disjointed best effort packets 532 between two systems. But to this specification, this tunnel is an 533 individual RSVP reservation. 535 Anywhere within this specification that mentions an individual 536 reservation flow, the same rules of bandwidth reduction and 537 preemption MUST apply. 539 5.6 Reduction of Multiple Flows at Once 541 As a cautionary note, bandwidth SHOULD NOT be reduced across 542 multiple reservations at the same time, in reaction to the same 543 reduction event. A router not knowing the impact of reservation 544 bandwidth reduction on more than one flow may cause more wide spread 545 ill effects than is necessary. 547 This says nothing to a policy where preemption should or should not 548 occur across multiple flows. 550 6. Backwards Compatibility 552 Backwards compatibility with this extension will result in RSVP 553 operating as it does without this extension, and no worse. The two 554 routers involved in this extension are the router that had the 555 congested interface and the furthest downstream router that 556 determines what to do with the reduction indication. 558 In the case of the router that experiences congestion or otherwise 559 needs to reduce the bandwidth of an existing reservation: 561 - If that router supports this extension: 563 #1 - it generates the ResvErr message with the error code 564 indicating the reduction in bandwidth 566 #2 - it does not generate the ResvTear message 568 - If that router does not support this extension, it generates both 569 ResvErr and ResvTear messages according to [1]. 571 In the case of the router at the extreme downstream of a reservation 572 that receives the ResvErr message with the reduction indication 574 - If that router does support this extension: 576 #1 - it processes this error message and applies whatever local 577 policy it is configured to do to determine how to reduce the 578 bandwidth of this designated flow 580 - If the router does not support this extension: 582 #1 - it processes the ResvErr message according to [1] and all 583 extensions it is able to understand, but not this extension 584 from this document. 586 Thus, this extension does not cause ill effects within RSVP if one 587 or more routers support this extension, and one or more routers do 588 not support this extension. 590 7. Security Considerations 592 This document does not lessen the overall security of RSVP or of 593 reservation flows through an aggregate. 595 If this specification is implemented poorly - which is never 596 intended, but is a consideration - the following issues may arise: 598 1) If the ResvTear messages are transmitted initially (at the same 599 time as the ResvErr messages indicating a reduction in bandwidth 600 is necessary), all upstream routers will tear down the entire 601 reservation. This will free up the total amount of bandwidth of 602 this reservation inadvertently. This may cause the re- 603 establishment of an otherwise good reservation to fail. This has 604 the most severe affects on an aggregate that has many individual 605 flows that would have remained operational. 607 2) Just as RSVP has the vulnerability of premature termination of 608 valid reservations by rouge flows without authentication 609 [12 & 13], this mechanism will have the same vulnerability. 610 Usage of RSVP authentication mechanisms is encouraged. 612 8. IANA Considerations 614 IANA is to assign the following from RFC [XXXX] (i.e. this 615 document): 617 The following error code is to be defined in the Error_spec object 618 for partial reservation failure under "Errcode = 2 (Policy Control 619 Failure)": 621 ErrSubCode = X (ERR_PARTIAL_PREEMPT) 623 Where 'X' is assigned by IANA for this error code 625 The behavior of this ErrSubCode is defined in this document. 627 9. Acknowledgements 629 The authors would like to thank Fred Baker for contributing text and 630 guidance in this effort and to Roger Levesque and Francois Le 631 Faucheur for helpful comments. 633 Appendix 1. Walking Through the Solution 635 Here is a concise explanation of roughly how RSVP behaves with the 636 solution to the problems presented in sections 2 & 3 of this 637 document. There is no normative text in this appendix. 639 Here is a duplicate of Figure 2 from section 3 of the document body 640 (to bring it closer to the detailed description of the solution). 642 Aggregator of X Deaggregator of X 643 | | 644 V V 645 +------+ +------+ +------+ +------+ 646 Flow 1-->| | | | | | | |--> Flow 1 647 Flow 2-->| | | | | | | |--> Flow 2 648 Flow 3-->| |==>| | | |==>| |--> Flow 3 649 Flow 4-->| | ^ | | | | ^ | |--> Flow 4 650 Flow 5-->| | | | | | | | | |--> Flow 5 651 Flow 9-->| R1 | | | R2 | | R3 | | | R4 |--> Flow 9 652 +------+ | +------+ +------+ | +------+ 653 | || || | 654 Aggregate X--->|| Aggregate X ||<--Aggregate X 655 || | || 656 +--------------+ | +--------------+ 657 | |Int 7 | | |Int 1 | | 658 | +----- | V |------+ | 659 | R10 |Int 8 |===========>|Int 2 | R11 | 660 | | |:::::::::::>| | | 661 | +----- | ^ |------+ | 662 | |Int 9 | | |Int 3 | | 663 +--------------+ | +--------------+ 664 .. | .. 665 Aggregate Y--->.. Aggregate Y ..<---Aggregate Y 666 | .. .. | 667 +------+ | +------+ +------+ | +------+ 668 Flow A-->| | | | | | | | | |--> Flow A 669 Flow B-->| | V | | | | V | |--> Flow B 670 Flow C-->| |::>| | | |::>| |--> Flow C 671 Flow D-->| | | | | | | |--> Flow D 672 Flow E-->| R5 | | R6 | | R7 | | R8 |--> Flow E 673 +------+ +------+ +------+ +------+ 674 ^ ^ 675 | | 676 Aggregator of Y Deaggregator of Y 678 Duplicate of Figure 2. Generic RSVP Aggregate Topology 680 Looking at Figure 2., aggregate X (with five 80kbps flows) 681 traverses: 683 R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4 685 And aggregate Y (with five 80kbps flows) traverses: 687 R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8 689 Both aggregates are 400kbps. This totals 800kbps at Interface-7 in 690 R10, which is the maximum bandwidth RSVP has access to at this 691 interface. Signaling messages still traverse the interface without 692 problem. Aggregate X is at a higher relative priority than 693 aggregate Y. Local policy in this example is for higher relative 694 priority flows to preempt lower priority flows during times of 695 congestion. The following points describe the flow when aggregate A 696 is increased to include flow 9. 698 o When flow 9 (at 80kbps) is added to aggregate X, R1 will 699 initiate the PATH message towards the destination endpoint of 700 the flow. This hop-by-hop message will take it through R2, 701 R10, R11, R3 and R4 which is the aggregate X path (that 702 was built per [2] from the aggregate's initial set up) to the 703 endpoint node. 705 o In response, R4 will generate the RESV (reservation) message 706 [defined behavior per 1]. This RESV from the deaggregator 707 indicates an increase bandwidth sufficient to accommodate the 708 existing 5 flows (1,2,3,4,5) and the new flow (9) [as stated in 709 2]. 711 o As mentioned before, in this example, Int8 in R 10 can only 712 accommodate 800kbps, and aggregates X and Y have each already 713 established 400kbps flows comprised of five 80kbps individual 714 flows. Therefore, R10 (the interface that detects a congestion 715 event in this example) must make a decision about this new 716 congestion generating condition in regard to the RESV message 717 received at Int8. 719 o Local Policy in this scenario is to preempt lower priority 720 reservations to place higher priority reservations. This would 721 normally cause all of aggregate Y to be preempted just to 722 accommodate aggregate X's request for an additional 80kbps. 724 o This document defines how aggregate Y is not completely 725 preempted, but reduced in bandwidth by 80kbps. This is 726 contained in the ResvErr message that R10 generates 727 (downstream) towards R11, R7 and R8. See section 5 for 728 the details of the error message. 730 o Normal operation of RSVP is to have the router that generates a 731 ResvErr message downstream to also generate a ResvTear message 732 upstream (in the opposite direction towards R5). The ResvTear 733 message terminates an individual flow or aggregate flow. This 734 document calls for that message to not be sent on any partial 735 failure of reservation. 737 o R8 is the deaggregator of aggregate Y. The deaggregator 738 controls all the parameters of an aggregate reservation. This 739 will be the node that reduces the necessary bandwidth of the 740 aggregate as a response to the reception of an ResvErr message 741 (from R10) indicating such an action is called for. In this 742 example, bandwidth reduction is accomplished by preempting an 743 individual flow within the aggregate (perhaps picking on Flow D 744 for individual preemption by generating a ResvErr downstream on 745 that individual flow). 747 o At the same time, a ResvTear message is transmitted upstream on 748 that individual flow (Flow D) by R8. This will not affect the 749 aggregate directly, but is an indication to the routers (and the 750 source end-system) which individual flow is to be preempted. 752 o Once R8 preempts whichever individual flow (or 'bandwidth' at 753 the aggregate ingress), it transmits a new RESV message for that 754 aggregate (Y), not for a new aggregate. This RESV from the 755 deaggregator indicates an decrease in bandwidth sufficient to 756 accommodate the remaining 4 flows (A,B,C,E), which is now 757 320kbps (in this example). 759 o This RESV message travels the entire path of the reservation, 760 resetting all routers to this new aggregate bandwidth value. 761 This should be what is necessary to prevent a ResvTear message 762 from being generated by R10 towards R6 and R5. 764 R5 will not know through this RESV message which individual flow 765 was preempted. If in this example, R8 was given more bandwidth to 766 keep, it might have transmitted a bandwidth reduction ResvErr 767 indication towards the end-system of Flow D. In that case, a voice 768 signaling protocol (such as SIP) could have attempted a 769 renegotiation of that individual flow to a reduced bandwidth (say, 770 but changing the voice codec from G.711 to G. 729). This could have 771 saved Flow D from preemption. 773 10. References 775 10.1 Normative References 777 [1] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 778 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 779 Specification", RFC 2205, September 1997 781 [2] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of 782 RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001 784 [3] S. Herzog, "Signaled Preemption Priority Policy Element", RFC 785 3181, October 2001 787 [4] Bradner S., "Key words for use in RFCs to Indicate Requirement 788 Levels", RFC 2119, March 1997 790 [5] S. Herzog, "RSVP Extensions for Policy Control", RFC 2750, 791 January 2000 793 [6] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini, 794 "RSVP Refresh Overhead Reduction Extensions" RFC 2961, April 2001 796 [7] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", 797 RFC 2210, September 1997 799 [8] L. Berger, T. O'Malley, "RSVP Extensions for IPSEC Data Flows", 800 RFC 2207, September 1997 802 10.2 Informational References 804 [9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, 805 J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 806 Session Initiation Protocol", RFC 3261, May 2002. 808 [10] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit 809 Congestion Notification (ECN) to IP", RFC 3168, September 2001 811 [11] F. Le Faucheur, B. Davie, P. Bose, C. Christou, " Aggregate 812 reservations for IPSec Tunnel", draft-lefaucheur-rsvp-ipsec-01, 813 July 2005, "work in progress" 815 [12] F. Baker, B. Lindell, M. Talwar, "RSVP Cryptographic 816 Authentication", RFC 2747, January 2000 818 [13] R. Braden, L. Zhang, "RSVP Cryptographic Authentication -- 819 Updated Message Type Value", RFC 3097, April 2001 821 Author Information 823 James M. Polk 824 Cisco Systems 825 2200 East President George Bush Turnpike 826 Richardson, Texas 75082 USA 828 Email: jmpolk@cisco.com 830 Subha Dhesikan 831 Cisco Systems 832 170 W. Tasman Drive 833 San Jose, CA 95134 USA 835 Email: sdhesika@cisco.com 837 Intellectual Property Statement 839 The IETF takes no position regarding the validity or scope of any 840 Intellectual Property Rights or other rights that might be claimed 841 to pertain to the implementation or use of the technology described 842 in this document or the extent to which any license under such 843 rights might or might not be available; nor does it represent that 844 it has made any independent effort to identify any such rights. 845 Information on the procedures with respect to rights in RFC 846 documents can be found in BCP 78 and BCP 79. 848 Copies of IPR disclosures made to the IETF Secretariat and any 849 assurances of licenses to be made available, or the result of an 850 attempt made to obtain a general license or permission for the use 851 of such proprietary rights by implementers or users of this 852 specification can be obtained from the IETF on-line IPR repository 853 at http://www.ietf.org/ipr. 855 The IETF invites any interested party to bring to its attention any 856 copyrights, patents or patent applications, or other proprietary 857 rights that may cover technology that may be required to implement 858 this standard. Please address the information to the IETF at 859 ietf-ipr@ietf.org. 861 Disclaimer of Validity 863 This document and the information contained herein are provided on 864 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 865 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 866 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 867 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 868 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 869 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 871 Copyright Statement 873 Copyright (C) The Internet Society (2006). This document is subject 874 to the rights, licenses and restrictions contained in BCP 78, and 875 except as set forth therein, the authors retain all their rights. 877 Acknowledgment 879 Funding for the RFC Editor function is currently provided by the 880 Internet Society. 882 The Expiration date for this Internet Draft is: 884 July 24th, 2006