--- 1/draft-ietf-tsvwg-rsvp-bw-reduction-01.txt 2006-02-04 17:03:02.000000000 +0100 +++ 2/draft-ietf-tsvwg-rsvp-bw-reduction-02.txt 2006-02-04 17:03:02.000000000 +0100 @@ -1,15 +1,15 @@ Transport Area Working Group James Polk Internet Draft Subha Dhesikan -Expiration: March 8th, 2005 Cisco Systems -File: draft-ietf-tsvwg-rsvp-bw-reduction-01.txt September 8th, 2005 +Expiration: July 24th, 2005 Cisco Systems +File: draft-ietf-tsvwg-rsvp-bw-reduction-02.txt January 24th, 2005 A Resource Reservation Protocol Extension for the Reduction of Bandwidth of a Reservation Flow Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. @@ -23,58 +23,58 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 8th, 2006. + This Internet-Draft will expire on July 24th, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). All Rights Reserved. + Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations or other forms of RSVP tunnels. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2 Changes From Previous Versions . . . . . . . . . . . . . 4 - 2. Individual Reservation Reduction Scenario . . . . . . . . . . 5 - 3. RSVP Aggregation Overview . . . . . . . . . . . . . . . . . . 6 - 3.1 RSVP Aggregation Reduction Scenario . . . . . . . . . . . 8 - 4. Requirements for Reservation Reduction . . . . . . . . . . . 9 - 5. RSVP Bandwidth Reduction Solution . . . . . . . . . . . . . . 10 - 5.1 Partial Preemption Error Code . . . . . . . . . . . . . 10 - 5.2 Error Flow Descriptor . . . . . . . . . . . . . . . . . 11 - 5.3 Individual Reservation Flow Reduction . . . . . . . . . 11 - 5.4 Aggregation Reduction of Individual Flows . . . . . . . 11 - 5.5 RSVP Flow Reduction involving IPsec Tunnels . . . . . . 12 + 2. Individual Reservation Reduction Scenario . . . . . . . . . . 4 + 3. RSVP Aggregation Overview . . . . . . . . . . . . . . . . . . 5 + 3.1 RSVP Aggregation Reduction Scenario . . . . . . . . . . . 7 + 4. Requirements for Reservation Reduction . . . . . . . . . . . 8 + 5. RSVP Bandwidth Reduction Solution . . . . . . . . . . . . . . 9 + 5.1 Partial Preemption Error Code . . . . . . . . . . . . . 9 + 5.2 Error Flow Descriptor . . . . . . . . . . . . . . . . . 10 + 5.3 Individual Reservation Flow Reduction . . . . . . . . . 10 + 5.4 Aggregation Reduction of Individual Flows . . . . . . . 10 + 5.5 RSVP Flow Reduction involving IPSec Tunnels . . . . . . 11 + 5.6 Reduction of Multiple Flows At Once . . . . . . . . . . 11 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 - 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 - Appendix. Walking Through the Solution . . . . . . . . . . . . . 14 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1 Normative References . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 12 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 + Appendix. Walking Through the Solution . . . . . . . . . . . . . 13 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 10.1 Normative References . . . . . . . . . . . . . . . . . . 16 10.2 Informational References . . . . . . . . . . . . . . . . 17 - 11. Author Information . . . . . . . . . . . . . . . . . . . . . 18 + Author Information . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document proposes an extension to the Resource Reservation Protocol (RSVP) [1] to allow an existing reservation to be reduced in allocated bandwidth in lieu of tearing that reservation down when some of that reservation's bandwidth is needed for other purposes. Several examples exist in which this mechanism may be utilized. The bandwidth allotted to an individual reservation may be reduced @@ -101,23 +101,23 @@ terminate all the individual flows if an aggregate is torn down, this event will cause packets to be discarded during aggregate reservation reestablishment. This document describes a method where only the minimum required bandwidth is taken away from the lower- priority aggregated reservation and the entire reservation is not preempted. This has the advantage that only some of the microflows making up the aggregate are affected. Without this extension, all individual flows are affected and the deaggregator will have to attempt the reservation request with a reduced bandwidth. - RSVP tunnels utilizing IPsec [8] also require an indication that + RSVP tunnels utilizing IPSec [8] also require an indication that the reservation must be reduced to a certain amount (or less). RSVP - aggregation with IPsec Tunnels is being defined in [11], which + aggregation with IPSec Tunnels is being defined in [11], which should be able to take advantage of the mechanism created here in this specification. Note that when this document refers to a router interface being "full" or "at capacity", this does not imply that all of the bandwidth has been used, but rather that all of the bandwidth available for reservation(s) via RSVP under the applicable policy has been used. Policies for real-time traffic routinely reserve capacity for routing and inelastic applications, and may distinguish between voice, video, and other real time applications. @@ -143,68 +143,33 @@ This document is intended to be classified as an 'update' to RFC 2205 [1], as this mechanism affects the behaviors of the ResvErr and ResvTear indications defined in that document. 1.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. -1.2 Changes from previous versions - - This is a listing of the changes that have taken place to this - Internet Draft since the previous version: - - o Changed the filename to reflect this now being a Working Group - item within the TSVWG - - o Added a informative reference to the new Internet Draft involving - Aggregates inside IPsec tunnels that use RSVP - - o Made minor editorial changes to make document more concise - - o Added a new section 6 on Backwards Compatibility - - This is a listing of the changes that have taken place to this - Internet Draft since from the Aggregation only version to the - Reservation version: - - o Changed the filename to remove "aggregation" as the focus of the - draft to open up this solution to a wider applicability - - o Reduced text in the introductory section to be more succinct - - o Added the use-case for this mechanism with individual reservations - - o Added the use-case for this mechanism with reservations of - individual IPsec data flows - - o Opened up the text in the document body for this wider - applicability - - o Mentioned why ECN is inappropriate for reducing bandwidth - allocations of RSVP reservations. - 2. Individual Reservation Reduction Scenario Figure 1 is a network topology that is used to describe the benefit of bandwidth reduction in an individual reservation. - +--------------+ +--------------+ + +------------+ +------------+ | |Int 1 | |Int 7 | | Flow 1===> | +----- | |------+ | Flow 1===> - | Rtr1 |Int 2 |===========>|Int 8 | Rtr2 | + | R1 |Int 2 |===========>|Int 8 | R2 | | | |:::::::::::>| | | Flow 2:::> | +----- | |------+ | Flow 2:::> | |Int 3 | |Int 9 | | - +--------------+ +--------------+ + +------------+ +------------+ Figure 1. Simple Reservation Flows Figure 1. Legend/Rules: - Flow 1 priority = 300 - Flow 2 priority = 100 - Both flows are shown in the same direction (left to right). Corresponding flows in the reverse direction are not shown for diagram simplicity @@ -212,32 +177,31 @@ RSVP is a reservation establishment protocol in one direction only. This split path philosophy is because the routed path from one device to the other in one direction might not be the routed path for communicating between the same two endpoints in the reverse direction. End-systems must request 2 one-way reservations if that is what is needed for a particular application (like voice calls). Please refer to [1] for the details on how this functions. This example only describes the reservation scenario in one direction for simplicity sake. - Figure 1. depicts 2 routers, (Rtr1 and Rtr2) initially with only one - flow (Flow 1). The flows are forwarded from Rtr1 to Rtr2 via + Figure 1. depicts 2 routers, (R1 and R2) initially with only one + flow (Flow 1). The flows are forwarded from R1 to R2 via interface 2. For this example, let us say that flow 1 and flow 2 each require 80 units of bandwidth (such as for the codec G.711 with no silence suppression). Let us also say that the RSVP bandwidth - limit for interface 2 of Rtr1 is 100 units. + limit for interface 2 of R1 is 100 units. As described in [3], a priority indication is established for each flow. In fact, there are two priority indications: 1) one to establish the reservation, and - 2) one to defend the reservation. In this example, flow 1 and flow 2 have an 'establishing' and a 'defending' priority of 300 and 100 respectively. Flow 2 will have a higher establishing priority than flow 1 has for its defending priority. This means that when flow 2 is signaled, and if no bandwidth is available at the interface, flow 1 will have to relinquish bandwidth in favor of the higher priority request of flow 2. The priorities assigned to a reservation are always end-to-end, and not altered by any routers in transit. @@ -262,143 +226,144 @@ flow 1 is established with much less than what is available then it leads to inefficient use of available bandwidth. 3. RSVP Aggregation Overview The following network overview is to help visualize the concerns that this specification addresses in RSVP Aggregates. Figure 2 consists of 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9, A, B, C, D, and E). Initially there will 5 flows per aggregate (flow 9 will be introduced to cause the problem we are addressing in - this document),with 2 aggregates (A & B); (1 through 5) in aggregate - A and (A through E) in aggregate B. These 2 aggregates will cross + this document),with 2 aggregates (X & Y); (1 through 5) in aggregate + X and (A through E) in aggregate Y. These 2 aggregates will cross one router interface utilizing all available capacity (in this example). RSVP aggregation [per 2] is no different from an individual reservation with respect to being unidirectional. - Aggregator of A Deaggregator of A + Aggregator of X Deaggregator of X | | V V +------+ +------+ +------+ +------+ Flow 1-->| | | | | | | |--> Flow 1 Flow 2-->| | | | | | | |--> Flow 2 Flow 3-->| |==>| | | |==>| |--> Flow 3 Flow 4-->| | ^ | | | | ^ | |--> Flow 4 Flow 5-->| | | | | | | | | |--> Flow 5 - Flow 9 | Rtr1 | | | Rtr2 | | Rtr3 | | | Rtr4 | Flow 9 + Flow 9 | R1 | | | R2 | | R3 | | | R4 | Flow 9 +------+ | +------+ +------+ | +------+ | || || | - Aggregate A-->|| Aggregate A ||<--Aggregate A + Aggregate X-->|| Aggregate X ||<--Aggregate X || | || +--------------+ | +--------------+ | |Int 7 | | |Int 1 | | | +----- | V |------+ | - | Rtr10 |Int 8 |===========>|Int 2 | Rtr11 | + | R10 |Int 8 |===========>|Int 2 | R11 | | | |:::::::::::>| | | | +----- | ^ |------+ | | |Int 9 | | |Int 3 | | +--------------+ | +--------------+ .. | .. - Aggregate B--->.. Aggregate B ..<---Aggregate B + Aggregate Y--->.. Aggregate Y ..<---Aggregate Y | .. .. | +------+ | +------+ +------+ | +------+ Flow A-->| | | | | | | | | |--> Flow A Flow B-->| | V | | | | V | |--> Flow B Flow C-->| |::>| | | |::>| |--> Flow C Flow D-->| | | | | | | |--> Flow D - Flow E-->| Rtr5 | | Rtr6 | | Rtr7 | | Rtr8 |--> Flow E + Flow E-->| R5 | | R6 | | R7 | | R8 |--> Flow E +------+ +------+ +------+ +------+ ^ ^ | | - Aggregator of B Deaggregator of B + Aggregator of Y Deaggregator of Y Figure 2. Generic RSVP Aggregate Topology Figure 2 legend/rules: - - Aggregate A priority = 100 - - Aggregate B priority = 200 + - Aggregate X priority = 100 + - Aggregate Y priority = 200 - All boxes are Routers - Both aggregates are shown in the same direction (left to right). Corresponding aggregates in the reverse direction are not shown for diagram simplicity - The path for aggregate A is: + The path for aggregate X is: - Rtr1 => Rtr2 => Rtr10 => Rtr11 => Rtr3 => Rtr4 - where aggregate A starts in Rtr1, and deaggregates in Rtr4. + R1 => R2 => R10 => R11 => R3 => R4 + + where aggregate X starts in R1, and deaggregates in R4. Flows 1, 2, 3, 4, 5 and 9 communicate through aggregate A - The path for aggregate B is: + The path for aggregate Y is: - Rtr5 ::> Rtr6 ::> Rtr10 ::> Rtr11 ::> Rtr7 ::> Rtr8 + R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8 - where aggregate B starts in Rtr5, and deaggregates in Rtr8. + where aggregate Y starts in R5, and deaggregates in R8. Flows A, B, C, D and E communicate through aggregate B - Both aggregates share one leg or physical link: between Rtr10 and - Rtr11, thus they share one outbound interface: Int8 of Rtr10, where + Both aggregates share one leg or physical link: between R10 and + R11, thus they share one outbound interface: Int8 of R10, where contention of resources may exist. That link has an RSVP capacity of 800kbps. RSVP signaling (messages) is outside this 800kbps in this example, as is any session signaling protocol like SIP. 3.1 RSVP Aggregation Reduction Scenario - Figure 2 shows an established aggregated reservation (aggregate A) - between the routers rtr1 and rtr4. This aggregated reservation + Figure 2 shows an established aggregated reservation (aggregate X) + between the routers R1 and R4. This aggregated reservation consists of 5 microflows (flow 1, 2, 3, 4, 5). For the sake of this discussion, let us assume that each flow represents a voice call and requires 80kb (such as for the codec G.711 with no silence - suppression). Aggregate A request is for 400kbps (80kbps * 5 flows). + suppression). Aggregate X request is for 400kbps (80kbps * 5 flows). The priority of the aggregate is derived from the individual microflows that it is made up of. In the simple case, all flows of a single priority are bundled as a single aggregate (another priority level would be in another aggregate, even if traversing the same path through the network). There may be other ways in which the priority of the aggregate is derived, but for this discussion it is sufficient to note that each aggregate contains a priority (both hold and defending priority). The means of deriving the priority is out of scope for this discussion. - Aggregate B, in Figure 2, consists of flows A, B, C, D and E and - requires 400kbps (80kbps * 5 flows), and starts at rtr5 and ends - rtr8. This means there are two aggregates occupying all 800kbps of + Aggregate Y, in Figure 2, consists of flows A, B, C, D and E and + requires 400kbps (80kbps * 5 flows), and starts at R5 and ends + R8. This means there are two aggregates occupying all 800kbps of the RSVP capacity. - When Flow 9 is added into aggregate A, this will occupy 80kbps more - than Int8 on rtr10 has available (880k offered vs. 800k capacity) - [1] and [2] create a behavior in RSVP to deny the entire aggregate B - and all its individual flows because aggregate A has a higher + When Flow 9 is added into aggregate X, this will occupy 80kbps more + than Int8 on R10 has available (880k offered load vs. 800k capacity) + [1] and [2] create a behavior in RSVP to deny the entire aggregate Y + and all its individual flows because aggregate X has a higher priority. This situation is where this document focuses its requirements and calls for a solution. There should be some means - to signal to all affected routers of aggregate B that only 80kbps is + to signal to all affected routers of aggregate Y that only 80kbps is needed to accommodate another (higher priority) aggregate. A solution that accomplishes this reduction instead of a failure could: - - reduce significant packet loss of all flows within aggregate B + - reduce significant packet loss of all flows within aggregate Y During the re-reservation request period of time no packets will traverse the aggregate until it is reestablished. - reduces the chances that the reestablishment of the aggregate will reserve an inefficient amount of bandwidth, causing the likely preemption of more individual flows at the aggregator than would be necessary had the aggregator had more information (that RSVP does not provide at this time) During reestablishment of the aggregation in Figure 2. (without any - modification to RSVP), rtr8 would guess at how much bandwidth to ask + modification to RSVP), R8 would guess at how much bandwidth to ask for in the new RESV message. It could request too much bandwidth, and have to wait for the error that not that much bandwidth was available; it could request too little bandwidth and have that aggregation accepted, but this would meant that more individual flows would need to be preempted outside the aggregate than were necessary, leading to inefficiencies in the opposite direction. 4. Requirements for Reservation Reduction The following are the requirements to reduce the bandwidth of a @@ -471,22 +436,22 @@ follows: Errcode = 2 (Policy Control Failure) and ErrSubCode = 5 (ERR_PREEMPT) The following error code is suggested in the Error_spec object for partial preemption: Errcode = 2 (Policy Control Failure) and ErrSubCode = X (ERR_PARTIAL_PREEMPT) - Where 'X' is the number assigned by IANA for this error code + Where 'X' is the number assigned by IANA for this error code There is also an error code in the preemption-pri policy object. This error code takes a value of 1 to indicate that the admitted flow was preempted [3]. The same error value of 1 may be used for the partial preemption case as well. 5.2 Error Flow Descriptor The error flow descriptor is defined in [1] & [7]. In the case of partial failure, the flowspec contained in the error flow descriptor indicates the highest average and peak rates that the @@ -540,43 +505,54 @@ flows. These ResvTear messages of an individual flow do not tear down the aggregate. Only the individual flows are affected. In all cases, the Deaggregator lowers the bandwidth requested in the Aggregate Resv message to reflect the change. Which particular flow or series of flows within an aggregate are picked by the deaggregator for bandwidth reduction or preemption is outside the scope of this document. -5.5 RSVP Flow Reduction involving IPsec Tunnels +5.5 RSVP Flow Reduction involving IPSec Tunnels - RFC 2207 (per [8]) specifies how RSVP reservations function in IPsec - data flows. The nodes initiating the IPsec flow can be an end- + RFC 2207 (per [8]) specifies how RSVP reservations function in IPSec + data flows. The nodes initiating the IPSec flow can be an end- system like a computer, or it can router between two end-systems, or it can be an in-line bulk encryption device immediately adjacent to a router interface, [11] directly addresses this later scenario. - The methods of identification of an IPsec with reservation flow are + The methods of identification of an IPSec with reservation flow are different than non-encrypted flows, but how the reduction mechanism specified within this document functions is not. - An IPsec with reservation flow is, for all intents and purposes, + An IPSec with reservation flow is, for all intents and purposes, considered an individual flow with regard to how to reduce the - bandwidth of the flow. Obviously an IPsec with reservation flow can + bandwidth of the flow. Obviously an IPSec with reservation flow can be a series of individual flows or disjointed best effort packets between two systems. But to this specification, this tunnel is an individual RSVP reservation. Anywhere within this specification that mentions an individual reservation flow, the same rules of bandwidth reduction and preemption MUST apply. +5.6 Reduction of Multiple Flows at Once + + As a cautionary note, bandwidth SHOULD NOT be reduced across + multiple reservations at the same time, in reaction to the same + reduction event. A router not knowing the impact of reservation + bandwidth reduction on more than one flow may cause more wide spread + ill effects than is necessary. + + This says nothing to a policy where preemption should or should not + occur across multiple flows. + 6. Backwards Compatibility Backwards compatibility with this extension will result in RSVP operating as it does without this extension, and no worse. The two routers involved in this extension are the router that had the congested interface and the furthest downstream router that determines what to do with the reduction indication. In the case of the router that experiences congestion or otherwise needs to reduce the bandwidth of an existing reservation: @@ -609,34 +585,40 @@ Thus, this extension does not cause ill effects within RSVP if one or more routers support this extension, and one or more routers do not support this extension. 7. Security Considerations This document does not lessen the overall security of RSVP or of reservation flows through an aggregate. If this specification is implemented poorly - which is never - intended, but is a consideration - the following issue may arise: + intended, but is a consideration - the following issues may arise: 1) If the ResvTear messages are transmitted initially (at the same time as the ResvErr messages indicating a reduction in bandwidth is necessary), all upstream routers will tear down the entire reservation. This will free up the total amount of bandwidth of this reservation inadvertently. This may cause the re- establishment of an otherwise good reservation to fail. This has the most severe affects on an aggregate that has many individual flows that would have remained operational. + 2) Just as RSVP has the vulnerability of premature termination of + valid reservations by rouge flows without authentication + [12 & 13], this mechanism will have the same vulnerability. + Usage of RSVP authentication mechanisms is encouraged. + 8. IANA Considerations - IANA is to assign the following from RFC [XXXX] (this document): + IANA is to assign the following from RFC [XXXX] (i.e. this + document): The following error code is to be defined in the Error_spec object for partial reservation failure under "Errcode = 2 (Policy Control Failure)": ErrSubCode = X (ERR_PARTIAL_PREEMPT) Where 'X' is assigned by IANA for this error code The behavior of this ErrSubCode is defined in this document. @@ -649,144 +631,144 @@ Appendix 1. Walking Through the Solution Here is a concise explanation of roughly how RSVP behaves with the solution to the problems presented in sections 2 & 3 of this document. There is no normative text in this appendix. Here is a duplicate of Figure 2 from section 3 of the document body (to bring it closer to the detailed description of the solution). - Aggregator of A Deaggregator of A + Aggregator of X Deaggregator of X | | V V +------+ +------+ +------+ +------+ Flow 1-->| | | | | | | |--> Flow 1 Flow 2-->| | | | | | | |--> Flow 2 Flow 3-->| |==>| | | |==>| |--> Flow 3 Flow 4-->| | ^ | | | | ^ | |--> Flow 4 Flow 5-->| | | | | | | | | |--> Flow 5 - Flow 9-->| Rtr1 | | | Rtr2 | | Rtr3 | | | Rtr4 |--> Flow 9 + Flow 9-->| R1 | | | R2 | | R3 | | | R4 |--> Flow 9 +------+ | +------+ +------+ | +------+ | || || | - Aggregate A--->|| Aggregate A ||<--Aggregate A + Aggregate X--->|| Aggregate X ||<--Aggregate X || | || +--------------+ | +--------------+ | |Int 7 | | |Int 1 | | | +----- | V |------+ | - | Rtr10 |Int 8 |===========>|Int 2 | Rtr11 | + | R10 |Int 8 |===========>|Int 2 | R11 | | | |:::::::::::>| | | | +----- | ^ |------+ | | |Int 9 | | |Int 3 | | +--------------+ | +--------------+ .. | .. - Aggregate B--->.. Aggregate B ..<---Aggregate B + Aggregate Y--->.. Aggregate Y ..<---Aggregate Y | .. .. | +------+ | +------+ +------+ | +------+ Flow A-->| | | | | | | | | |--> Flow A Flow B-->| | V | | | | V | |--> Flow B Flow C-->| |::>| | | |::>| |--> Flow C Flow D-->| | | | | | | |--> Flow D - Flow E-->| Rtr5 | | Rtr6 | | Rtr7 | | Rtr8 |--> Flow E + Flow E-->| R5 | | R6 | | R7 | | R8 |--> Flow E +------+ +------+ +------+ +------+ ^ ^ | | - Aggregator of B Deaggregator of B + Aggregator of Y Deaggregator of Y Duplicate of Figure 2. Generic RSVP Aggregate Topology - Looking at Figure 2., aggregate A (with five 80kbps flows) + Looking at Figure 2., aggregate X (with five 80kbps flows) traverses: - Rtr1 ==> Rtr2 ==> Rtr10 ==> Rtr11 ==> Rtr3 ==> Rtr4 + R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4 - And aggregate B (with five 80kbps flows) traverses: + And aggregate Y (with five 80kbps flows) traverses: - Rtr5 ::> Rtr6 ::> Rtr10 ::> Rtr11 ::> Rtr7 ::> Rtr8 + R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8 Both aggregates are 400kbps. This totals 800kbps at Interface-7 in - Rtr10, which is the maximum bandwidth RSVP has access to at this + R10, which is the maximum bandwidth RSVP has access to at this interface. Signaling messages still traverse the interface without - problem. Aggregate A is at a higher relative priority than - aggregate B. Local policy in this example is for higher relative + problem. Aggregate X is at a higher relative priority than + aggregate Y. Local policy in this example is for higher relative priority flows to preempt lower priority flows during times of congestion. The following points describe the flow when aggregate A is increased to include flow 9. - o When flow 9 (at 80kbps) is added to aggregate A, Rtr1 will + o When flow 9 (at 80kbps) is added to aggregate X, R1 will initiate the PATH message towards the destination endpoint of - the flow. This hop-by-hop message will take it through Rtr2, - Rtr10, Rtr11, Rtr3 and Rtr4 which is the aggregate A path (that + the flow. This hop-by-hop message will take it through R2, + R10, R11, R3 and R4 which is the aggregate X path (that was built per [2] from the aggregate's initial set up) to the endpoint node. - o In response, Rtr4 will generate the RESV (reservation) message + o In response, R4 will generate the RESV (reservation) message [defined behavior per 1]. This RESV from the deaggregator indicates an increase bandwidth sufficient to accommodate the existing 5 flows (1,2,3,4,5) and the new flow (9) [as stated in 2]. - o As mentioned before, in this example, Int8 in RTR 10 can only - accommodate 800kbps, and aggregates A and B have each already + o As mentioned before, in this example, Int8 in R 10 can only + accommodate 800kbps, and aggregates X and Y have each already established 400kbps flows comprised of five 80kbps individual - flows. Therefore, Rtr10 (the interface that detects a congestion + flows. Therefore, R10 (the interface that detects a congestion event in this example) must make a decision about this new congestion generating condition in regard to the RESV message received at Int8. o Local Policy in this scenario is to preempt lower priority reservations to place higher priority reservations. This would - normally cause all of aggregate B to be preempted just to - accommodate aggregate A's request for an additional 80kbps. + normally cause all of aggregate Y to be preempted just to + accommodate aggregate X's request for an additional 80kbps. - o This document defines how aggregate B is not completely + o This document defines how aggregate Y is not completely preempted, but reduced in bandwidth by 80kbps. This is - contained in the ResvErr message that Rtr10 generates - (downstream) towards Rtr11, Rtr7 and Rtr8. See section 5 for + contained in the ResvErr message that R10 generates + (downstream) towards R11, R7 and R8. See section 5 for the details of the error message. o Normal operation of RSVP is to have the router that generates a ResvErr message downstream to also generate a ResvTear message - upstream (in the opposite direction towards Rtr5). The ResvTear + upstream (in the opposite direction towards R5). The ResvTear message terminates an individual flow or aggregate flow. This document calls for that message to not be sent on any partial failure of reservation. - o Rtr8 is the deaggregator of aggregate B. The deaggregator + o R8 is the deaggregator of aggregate Y. The deaggregator controls all the parameters of an aggregate reservation. This will be the node that reduces the necessary bandwidth of the aggregate as a response to the reception of an ResvErr message - (from Rtr10) indicating such an action is called for. In this + (from R10) indicating such an action is called for. In this example, bandwidth reduction is accomplished by preempting an individual flow within the aggregate (perhaps picking on Flow D for individual preemption by generating a ResvErr downstream on that individual flow). o At the same time, a ResvTear message is transmitted upstream on - that individual flow (Flow D) by Rtr8. This will not affect the + that individual flow (Flow D) by R8. This will not affect the aggregate directly, but is an indication to the routers (and the source end-system) which individual flow is to be preempted. - o Once Rtr8 preempts whichever individual flow (or 'bandwidth' at + o Once R8 preempts whichever individual flow (or 'bandwidth' at the aggregate ingress), it transmits a new RESV message for that - aggregate (B), not for a new aggregate. This RESV from the + aggregate (Y), not for a new aggregate. This RESV from the deaggregator indicates an decrease in bandwidth sufficient to accommodate the remaining 4 flows (A,B,C,E), which is now 320kbps (in this example). o This RESV message travels the entire path of the reservation, resetting all routers to this new aggregate bandwidth value. This should be what is necessary to prevent a ResvTear message - from being generated by Rtr10 towards Rtr6 and Rtr5. + from being generated by R10 towards R6 and R5. - Rtr5 will not know through this RESV message which individual flow - was preempted. If in this example, Rtr8 was given more bandwidth to + R5 will not know through this RESV message which individual flow + was preempted. If in this example, R8 was given more bandwidth to keep, it might have transmitted a bandwidth reduction ResvErr indication towards the end-system of Flow D. In that case, a voice signaling protocol (such as SIP) could have attempted a renegotiation of that individual flow to a reduced bandwidth (say, but changing the voice codec from G.711 to G. 729). This could have saved Flow D from preemption. 10. References 10.1 Normative References @@ -819,24 +800,30 @@ 10.2 Informational References [9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [10] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001 [11] F. Le Faucheur, B. Davie, P. Bose, C. Christou, " Aggregate - reservations for IPsec Tunnel", draft-lefaucheur-rsvp-ipsec-01, + reservations for IPSec Tunnel", draft-lefaucheur-rsvp-ipsec-01, July 2005, "work in progress" -11. Author Information + [12] F. Baker, B. Lindell, M. Talwar, "RSVP Cryptographic + Authentication", RFC 2747, January 2000 + + [13] R. Braden, L. Zhang, "RSVP Cryptographic Authentication -- + Updated Message Type Value", RFC 3097, April 2001 + + Author Information James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA Email: jmpolk@cisco.com Subha Dhesikan Cisco Systems @@ -874,22 +861,22 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2005). This document is subject + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. The Expiration date for this Internet Draft is: - March 8th, 2006 + July 24th, 2006