idnits 2.17.1 draft-ietf-tsvwg-rsvp-bw-reduction-00.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 857. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 870. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 886), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 19 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 248 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 632 == Outdated reference: A later version (-02) exists of draft-lefaucheur-rsvp-ipsec-00 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force James Polk 2 Internet Draft Subha Dhesikan 3 Expiration: August 10th, 2005 Cisco Systems 4 File: draft-ietf-tsvwg-rsvp-bw-reduction-00.txt 6 A Resource Reservation Extension for the Reduction of 7 Bandwidth of a Reservation Flow 9 February 10th, 2005 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance 16 with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This document proposes an extension to the Resource Reservation 41 Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an 42 existing reservation. This mechanism can be used to affect 43 individual reservations, aggregate reservations or other forms of 44 RSVP tunnels. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 4 50 1.2 Changes From Previous Versions . . . . . . . . . . . . . 4 51 2. Individual Reservation Reduction Scenario . . . . . . . . . . 5 52 3. RSVP Aggregation Overview . . . . . . . . . . . . . . . . . . 6 53 3.1 RSVP Aggregation Reduction Scenario . . . . . . . . . . . 8 54 4. Requirements for Reservation Reduction . . . . . . . . . . . 9 55 5. RSVP Bandwidth Reduction Solution . . . . . . . . . . . . . . 10 56 5.1 Partial Preemption Error Code . . . . . . . . . . . . . 10 57 5.2 Error Flow Descriptor . . . . . . . . . . . . . . . . . 11 58 5.3 Individual Reservation Flow Reduction . . . . . . . . . . 11 59 5.4 Aggregation Reduction of Individual Flows . . . . . . . . 11 60 5.5 RSVP Flow Reduction involving IPsec Tunnels . . . . . . . 12 61 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 62 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 65 Appendix. Walking Through the Solution . . . . . . . . . . . . . 14 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 10.1 Normative References . . . . . . . . . . . . . . . . . . 17 68 10.2 Informational References . . . . . . . . . . . . . . . . 17 69 11. Author Information . . . . . . . . . . . . . . . . . . . . . 18 71 1. Introduction 73 This document proposes an extension to the Resource Reservation 74 Protocol (RSVP) [1] to allow an existing reservation to be reduced 75 in allocated bandwidth in lieu of tearing that reservation down when 76 some of that reservation's bandwidth is needed for other purposes. 77 Several examples exist in which this mechanism may be utilized. 79 The bandwidth allotted to an individual reservation may be reduced 80 due to a variety of reasons such as preemption, etc. In such cases, 81 when the entire bandwidth allocated to a reservation is not 82 required, the reservation need not be torn down. The solution 83 described in this document allows endpoints to negotiate a new 84 (lower) bandwidth that falls at or below the specified new bandwidth 85 maximum allocated by the network. Using a voice session as an 86 example, this indication in RSVP could lead endpoints, using another 87 protocol such as Session Initiation Protocol (SIP) [9], to signal 88 for a lower bandwidth codec and retain the reservation. 90 With RSVP aggregation [2], two aggregate flows with differing 91 priority levels may traverse the same router interface. If that 92 router interface reaches bandwidth capacity and is then asked to 93 establish a new reservation or increase an existing reservation the 94 router has to make a choice: deny the new request (because all 95 resources have been utilized) or preempt an existing lower priority 96 reservation to make room for the new or expanded reservation. 98 If the flow being preempted is an aggregate of many individual 99 flows, this has greater consequences. While [2] clearly does not 100 terminate all the individual flows if an aggregate is torn down, 101 this event will cause packets to be discarded during aggregate 102 reservation reestablishment. This document describes a method where 103 only the minimum required bandwidth is taken away from the lower- 104 priority aggregated reservation and the entire reservation is not 105 preempted. This has the advantage that only some of the microflows 106 making up the aggregate are affected. Without this extension, all 107 individual flows are affected and the deaggregator will have to 108 attempt the reservation request with a reduced bandwidth. 110 RSVP tunnels utilizing IPsec [8] also require an indication that 111 the reservation must be reduced to a certain amount (or less). RSVP 112 aggregation with IPsec Tunnels is being defined in [11], which 113 should be able to take advantage of the mechanism created here in 114 this specification. 116 Note that when this document refers to a router interface being 117 "full" or "at capacity", this does not imply that all of the 118 bandwidth has been used, but rather that all of the bandwidth 119 available for reservation(s) via RSVP under the applicable policy 120 has been used. Policies for real-time traffic routinely reserve 121 capacity for routing and inelastic applications, and may distinguish 122 between voice, video, and other real time applications. 124 Explicit Congestion notification (ECN) [10] is an indication that 125 the transmitting endpoint must reduce its transmission. It does not 126 provide sufficient indication to tell the endpoint by how much the 127 reduction should be. Hence the application may have to attempt 128 multiple times before it is able to drop its bandwidth utilization 129 below the available limit. Therefore, while we consider ECN to be 130 very useful for elastic applications, it is not sufficient for the 131 purpose of inelastic application where an indication of bandwidth 132 availability is useful for codec selection. 134 Section 2 will discuss the individual reservation flow problem 135 while Section 3 will discuss the aggregate reservation flow 136 problem space. Section 4 lists the requirements for this extension. 137 Section 5 details the protocol changes necessary in RSVP to create a 138 reservation reduction indication. And finally, there is an appendix 139 with a walk-through example of how this extension modifies RSVP 140 functionality in an aggregate scenario. 142 This document is intended to be classified as an 'update' to RFC 143 2205 [1], as this mechanism affects the behaviors of the ResvErr and 144 ResvTear indications defined in that document. 146 1.1 Conventions used in this document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [4]. 152 1.2 Changes from previous versions 154 This is a listing of the changes that have taken place to this 155 Internet Draft since the previous version: 157 o Changed the filename to reflect this now being a Working Group 158 item within the TSVWG 160 o Added a informative reference to the new Internet Draft involving 161 Aggregates inside IPsec tunnels that use RSVP 163 o Made minor editorial changes to make document more concise 165 o Added a new section 6 on Backwards Compatibility 167 This is a listing of the changes that have taken place to this 168 Internet Draft since from the Aggregation only version to the 169 Reservation version: 171 o Changed the filename to remove "aggregation" as the focus of the 172 draft to open up this solution to a wider applicability 174 o Reduced text in the introductory section to be more succinct 176 o Added the use-case for this mechanism with individual reservations 178 o Added the use-case for this mechanism with reservations of 179 individual IPsec data flows 181 o Opened up the text in the document body for this wider 182 applicability 184 o Mentioned why ECN is inappropriate for reducing bandwidth 185 allocations of RSVP reservations. 187 2. Individual Reservation Reduction Scenario 189 Figure 1 is a network topology that is used to describe the benefit 190 of bandwidth reduction in an individual reservation. 192 +--------------+ +--------------+ 193 | |Int 1 | |Int 7 | | 194 Flow 1===> | +----- | |------+ | Flow 1===> 195 | Rtr1 |Int 2 |===========>|Int 8 | Rtr2 | 196 | | |:::::::::::>| | | 197 Flow 2:::> | +----- | |------+ | Flow 2:::> 198 | |Int 3 | |Int 9 | | 199 +--------------+ +--------------+ 201 Figure 1. Simple Reservation Flows 203 Figure 1. Legend/Rules: 205 - Flow 1 priority = 300 206 - Flow 2 priority = 100 207 - Both flows are shown in the same direction (left to 208 right). Corresponding flows in the reverse direction are 209 not shown for diagram simplicity 211 RSVP is a reservation establishment protocol in one direction only. 212 This split path philosophy is because the routed path from one 213 device to the other in one direction might not be the routed path 214 for communicating between the same two endpoints in the reverse 215 direction. End-systems must request 2 one-way reservations if that 216 is what is needed for a particular application (like voice calls). 217 Please refer to [1] for the details on how this functions. This 218 example only describes the reservation scenario in one direction for 219 simplicity sake. 221 Figure 1. depicts 2 routers, (Rtr1 and Rtr2) initially with only one 222 flow (Flow 1). The flows are forwarded from Rtr1 to Rtr2 via 223 interface 2. For this example, let us say that flow 1 and flow 2 224 each require 80 units of bandwidth (such as for the codec G.711 with 225 no silence suppression). Let us also say that the RSVP bandwidth 226 limit for interface 2 of Rtr1 is 100 units. 228 As described in [3], a priority indication is established for each 229 flow. In fact, there are two priority indications: 231 1) one to establish the reservation, and 233 2) one to defend the reservation. 235 In this example, flow 1 and flow 2 have an 'establishing' and a 236 'defending' priority of 300 and 100 respectively. Flow 2 will have 237 a higher establishing priority than flow 1 has for its defending 238 priority. This means that when flow 2 is signaled, and if no 239 bandwidth is available at the interface, flow 1 will have to 240 relinquish bandwidth in favor of the higher priority request of flow 241 2. The priorities assigned to a reservation are always end-to-end, 242 and not altered by any routers in transit. 244 Without the benefit of this specification, flow 1 will be preempted. 245 This specification makes it possible for the ResvErr message to 246 indicate that 20 units are still available for a reservation to 247 remain up (the interface's 100 units maximum minus flow 2's 80 248 units). The reservation initiating node (router or end-system) for 249 Flow 1 has the opportunity to re-negotiate (via call signaling) for 250 acceptable parameters within the existing and available bandwidth 251 for the flow (for example, it may decide to change to using a codec 252 such as G.729) 254 The problems avoided with the partial failure of the flow are: 256 - Reduced packet loss which is resulted as flow 1 attempts to 257 re-establish the reservation for a lower bandwidth. 259 - Inefficiency caused by multiple attempts until flow 1 is able to 260 request bandwidth equal to or lower than what is available. If 261 flow 1 is established with much less than what is available then 262 it leads to inefficient use of available bandwidth. 264 3. RSVP Aggregation Overview 266 The following network overview is to help visualize the concerns 267 that this specification addresses in RSVP Aggregates. Figure 2 268 consists of 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9, 269 A, B, C, D, and E). Initially there will 5 flows per aggregate 270 (flow 9 will be introduced to cause the problem we are addressing in 271 this document),with 2 aggregates (A & B); (1 through 5) in aggregate 272 A and (A through E) in aggregate B. These 2 aggregates will cross 273 one router interface utilizing all available capacity (in this 274 example). 276 RSVP aggregation [per 2] is no different from an individual 277 reservation with respect to being unidirectional. 279 Aggregator of A Deaggregator of A 280 | | 281 V V 282 +------+ +------+ +------+ +------+ 283 Flow 1-->| | | | | | | |--> Flow 1 284 Flow 2-->| | | | | | | |--> Flow 2 285 Flow 3-->| |==>| | | |==>| |--> Flow 3 286 Flow 4-->| | ^ | | | | ^ | |--> Flow 4 287 Flow 5-->| | | | | | | | | |--> Flow 5 288 Flow 9 | Rtr1 | | | Rtr2 | | Rtr3 | | | Rtr4 | Flow 9 289 +------+ | +------+ +------+ | +------+ 290 | || || | 291 Aggregate A-->|| Aggregate A ||<--Aggregate A 292 || | || 293 +--------------+ | +--------------+ 294 | |Int 7 | | |Int 1 | | 295 | +----- | V |------+ | 296 | Rtr10 |Int 8 |===========>|Int 2 | Rtr11 | 297 | | |:::::::::::>| | | 298 | +----- | ^ |------+ | 299 | |Int 9 | | |Int 3 | | 300 +--------------+ | +--------------+ 301 .. | .. 302 Aggregate B--->.. Aggregate B ..<---Aggregate B 303 | .. .. | 304 +------+ | +------+ +------+ | +------+ 305 Flow A-->| | | | | | | | | |--> Flow A 306 Flow B-->| | V | | | | V | |--> Flow B 307 Flow C-->| |::>| | | |::>| |--> Flow C 308 Flow D-->| | | | | | | |--> Flow D 309 Flow E-->| Rtr5 | | Rtr6 | | Rtr7 | | Rtr8 |--> Flow E 310 +------+ +------+ +------+ +------+ 311 ^ ^ 312 | | 313 Aggregator of B Deaggregator of B 315 Figure 2. Generic RSVP Aggregate Topology 317 Figure 2 legend/rules: 319 - Aggregate A priority = 100 320 - Aggregate B priority = 200 321 - All boxes are Routers 322 - Both aggregates are shown in the same direction (left to 323 right). Corresponding aggregates in the reverse direction are 324 not shown for diagram simplicity 326 The path for aggregate A is: 328 Rtr1 => Rtr2 => Rtr10 => Rtr11 => Rtr3 => Rtr4 330 where aggregate A starts in Rtr1, and deaggregates in Rtr4. 332 Flows 1, 2, 3, 4, 5 and 9 communicate through aggregate A 334 The path for aggregate B is: 336 Rtr5 ::> Rtr6 ::> Rtr10 ::> Rtr11 ::> Rtr7 ::> Rtr8 338 where aggregate B starts in Rtr5, and deaggregates in Rtr8. 340 Flows A, B, C, D and E communicate through aggregate B 342 Both aggregates share one leg or physical link: between Rtr10 and 343 Rtr11, thus they share one outbound interface: Int8 of Rtr10, where 344 contention of resources may exist. That link has an RSVP capacity 345 of 800kbps. RSVP signaling (messages) is outside this 800kbps in 346 this example, as is any session signaling protocol like SIP. 348 3.1 RSVP Aggregation Reduction Scenario 350 Figure 2 shows an established aggregated reservation (aggregate A) 351 between the routers rtr1 and rtr4. This aggregated reservation 352 consists of 5 microflows (flow 1, 2, 3, 4, 5). For the sake of this 353 discussion, let us assume that each flow represents a voice call and 354 requires 80kb (such as for the codec G.711 with no silence 355 suppression). Aggregate A request is for 400kbps (80kbps * 5 flows). 356 The priority of the aggregate is derived from the individual 357 microflows that it is made up of. In the simple case, all flows of a 358 single priority are bundled as a single aggregate (another priority 359 level would be in another aggregate, even if traversing the same 360 path through the network). There may be other ways in which the 361 priority of the aggregate is derived, but for this discussion it 362 is sufficient to note that each aggregate contains a priority (both 363 hold and defending priority). The means of deriving the priority is 364 out of scope for this discussion. 366 Aggregate B, in Figure 2, consists of flows A, B, C, D and E and 367 requires 400kbps (80kbps * 5 flows), and starts at rtr5 and ends 368 rtr8. This means there are two aggregates occupying all 800kbps of 369 the RSVP capacity. 371 When Flow 9 is added into aggregate A, this will occupy 80kbps more 372 than Int8 on rtr10 has available (880k offered vs. 800k capacity) 373 [1] and [2] create a behavior in RSVP to deny the entire aggregate B 374 and all its individual flows because aggregate A has a higher 375 priority. This situation is where this document focuses its 376 requirements and calls for a solution. There should be some means 377 to signal to all affected routers of aggregate B that only 80kbps is 378 needed to accommodate another (higher priority) aggregate. A 379 solution that accomplishes this reduction instead of a failure 380 could: 382 - reduce significant packet loss of all flows within aggregate B 384 During the re-reservation request period of time no packets will 385 traverse the aggregate until it is reestablished. 387 - reduces the chances that the reestablishment of the aggregate 388 will reserve an inefficient amount of bandwidth, causing the 389 likely preemption of more individual flows at the aggregator 390 than would be necessary had the aggregator had more information 391 (that RSVP does not provide at this time) 393 During reestablishment of the aggregation in Figure 2. (without any 394 modification to RSVP), rtr8 would guess at how much bandwidth to ask 395 for in the new RESV message. It could request too much bandwidth, 396 and have to wait for the error that not that much bandwidth was 397 available; it could request too little bandwidth and have that 398 aggregation accepted, but this would meant that more individual 399 flows would need to be preempted outside the aggregate than were 400 necessary, leading to inefficiencies in the opposite direction. 402 4. Requirements for Reservation Reduction 404 The following are the requirements to reduce the bandwidth of a 405 reservation. This applies to both individual and aggregate 406 reservations: 408 Req#1 - MUST have the ability to differentiate one reservation from 409 another. In the case of aggregates, it MUST distinguish one 410 aggregate from other flows. 412 Req#2 - MUST have the ability to indicate within an RSVP error 413 message (generated at the router with the congested 414 interface) that a specific reservation (individual or 415 aggregate) is to be reduced in bandwidth. 417 Req#3 - MUST have the ability to indicate within the same error 418 message the new maximum amount of bandwidth that is 419 available to be utilized within the existing reservation, 420 but no more. 422 Req#4 - MUST NOT produce a case in which retransmitted reduction 423 indications further reduce the bandwidth of a reservation. 424 Any additional reduction in bandwidth for a specified 425 reservation MUST be signaled in a new message. 427 RSVP messages are unreliable and can get lost. This specification 428 should not compound any error in the network. If a reduction 429 message were lost, another one needs to be sent. If the receiver 430 ends up receiving two copies to reduce the bandwidth of a 431 reservation by some amount, it is likely the router will reduce the 432 bandwidth by twice the amount than was actually called for. This 433 will be in error. 435 5. RSVP Bandwidth Reduction Solution 437 When a reservation is partially failed, a ResvErr (Reservation 438 Error) message is generated just as it is done currently with 439 preemptions. The error spec object and the preemption_pri policy 440 object are included as well. Very few additions/changes are needed 441 to the ResvErr message to support partial preemptions. A new error 442 sub code is required and is defined in section 5.1. The error 443 flowspec contained in the ResvErr message indicates the flowspec 444 that is reserved and this flowspec may not match or be less than the 445 original reservation request. This is defined in section 5.2. 447 A comment about RESV message not using a reliable transport. This 448 document recommends that ResvErr message be made reliable by 449 implementing mechanisms in [6]. 451 The current behavior in RSVP requires a ResvTear message to be 452 transmitted upstream when the ResvErr message is transmitted 453 downstream (per 1). This ResvTear message terminates the 454 reservation in all routers upstream of the router where the failure 455 occurred. This document requires that the ResvTear is only 456 generated when the reservation is to be completely removed. In cases 457 where the reservation is only to be reduced, routers compliant with 458 this specification requires that the ResvTear message MUST NOT be 459 sent. 461 An appendix has been written to walk through the overall solution to 462 the problems presented in sections 2 and 3. There is mention of 463 this ResvTear transmission behavior within the appendix. 465 5.1 Partial Preemption Error Code 467 The ResvErr message generated due to preemption includes the Error 468 Spec object as well as the Preemption Priority Policy object. The 469 format of Error-spec objects is defined in [1]. The error code 470 listed in the ERROR_SPEC object for preemption [5] currently is as 471 follows: 473 Errcode = 2 (Policy Control Failure) and 474 ErrSubCode = 5 (ERR_PREEMPT) 476 The following error code is suggested in the Error_spec object for 477 partial preemption: 479 Errcode = 2 (Policy Control Failure) and 480 ErrSubCode = X (ERR_PARTIAL_PREEMPT) 481 Where 'X' is the number assigned by IANA for this error code 483 There is also an error code in the preemption-pri policy object. 484 This error code takes a value of 1 to indicate that the admitted 485 flow was preempted [3]. The same error value of 1 may be used for 486 the partial preemption case as well. 488 5.2 Error Flow Descriptor 490 The error flow descriptor is defined in [1] & [7]. In the case of 491 partial failure, the flowspec contained in the error flow 492 descriptor indicates the highest average and peak rates that the 493 preempting system can accept in the next RESV message. The 494 deaggregator must reduce its reservation to a number less than or 495 equal to that, whether by changing codecs, by dropping reservations, 496 or some other mechanism. 498 5.3 Individual Reservation Flow Reduction 500 When a router requires part of the bandwidth that has been allocated 501 to a reservation be used for another flow, the router engages in the 502 partial-reduction of bandwidth as described in this document. The 503 router sends a ResvErr downstream to indicate the partial error with 504 the error code and sub code as described in section 5.1. The 505 flowspec contained in the ResvErr message will be used to indicate 506 the bandwidth that is currently allocated. 508 The requesting endpoint that receives the ResvErr can then negotiate 509 with the transmitting endpoint to lower the bandwidth requirement 510 (by selecting another lower bandwidth codec, for example). After the 511 negotiations, both endpoints will issue the RSVP PATH and RESV 512 message with the new, lowered bandwidth. 514 5.4 Aggregation Reduction of Individual Flows 516 When a partial-failure occurs in a aggregation scenario, the 517 deaggregator receives the ResvErr message with the reduction 518 indication from a router in the path of the aggregate. It then 519 decides whether one or more individual flows from the aggregate are 520 to be affected by this ResvErr message. The following choices are 521 possible: 523 o If that (deaggregator) router determines one or more individual 524 flow(s) are to partially failed, then it sends a ResvErr message 525 with a reduced bandwidth indication to those individual flow(s). 526 This is as per the descriptions in the previous section (5.3). 528 o If that (deaggregator) router determines one individual flow is to 529 be preempted to satisfy the aggregate ResvErr, it determines which 530 flow is affected. That router transmits a new ResvErr message 531 downstream per [3]. That same router transmits a ResvTear message 532 upstream. This ResvTear message of an individual flow does not 533 tear down the aggregate. Only the individual flow is affected. 535 o If that (deaggregator) router determines multiple individual flows 536 are to be preempted to satisfy the aggregate ResvErr, it chooses 537 which flows are affected. That router transmits a new ResvErr 538 message downstream as per [3] to each individual flow. The router 539 also transmits ResvTear messages upstream for the same individual 540 flows. These ResvTear messages of an individual flow do not tear 541 down the aggregate. Only the individual flows are affected. 543 In all cases, the Deaggregator lowers the bandwidth requested in the 544 Aggregate Resv message to reflect the change. 546 Which particular flow or series of flows within an aggregate are 547 picked by the deaggregator for bandwidth reduction or preemption is 548 outside the scope of this document. 550 5.5 RSVP Flow Reduction involving IPsec Tunnels 552 RFC 2207 (per [8]) specifies how RSVP reservations function in IPsec 553 data flows. The nodes initiating the IPsec flow can be an end- 554 system like a computer, or it can router between two end-systems, or 555 it can be an in-line bulk encryption device immediately adjacent to 556 a router interface, [11] directly addresses this later scenario. 558 The methods of identification of an IPsec with reservation flow are 559 different than non-encrypted flows, but how the reduction mechanism 560 specified within this document functions is not. 562 An IPsec with reservation flow is, for all intents and purposes, 563 considered an individual flow with regard to how to reduce the 564 bandwidth of the flow. Obviously an IPsec with reservation flow can 565 be a series of individual flows or disjointed best effort packets 566 between two systems. But to this specification, this tunnel is an 567 individual RSVP reservation. 569 Anywhere within this specification that mentions an individual 570 reservation flow, the same rules of bandwidth reduction and 571 preemption MUST apply. 573 6. Backwards Compatibility 575 Backwards compatibility with this extension will result in RSVP 576 operating as it does without this extension, and no worse. The two 577 routers involved in this extension are the router that had the 578 congested interface and the furthest downstream router that 579 determines what to do with the reduction indication. 581 In the case of the router that experiences congestion or otherwise 582 needs to reduce the bandwidth of an existing reservation: 584 - If that router supports this extension: 586 #1 - it generates the ResvErr message with the error code 587 indicating the reduction in bandwidth 589 #2 - it does not generate the ResvTear message 591 - If that router does not support this extension, it generates both 592 ResvErr and ResvTear messages according to [1]. 594 In the case of the router at the extreme downstream of a reservation 595 that receives the ResvErr message with the reduction indication 597 - If that router does support this extension: 599 #1 - it processes this error message and applies whatever local 600 policy it is configured to do to determine how to reduce the 601 bandwidth of this designated flow 603 - If the router does not support this extension: 605 #1 - it processes the ResvErr message according to [1] and all 606 extensions it is able to understand, but not this extension 607 from this document. 609 Thus, this extension does not cause ill effects within RSVP if one 610 or more routers support this extension, and one or more routers do 611 not support this extension. 613 7. Security Considerations 615 This document does not lessen the overall security of RSVP or of 616 reservation flows through an aggregate. 618 If this specification is implemented poorly - which is never 619 intended, but is a consideration - the following issue may arise: 621 1) If the ResvTear messages are transmitted initially (at the same 622 time as the ResvErr messages indicating a reduction in bandwidth 623 is necessary), all upstream routers will tear down the entire 624 reservation. This will free up the total amount of bandwidth of 625 this reservation inadvertently. This may cause the re- 626 establishment of an otherwise good reservation to fail. This has 627 the most severe affects on an aggregate that has many individual 628 flows that would have remained operational. 630 8. IANA Considerations 632 IANA is to assign the following from RFC [XXXX] (this document): 634 The following error code is to be defined in the Error_spec object 635 for partial reservation failure under "Errcode = 2 (Policy Control 636 Failure)": 638 ErrSubCode = X (ERR_PARTIAL_PREEMPT) 640 Where 'X' is assigned by IANA for this error code 642 The behavior of this ErrSubCode is defined in this document. 644 9. Acknowledgements 646 The authors would like to thank Fred Baker for contributing text and 647 guidance in this effort and to Roger Levesque and Francois Le 648 Faucheur for helpful comments. 650 Appendix 1. Walking Through the Solution 652 Here is a concise explanation of roughly how RSVP behaves with the 653 solution to the problems presented in sections 2 & 3 of this 654 document. There is no normative text in this appendix. 656 Here is a duplicate of Figure 2 from section 3 of the document body 657 (to bring it closer to the detailed description of the solution). 659 Aggregator of A Deaggregator of A 660 | | 661 V V 662 +------+ +------+ +------+ +------+ 663 Flow 1-->| | | | | | | |--> Flow 1 664 Flow 2-->| | | | | | | |--> Flow 2 665 Flow 3-->| |==>| | | |==>| |--> Flow 3 666 Flow 4-->| | ^ | | | | ^ | |--> Flow 4 667 Flow 5-->| | | | | | | | | |--> Flow 5 668 Flow 9-->| Rtr1 | | | Rtr2 | | Rtr3 | | | Rtr4 |--> Flow 9 669 +------+ | +------+ +------+ | +------+ 670 | || || | 671 Aggregate A--->|| Aggregate A ||<--Aggregate A 672 || | || 673 +--------------+ | +--------------+ 674 | |Int 7 | | |Int 1 | | 675 | +----- | V |------+ | 676 | Rtr10 |Int 8 |===========>|Int 2 | Rtr11 | 677 | | |:::::::::::>| | | 678 | +----- | ^ |------+ | 679 | |Int 9 | | |Int 3 | | 680 +--------------+ | +--------------+ 681 .. | .. 682 Aggregate B--->.. Aggregate B ..<---Aggregate B 683 | .. .. | 684 +------+ | +------+ +------+ | +------+ 685 Flow A-->| | | | | | | | | |--> Flow A 686 Flow B-->| | V | | | | V | |--> Flow B 687 Flow C-->| |::>| | | |::>| |--> Flow C 688 Flow D-->| | | | | | | |--> Flow D 689 Flow E-->| Rtr5 | | Rtr6 | | Rtr7 | | Rtr8 |--> Flow E 690 +------+ +------+ +------+ +------+ 691 ^ ^ 692 | | 693 Aggregator of B Deaggregator of B 695 Duplicate of Figure 2. Generic RSVP Aggregate Topology 697 Looking at Figure 2., aggregate A (with five 80kbps flows) 698 traverses: 700 Rtr1 ==> Rtr2 ==> Rtr10 ==> Rtr11 ==> Rtr3 ==> Rtr4 702 And aggregate B (with five 80kbps flows) traverses: 704 Rtr5 ::> Rtr6 ::> Rtr10 ::> Rtr11 ::> Rtr7 ::> Rtr8 706 Both aggregates are 400kbps. This totals 800kbps at Interface-7 in 707 Rtr10, which is the maximum bandwidth RSVP has access to at this 708 interface. Signaling messages still traverse the interface without 709 problem. Aggregate A is at a higher relative priority than 710 aggregate B. Local policy in this example is for higher relative 711 priority flows to preempt lower priority flows during times of 712 congestion. The following points describe the flow when aggregate A 713 is increased to include flow 9. 715 o When flow 9 (at 80kbps) is added to aggregate A, Rtr1 will 716 initiate the PATH message towards the destination endpoint of 717 the flow. This hop-by-hop message will take it through Rtr2, 718 Rtr10, Rtr11, Rtr3 and Rtr4 which is the aggregate A path (that 719 was built per [2] from the aggregate's initial set up) to the 720 endpoint node. 722 o In response, Rtr4 will generate the RESV (reservation) message 723 [defined behavior per 1]. This RESV from the deaggregator 724 indicates an increase bandwidth sufficient to accommodate the 725 existing 5 flows (1,2,3,4,5) and the new flow (9) [as stated in 726 2]. 728 o As mentioned before, in this example, Int8 in RTR 10 can only 729 accommodate 800kbps, and aggregates A and B have each already 730 established 400kbps flows comprised of five 80kbps individual 731 flows. Therefore, Rtr10 (the interface that detects a congestion 732 event in this example) must make a decision about this new 733 congestion generating condition in regard to the RESV message 734 received at Int8. 736 o Local Policy in this scenario is to preempt lower priority 737 reservations to place higher priority reservations. This would 738 normally cause all of aggregate B to be preempted just to 739 accommodate aggregate A's request for an additional 80kbps. 741 o This document defines how aggregate B is not completely 742 preempted, but reduced in bandwidth by 80kbps. This is 743 contained in the ResvErr message that Rtr10 generates 744 (downstream) towards Rtr11, Rtr7 and Rtr8. See section 5 for 745 the details of the error message. 747 o Normal operation of RSVP is to have the router that generates a 748 ResvErr message downstream to also generate a ResvTear message 749 upstream (in the opposite direction towards Rtr5). The ResvTear 750 message terminates an individual flow or aggregate flow. This 751 document calls for that message to not be sent on any partial 752 failure of reservation. 754 o Rtr8 is the deaggregator of aggregate B. The deaggregator 755 controls all the parameters of an aggregate reservation. This 756 will be the node that reduces the necessary bandwidth of the 757 aggregate as a response to the reception of an ResvErr message 758 (from Rtr10) indicating such an action is called for. In this 759 example, bandwidth reduction is accomplished by preempting an 760 individual flow within the aggregate (perhaps picking on Flow D 761 for individual preemption by generating a ResvErr downstream on 762 that individual flow). 764 o At the same time, a ResvTear message is transmitted upstream on 765 that individual flow (Flow D) by Rtr8. This will not affect the 766 aggregate directly, but is an indication to the routers (and the 767 source end-system) which individual flow is to be preempted. 769 o Once Rtr8 preempts whichever individual flow (or 'bandwidth' at 770 the aggregate ingress), it transmits a new RESV message for that 771 aggregate (B), not for a new aggregate. This RESV from the 772 deaggregator indicates an decrease in bandwidth sufficient to 773 accommodate the remaining 4 flows (A,B,C,E), which is now 774 320kbps (in this example). 776 o This RESV message travels the entire path of the reservation, 777 resetting all routers to this new aggregate bandwidth value. 778 This should be what is necessary to prevent a ResvTear message 779 from being generated by Rtr10 towards Rtr6 and Rtr5. 781 Rtr5 will not know through this RESV message which individual flow 782 was preempted. If in this example, Rtr8 was given more bandwidth to 783 keep, it might have transmitted a bandwidth reduction ResvErr 784 indication towards the end-system of Flow D. In that case, a voice 785 signaling protocol (such as SIP) could have attempted a 786 renegotiation of that individual flow to a reduced bandwidth (say, 787 but changing the voice codec from G.711 to G. 729). This could have 788 saved Flow D from preemption. 790 10. References 792 10.1 Normative References 794 [1] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 795 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 796 Specification", RFC 2205, September 1997 798 [2] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of 799 RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001 801 [3] S. Herzog, "Signaled Preemption Priority Policy Element", RFC 802 3181, October 2001 804 [4] Bradner S., "Key words for use in RFCs to Indicate Requirement 805 Levels", RFC 2119, March 1997 807 [5] S. Herzog, "RSVP Extensions for Policy Control", RFC 2750, 808 January 2000 810 [6] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini, 811 "RSVP Refresh Overhead Reduction Extensions" RFC 2961, April 2001 813 [7] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", 814 RFC 2210, September 1997 816 [8] L. Berger, T. O'Malley, "RSVP Extensions for IPSEC Data Flows", 817 RFC 2207, September 1997 819 10.2 Informational References 821 [9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, 822 J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 823 Session Initiation Protocol", RFC 3261, May 2002. 825 [10] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit 826 Congestion Notification (ECN) to IP", RFC 3168, September 2001 828 [11] F. Le Faucheur, B. Davie, P. Bose, C. Christou, " Aggregate 829 reservations for IPsec Tunnel", draft-lefaucheur-rsvp-ipsec-00, 830 February 2005, "work in progress" 832 11. Author Information 834 James M. Polk 835 Cisco Systems 836 2200 East President George Bush Turnpike 837 Richardson, Texas 75082 USA 839 Email: jmpolk@cisco.com 841 Subha Dhesikan 842 Cisco Systems 843 170 W. Tasman Drive 844 San Jose, CA 95134 USA 846 Email: sdhesika@cisco.com 848 Intellectual Property Statement 850 The IETF takes no position regarding the validity or scope of any 851 Intellectual Property Rights or other rights that might be claimed 852 to pertain to the implementation or use of the technology described 853 in this document or the extent to which any license under such 854 rights might or might not be available; nor does it represent that 855 it has made any independent effort to identify any such rights. 856 Information on the procedures with respect to rights in RFC 857 documents can be found in BCP 78 and BCP 79. 859 Copies of IPR disclosures made to the IETF Secretariat and any 860 assurances of licenses to be made available, or the result of an 861 attempt made to obtain a general license or permission for the use 862 of such proprietary rights by implementers or users of this 863 specification can be obtained from the IETF on-line IPR repository 864 at http://www.ietf.org/ipr. 866 The IETF invites any interested party to bring to its attention any 867 copyrights, patents or patent applications, or other proprietary 868 rights that may cover technology that may be required to implement 869 this standard. Please address the information to the IETF at 870 ietf-ipr@ietf.org. 872 Disclaimer of Validity 874 This document and the information contained herein are provided on 875 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 876 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 877 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 878 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 879 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 880 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 882 Copyright Statement 884 Copyright (C) The Internet Society (2005). This document is subject 885 to the rights, licenses and restrictions contained in BCP 78, and 886 except as set forth therein, the authors retain all their rights. 888 Acknowledgment 890 Funding for the RFC Editor function is currently provided by the 891 Internet Society. 893 The Expiration date for this Internet Draft is: 895 August 10th, 2005