summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4495.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4495.txt')
-rw-r--r--doc/rfc/rfc4495.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc4495.txt b/doc/rfc/rfc4495.txt
new file mode 100644
index 0000000..ce242c8
--- /dev/null
+++ b/doc/rfc/rfc4495.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group J. Polk
+Request for Comments: 4495 S. Dhesikan
+Updates: 2205 Cisco Systems
+Category: Standards Track May 2006
+
+
+ A Resource Reservation Protocol (RSVP) Extension for the
+ Reduction of Bandwidth of a Reservation Flow
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+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. This specification is an extension of RFC 2205.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 1]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Conventions Used in This Document ..........................4
+ 2. Individual Reservation Reduction Scenario .......................4
+ 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 .............................11
+ 5.2. Error Flow Descriptor .....................................11
+ 5.3. Individual Reservation Flow Reduction .....................11
+ 5.4. Aggregation Reduction of Individual Flows .................12
+ 5.5. RSVP Flow Reduction Involving IPsec Tunnels ...............12
+ 5.6. Reduction of Multiple Flows at Once .......................13
+ 6. Backwards Compatibility ........................................13
+ 7. Security Considerations ........................................14
+ 8. IANA Considerations ............................................15
+ 9. Acknowledgements ...............................................15
+ 10. References ....................................................15
+ 10.1. Normative References .....................................15
+ 10.2. Informative References ...................................16
+ Appendix A. Walking through the Solution ..........................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
+ due to a variety of reasons such as preemption, etc. In such cases,
+ when the entire bandwidth allocated to a reservation is not required,
+ the reservation need not be torn down. The solution described in
+ this document allows endpoints to negotiate a new (lower) bandwidth
+ that falls at or below the specified new bandwidth maximum allocated
+ by the network. Using a voice session as an example, this indication
+ in RSVP could lead endpoints, using another protocol such as Session
+ Initiation Protocol (SIP) [9], to signal for a lower-bandwidth codec
+ and retain the reservation.
+
+ With RSVP aggregation [2], two aggregate flows with differing
+ priority levels may traverse the same router interface. If that
+ router interface reaches bandwidth capacity and is then asked to
+ establish a new reservation or increase an existing reservation, the
+
+
+
+
+Polk & Dhesikan Standards Track [Page 2]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ router has to make a choice: deny the new request (because all
+ resources have been utilized) or preempt an existing lower-priority
+ reservation to make room for the new or expanded reservation.
+
+ If the flow being preempted is an aggregate of many individual flows,
+ this has greater consequences. While [2] clearly does not 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 the
+ reservation must be reduced to a certain amount (or less). RSVP
+ 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.
+
+ Explicit Congestion Notification (ECN) [10] is an indication that the
+ transmitting endpoint must reduce its transmission. It does not
+ provide sufficient indication to tell the endpoint by how much the
+ reduction should be. Hence the application may have to attempt
+ multiple times before it is able to drop its bandwidth utilization
+ below the available limit. Therefore, while we consider ECN to be
+ very useful for elastic applications, it is not sufficient for the
+ purpose of inelastic application where an indication of bandwidth
+ availability is useful for codec selection.
+
+ Section 2 discusses the individual reservation flow problem, while
+ Section 3 discusses the aggregate reservation flow problem space.
+ Section 4 lists the requirements for this extension. Section 5
+ details the protocol changes necessary in RSVP to create a
+ reservation reduction indication. And finally, the appendix provides
+ a walk-through example of how this extension modifies RSVP
+ functionality in an aggregate scenario.
+
+
+
+
+Polk & Dhesikan Standards Track [Page 3]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ This document updates 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].
+
+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===>
+ | R1 |Int 2 |===========>|Int 8 | R2 |
+ | | |:::::::::::>| | |
+ Flow 2:::> | +----- | |------+ | Flow 2:::>
+ | |Int 3 | |Int 9 | |
+ +------------+ +------------+
+
+ Figure 1. Simple Reservation Flows
+
+ 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
+
+ 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's sake.
+
+ Figure 1 depicts 2 routers (R1 and R2) initially with only one flow
+ (Flow 1). The flows are forwarded from R1 to R2 via Int 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).
+
+
+
+Polk & Dhesikan Standards Track [Page 4]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ Let us also say that the RSVP bandwidth limit for Int 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.
+
+ Without the benefit of this specification, Flow 1 will be preempted.
+ This specification makes it possible for the ResvErr message to
+ indicate that 20 units are still available for a reservation to
+ remain up (the interface's 100 units maximum minus Flow 2's 80
+ units). The reservation initiating node (router or end-system) for
+ Flow 1 has the opportunity to renegotiate (via call signaling) for
+ acceptable parameters within the existing and available bandwidth for
+ the flow (for example, it may decide to change to using a codec such
+ as G.729)
+
+ The problems avoided with the partial failure of the flow are:
+
+ - Reduced packet loss, which results as Flow 1 attempts to
+ reestablish the reservation for a lower bandwidth.
+
+ - Inefficiency caused by multiple attempts until Flow 1 is able to
+ request bandwidth equal to or lower than what is available. If
+ Flow 1 is established with much less than what is available then it
+ leads to inefficient use of available bandwidth.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 5]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+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 be 5 flows per aggregate (Flow 9 will
+ be introduced to cause the problem we are addressing in this
+ document), with 2 aggregates (X and Y); Flows 1 through 5 in
+ aggregate X and Flows 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 6]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ 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 | R1 | | | R2 | | R3 | | | R4 | Flow 9
+ +------+ | +------+ +------+ | +------+
+ | || || |
+ Aggregate X-->|| Aggregate X ||<--Aggregate X
+ || | ||
+ +--------------+ | +--------------+
+ | |Int 7 | | |Int 1 | |
+ | +----- | V |------+ |
+ | R10 |Int 8 |===========>|Int 2 | R11 |
+ | | |:::::::::::>| | |
+ | +----- | ^ |------+ |
+ | |Int 9 | | |Int 3 | |
+ +--------------+ | +--------------+
+ .. | ..
+ 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-->| R5 | | R6 | | R7 | | R8 |-->Flow E
+ +------+ +------+ +------+ +------+
+ ^ ^
+ | |
+ Aggregator of Y Deaggregator of Y
+
+ Figure 2. Generic RSVP Aggregate Topology
+
+ Legend/Rules:
+
+ - 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.
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 7]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ The path for aggregate X is:
+
+ 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 Y is:
+
+ R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
+
+ 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 R10 and R11,
+ thus they share one outbound interface: Int 8 of R10, where
+ contention of resources may exist. That link has an RSVP capacity of
+ 800 kbps. RSVP signaling (messages) is outside the 800 kbps 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 X)
+ between the routers R1 and R4. This aggregated reservation consists
+ of 5 microflows (Flows 1, 2, 3, 4, and 5). For the sake of this
+ discussion, let us assume that each flow represents a voice call and
+ requires 80 kb (such as for the codec G.711 with no silence
+ suppression). Aggregate X request is for 400 kbps (80 kbps * 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 Y, in Figure 2, consists of Flows A, B, C, D, and E and
+ requires 400 kbps (80 kbps * 5 flows), and starts at R5 and ends R8.
+ This means there are two aggregates occupying all 800 kbps of the
+ RSVP capacity.
+
+ When Flow 9 is added into aggregate X, this will occupy 80 kbps more
+ than Int 8 on R10 has available (880k offered load vs. 800k capacity)
+ [1] and [2] create a behavior in RSVP to deny the entire aggregate Y
+
+
+
+Polk & Dhesikan Standards Track [Page 8]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ 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 Y that only 80 kbps 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 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), 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 mean 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
+ reservation. This applies to both individual and aggregate
+ reservations:
+
+ Req#1 - MUST have the ability to differentiate one reservation from
+ another. In the case of aggregates, it MUST distinguish one
+ aggregate from other flows.
+
+ Req#2 - MUST have the ability to indicate within an RSVP error
+ message (generated at the router with the congested
+ interface) that a specific reservation (individual or
+ aggregate) is to be reduced in bandwidth.
+
+ Req#3 - MUST have the ability to indicate within the same error
+ message the new maximum amount of bandwidth that is available
+ to be utilized within the existing reservation, but no more.
+
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 9]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ Req#4 - MUST NOT produce a case in which retransmitted reduction
+ indications further reduce the bandwidth of a reservation.
+ Any additional reduction in bandwidth for a specified
+ reservation MUST be signaled in a new message.
+
+ RSVP messages are unreliable and can get lost. This specification
+ should not compound any error in the network. If a reduction message
+ were lost, another one needs to be sent. If the receiver ends up
+ receiving two copies to reduce the bandwidth of a reservation by some
+ amount, it is likely the router will reduce the bandwidth by twice
+ the amount that was actually called for. This will be in error.
+
+5. RSVP Bandwidth Reduction Solution
+
+ When a reservation is partially failed, a ResvErr (Reservation Error)
+ message is generated just as it is done currently with preemptions.
+ The ERROR_SPEC object and the PREEMPTION_PRI object are included as
+ well. Very few additions/changes are needed to the ResvErr message
+ to support partial preemptions. A new error subcode is required and
+ is defined in Section 5.1. The ERROR_SPEC object contained in the
+ ResvErr message indicates the flowspec that is reserved. The
+ bandwidth indication in this flowspec SHOULD be less than the
+ original reservation request. This is defined in Section 5.2.
+
+ A comment about RESV messages that do not use reliable transport:
+ This document RECOMMENDS that ResvErr messages be made reliable by
+ implementing mechanisms in [6].
+
+ The current behavior in RSVP requires a ResvTear message to be
+ transmitted upstream when the ResvErr message is transmitted
+ downstream (per [1]). This ResvTear message terminates the
+ reservation in all routers upstream of the router where the failure
+ occurred. This document requires that the ResvTear is only generated
+ when the reservation is to be completely removed. In cases where the
+ reservation is only to be reduced, routers compliant with this
+ specification require that the ResvTear message MUST NOT be sent.
+
+ The appendix has been written to walk through the overall solution to
+ the problems presented in Sections 2 and 3. There is mention of this
+ ResvTear transmission behavior in the appendix.
+
+
+
+
+
+
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 10]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+5.1. Partial Preemption Error Code
+
+ The ResvErr message generated due to preemption includes the
+ ERROR_SPEC object as well as the PREEMPTION_PRI object. The format
+ of ERROR_SPEC objects is defined in [1]. The error code listed in
+ the ERROR_SPEC object for preemption [5] currently is as 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 = 102 (ERR_PARTIAL_PREEMPT)
+
+ There is also an error code in the PREEMPTION-PRI 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] and [7]. In the case of
+ partial failure, the flowspec contained in the error flow descriptor
+ indicates the highest average and peak rates that the preempting
+ system can accept in the next RESV message. The deaggregator must
+ reduce its reservation to a number less than or equal to that,
+ whether by changing codecs, dropping reservations, or some other
+ mechanism.
+
+5.3. Individual Reservation Flow Reduction
+
+ When a router requires part of the bandwidth that has been allocated
+ to a reservation be used for another flow, the router engages in the
+ partial reduction of bandwidth as described in this document. The
+ router sends a ResvErr downstream to indicate the partial error with
+ the error code and subcode as described in section 5.1. The flowspec
+ contained in the ResvErr message will be used to indicate the
+ bandwidth that is currently allocated.
+
+ The requesting endpoint that receives the ResvErr can then negotiate
+ with the transmitting endpoint to lower the bandwidth requirement (by
+ selecting another lower bandwidth codec, for example). After the
+ negotiations, both endpoints will issue the RSVP PATH and RESV
+ message with the new, lowered bandwidth.
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 11]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+5.4. Aggregation Reduction of Individual Flows
+
+ When a partial failure occurs in an aggregation scenario, the
+ deaggregator receives the ResvErr message with the reduction
+ indication from a router in the path of the aggregate. It then
+ decides whether one or more individual flows from the aggregate are
+ to be affected by this ResvErr message. The following choices are
+ possible:
+
+ o If that (deaggregator) router determines that one or more
+ individual flow(s) are to partially failed, then it sends a
+ ResvErr message with a reduced bandwidth indication to those
+ individual flow(s). This is as per the descriptions in the
+ previous section (5.3).
+
+ o If that (deaggregator) router determines that one individual flow
+ is to be preempted to satisfy the aggregate ResvErr, it determines
+ which flow is affected. That router transmits a new ResvErr
+ message downstream per [3]. That same router transmits a ResvTear
+ message upstream. This ResvTear message of an individual flow
+ does not tear down the aggregate. Only the individual flow is
+ affected.
+
+ o If that (deaggregator) router determines that multiple individual
+ flows are to be preempted to satisfy the aggregate ResvErr, it
+ chooses which flows are affected. That router transmits a new
+ ResvErr message downstream as per [3] to each individual flow.
+ The router also transmits ResvTear messages upstream for the same
+ individual 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
+
+ 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.
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 12]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ The methods of identification of an IPsec with reservation flow are
+ different from 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,
+ considered an individual flow with regard to how to reduce the
+ 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 widespread 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:
+
+ - If that router supports this extension:
+
+ #1 - it generates the ResvErr message with the error code
+ indicating the reduction in bandwidth.
+
+ #2 - it does not generate the ResvTear message.
+
+ - If that router does not support this extension, it generates both
+ ResvErr and ResvTear messages according to [1].
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 13]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ In the case of the router at the extreme downstream of a reservation
+ that receives the ResvErr message with the reduction indication:
+
+ - If that router does support this extension:
+
+ #1 - it processes this error message and applies whatever local
+ policy it is configured to do to determine how to reduce the
+ bandwidth of this designated flow.
+
+ - If the router does not support this extension:
+
+ #1 - it processes the ResvErr message according to [1] and all
+ extensions it is able to understand, but not this extension
+ from this document.
+
+ 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 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 rogue flows without authentication [12, 13],
+ this mechanism will have the same vulnerability. Usage of RSVP
+ authentication mechanisms is encouraged.
+
+
+
+
+
+
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 14]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+8. IANA Considerations
+
+ The IANA has assigned the following from RFC 4495 (i.e., this
+ document):
+
+ The following error code has been defined in the ERROR_SPEC object
+ for partial reservation failure under "Errcode = 2 (Policy Control
+ Failure)":
+
+ ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)
+
+ The behavior of this ErrSubCode is defined in this document.
+
+9. Acknowledgements
+
+ The authors would like to thank Fred Baker for contributing text and
+ guidance in this effort and to Roger Levesque and Francois Le
+ Faucheur for helpful comments.
+
+10. References
+
+10.1. Normative References
+
+ [1] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+ Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+ Functional Specification", RFC 2205, September 1997.
+
+ [2] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
+ "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
+ September 2001.
+
+ [3] Herzog, S., "Signaled Preemption Priority Policy Element", RFC
+ 3181, October 2001.
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
+ January 2000.
+
+ [6] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
+ Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
+ 2961, April 2001.
+
+ [7] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
+ RFC 2210, September 1997.
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 15]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ [8] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
+ Flows", RFC 2207, September 1997.
+
+10.2. Informative References
+
+ [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+ Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+ Session Initiation Protocol", RFC 3261, June 2002.
+
+ [10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
+ Explicit Congestion Notification (ECN) to IP", RFC 3168,
+ September 2001.
+
+ [11] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
+ Davenport, "Generic Aggregate RSVP Reservations", Work in
+ Progress, October 2005.
+
+ [12] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
+ Authentication", RFC 2747, January 2000.
+
+ [13] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication --
+ Updated Message Type Value", RFC 3097, April 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 16]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+Appendix A. Walking through the Solution
+
+ Here is a concise explanation of roughly how RSVP behaves with the
+ solution to the problems presented in Sections 2 and 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 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-->| R1 | | | R2 | | R3 | | | R4 |-->Flow 9
+ +------+ | +------+ +------+ | +------+
+ | || || |
+ Aggregate X--->|| Aggregate X ||<--Aggregate X
+ || | ||
+ +--------------+ | +--------------+
+ | |Int 7 | | |Int 1 | |
+ | +----- | V |------+ |
+ | R10 |Int 8 |===========>|Int 2 | R11 |
+ | | |:::::::::::>| | |
+ | +----- | ^ |------+ |
+ | |Int 9 | | |Int 3 | |
+ +--------------+ | +--------------+
+ .. | ..
+ 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-->| R5 | | R6 | | R7 | | R8 |-->Flow E
+ +------+ +------+ +------+ +------+
+ ^ ^
+ | |
+ Aggregator of Y Deaggregator of Y
+
+ Duplicate of Figure 2. Generic RSVP Aggregate Topology
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 17]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ Looking at Figure 2, aggregate X (with five 80 kbps flows) traverses:
+
+ R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4
+
+ And aggregate Y (with five 80 kbps flows) traverses:
+
+ R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
+
+ Both aggregates are 400 kbps. This totals 800 kbps at Int 7 in R10,
+ which is the maximum bandwidth that RSVP has access to at this
+ interface. Signaling messages still traverse the interface without
+ 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 80 kbps) 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 R2, R10, R11, R3, and
+ R4, which is the aggregate X path (that was built per [2] from the
+ aggregate's initial setup) to the endpoint node.
+
+ 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, and 5) and the new flow (9), as
+ stated in [2].
+
+ o As mentioned before, in this example, Int 8 in R10 can only
+ accommodate 800 kbps, and aggregates X and Y have each already
+ established 400 kbps flows comprised of five 80 kbps individual
+ 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 Int 8.
+
+ o Local policy in this scenario is to preempt lower-priority
+ reservations to place higher-priority reservations. This would
+ normally cause all of aggregate Y to be preempted just to
+ accommodate aggregate X's request for an additional 80 kbps.
+
+ o This document defines how aggregate Y is not completely preempted,
+ but reduced in bandwidth by 80 kbps. This is contained in the
+ ResvErr message that R10 generates (downstream) towards R11, R7,
+ and R8. See section 5 for the details of the error message.
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 18]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+ 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, i.e., towards R5). The
+ ResvTear message terminates an individual flow or aggregate flow.
+ This document calls for that message not to be sent on any partial
+ failure of reservation.
+
+ 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 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 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 R8 preempts whichever individual flow (or 'bandwidth' at the
+ aggregate ingress), it transmits a new RESV message for that
+ aggregate (Y), not for a new aggregate. This RESV from the
+ deaggregator indicates a decrease in bandwidth sufficient to
+ accommodate the remaining 4 flows (A, B, C, and E), which is now
+ 320 kbps (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 R10 towards R6 and R5.
+
+ 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.
+
+
+
+
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 19]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+Authors' Addresses
+
+ James M. Polk
+ Cisco Systems
+ 2200 East President George Bush Turnpike
+ Richardson, Texas 75082 USA
+
+ EMail: jmpolk@cisco.com
+
+
+ Subha Dhesikan
+ Cisco Systems
+ 170 W. Tasman Drive
+ San Jose, CA 95134 USA
+
+ EMail: sdhesika@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 20]
+
+RFC 4495 RSVP Bandwidth Reduction May 2006
+
+
+Full Copyright Statement
+
+ 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.
+
+ 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Polk & Dhesikan Standards Track [Page 21]
+