draft-ietf-tsvwg-rsvp-bw-reduction-02.txt		rfc4495.txt
	Transport Area Working Group James Polk		Network Working Group J. Polk
	Internet Draft Subha Dhesikan		Request for Comments: 4495 S. Dhesikan
	Expiration: July 24th, 2005 Cisco Systems		Updates: 2205 Cisco Systems
	File: draft-ietf-tsvwg-rsvp-bw-reduction-02.txt January 24th, 2005		Category: Standards Track May 2006
	A Resource Reservation Protocol Extension for the		A Resource Reservation Protocol (RSVP) Extension for the
	Reduction of Bandwidth of a Reservation Flow		Reduction of Bandwidth of a Reservation Flow
	Status of this Memo		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.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six
	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 July 24th, 2006.		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 Notice
	Copyright (C) The Internet Society (2006). All Rights Reserved.		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document proposes an extension to the Resource Reservation		This document proposes an extension to the Resource Reservation
	Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an		Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an
	existing reservation. This mechanism can be used to affect		existing reservation. This mechanism can be used to affect
	individual reservations, aggregate reservations or other forms of		individual reservations, aggregate reservations, or other forms of
	RSVP tunnels.		RSVP tunnels. This specification is an extension of RFC 2205.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction ....................................................2
	1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Conventions Used in This Document ..........................4
	2. Individual Reservation Reduction Scenario . . . . . . . . . . 4		2. Individual Reservation Reduction Scenario .......................4
	3. RSVP Aggregation Overview . . . . . . . . . . . . . . . . . . 5		3. RSVP Aggregation Overview .......................................6
	3.1 RSVP Aggregation Reduction Scenario . . . . . . . . . . . 7		3.1. RSVP Aggregation Reduction Scenario ........................8
	4. Requirements for Reservation Reduction . . . . . . . . . . . 8		4. Requirements for Reservation Reduction ..........................9
	5. RSVP Bandwidth Reduction Solution . . . . . . . . . . . . . . 9		5. RSVP Bandwidth Reduction Solution ..............................10
	5.1 Partial Preemption Error Code . . . . . . . . . . . . . 9		5.1. Partial Preemption Error Code .............................11
	5.2 Error Flow Descriptor . . . . . . . . . . . . . . . . . 10		5.2. Error Flow Descriptor .....................................11
	5.3 Individual Reservation Flow Reduction . . . . . . . . . 10		5.3. Individual Reservation Flow Reduction .....................11
	5.4 Aggregation Reduction of Individual Flows . . . . . . . 10		5.4. Aggregation Reduction of Individual Flows .................12
	5.5 RSVP Flow Reduction involving IPSec Tunnels . . . . . . 11		5.5. RSVP Flow Reduction Involving IPsec Tunnels ...............12
	5.6 Reduction of Multiple Flows At Once . . . . . . . . . . 11		5.6. Reduction of Multiple Flows at Once .......................13
	6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12		6. Backwards Compatibility ........................................13
	7. Security Considerations . . . . . . . . . . . . . . . . . . 12		7. Security Considerations ........................................14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations ............................................15
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		9. Acknowledgements ...............................................15
	Appendix. Walking Through the Solution . . . . . . . . . . . . . 13		10. References ....................................................15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		10.1. Normative References .....................................15
	10.1 Normative References . . . . . . . . . . . . . . . . . . 16		10.2. Informative References ...................................16
	10.2 Informational References . . . . . . . . . . . . . . . . 17		Appendix A. Walking through the Solution ..........................17
	Author Information . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This document proposes an extension to the Resource Reservation		This document proposes an extension to the Resource Reservation
	Protocol (RSVP) [1] to allow an existing reservation to be reduced		Protocol (RSVP) [1] to allow an existing reservation to be reduced in
	in allocated bandwidth in lieu of tearing that reservation down when		allocated bandwidth in lieu of tearing that reservation down when
	some of that reservation's bandwidth is needed for other purposes.		some of that reservation's bandwidth is needed for other purposes.
	Several examples exist in which this mechanism may be utilized.		Several examples exist in which this mechanism may be utilized.
	The bandwidth allotted to an individual reservation may be reduced		The bandwidth allotted to an individual reservation may be reduced
	due to a variety of reasons such as preemption, etc. In such cases,		due to a variety of reasons such as preemption, etc. In such cases,
	when the entire bandwidth allocated to a reservation is not		when the entire bandwidth allocated to a reservation is not required,
	required, the reservation need not be torn down. The solution		the reservation need not be torn down. The solution described in
	described in this document allows endpoints to negotiate a new		this document allows endpoints to negotiate a new (lower) bandwidth
	(lower) bandwidth that falls at or below the specified new bandwidth		that falls at or below the specified new bandwidth maximum allocated
	maximum allocated by the network. Using a voice session as an		by the network. Using a voice session as an example, this indication
	example, this indication in RSVP could lead endpoints, using another		in RSVP could lead endpoints, using another protocol such as Session
	protocol such as Session Initiation Protocol (SIP) [9], to signal		Initiation Protocol (SIP) [9], to signal for a lower-bandwidth codec
	for a lower bandwidth codec and retain the reservation.		and retain the reservation.
	With RSVP aggregation [2], two aggregate flows with differing		With RSVP aggregation [2], two aggregate flows with differing
	priority levels may traverse the same router interface. If that		priority levels may traverse the same router interface. If that
	router interface reaches bandwidth capacity and is then asked to		router interface reaches bandwidth capacity and is then asked to
	establish a new reservation or increase an existing reservation the		establish a new reservation or increase an existing reservation, the
	router has to make a choice: deny the new request (because all		router has to make a choice: deny the new request (because all
	resources have been utilized) or preempt an existing lower priority		resources have been utilized) or preempt an existing lower-priority
	reservation to make room for the new or expanded reservation.		reservation to make room for the new or expanded reservation.
	If the flow being preempted is an aggregate of many individual		If the flow being preempted is an aggregate of many individual flows,
	flows, this has greater consequences. While [2] clearly does not		this has greater consequences. While [2] clearly does not terminate
	terminate all the individual flows if an aggregate is torn down,		all the individual flows if an aggregate is torn down, this event
	this event will cause packets to be discarded during aggregate		will cause packets to be discarded during aggregate reservation
	reservation reestablishment. This document describes a method where		reestablishment. This document describes a method where only the
	only the minimum required bandwidth is taken away from the lower-		minimum required bandwidth is taken away from the lower-priority
	priority aggregated reservation and the entire reservation is not		aggregated reservation and the entire reservation is not preempted.
	preempted. This has the advantage that only some of the microflows		This has the advantage that only some of the microflows making up the
	making up the aggregate are affected. Without this extension, all		aggregate are affected. Without this extension, all individual flows
	individual flows are affected and the deaggregator will have to		are affected and the deaggregator will have to attempt the
	attempt the reservation request with a reduced bandwidth.		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
	the reservation must be reduced to a certain amount (or less). RSVP		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
	should be able to take advantage of the mechanism created here in		be able to take advantage of the mechanism created here in this
	this specification.		specification.
	Note that when this document refers to a router interface being		Note that when this document refers to a router interface being
	"full" or "at capacity", this does not imply that all of the		"full" or "at capacity", this does not imply that all of the
	bandwidth has been used, but rather that all of the bandwidth		bandwidth has been used, but rather that all of the bandwidth
	available for reservation(s) via RSVP under the applicable policy		available for reservation(s) via RSVP under the applicable policy has
	has been used. Policies for real-time traffic routinely reserve		been used. Policies for real-time traffic routinely reserve capacity
	capacity for routing and inelastic applications, and may distinguish		for routing and inelastic applications, and may distinguish between
	between voice, video, and other real time applications.		voice, video, and other real-time applications.
	Explicit Congestion notification (ECN) [10] is an indication that		Explicit Congestion Notification (ECN) [10] is an indication that the
	the transmitting endpoint must reduce its transmission. It does not		transmitting endpoint must reduce its transmission. It does not
	provide sufficient indication to tell the endpoint by how much the		provide sufficient indication to tell the endpoint by how much the
	reduction should be. Hence the application may have to attempt		reduction should be. Hence the application may have to attempt
	multiple times before it is able to drop its bandwidth utilization		multiple times before it is able to drop its bandwidth utilization
	below the available limit. Therefore, while we consider ECN to be		below the available limit. Therefore, while we consider ECN to be
	very useful for elastic applications, it is not sufficient for the		very useful for elastic applications, it is not sufficient for the
	purpose of inelastic application where an indication of bandwidth		purpose of inelastic application where an indication of bandwidth
	availability is useful for codec selection.		availability is useful for codec selection.
	Section 2 will discuss the individual reservation flow problem		Section 2 discusses the individual reservation flow problem, while
	while Section 3 will discuss the aggregate reservation flow		Section 3 discusses the aggregate reservation flow problem space.
	problem space. Section 4 lists the requirements for this extension.		Section 4 lists the requirements for this extension. Section 5
	Section 5 details the protocol changes necessary in RSVP to create a		details the protocol changes necessary in RSVP to create a
	reservation reduction indication. And finally, there is an appendix		reservation reduction indication. And finally, the appendix provides
	with a walk-through example of how this extension modifies RSVP		a walk-through example of how this extension modifies RSVP
	functionality in an aggregate scenario.		functionality in an aggregate scenario.
	This document is intended to be classified as an 'update' to RFC		This document updates RFC 2205 [1], as this mechanism affects the
	2205 [1], as this mechanism affects the behaviors of the ResvErr and		behaviors of the ResvErr and ResvTear indications defined in that
	ResvTear indications defined in that document.		document.
	1.1 Conventions used in this document		1.1. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [4].		document are to be interpreted as described in [4].
	2. Individual Reservation Reduction Scenario		2. Individual Reservation Reduction Scenario
	Figure 1 is a network topology that is used to describe the benefit		Figure 1 is a network topology that is used to describe the benefit
	of bandwidth reduction in an individual reservation.		of bandwidth reduction in an individual reservation.
	skipping to change at page 4, line 27		skipping to change at page 4, line 31
	| |Int 1 | |Int 7 | |		| |Int 1 | |Int 7 | |
	Flow 1===> | +----- | |------+ | Flow 1===>		Flow 1===> | +----- | |------+ | Flow 1===>
	| R1 |Int 2 |===========>|Int 8 | R2 |		| R1 |Int 2 |===========>|Int 8 | R2 |
	| | |:::::::::::>| | |		| | |:::::::::::>| | |
	Flow 2:::> | +----- | |------+ | Flow 2:::>		Flow 2:::> | +----- | |------+ | Flow 2:::>
	| |Int 3 | |Int 9 | |		| |Int 3 | |Int 9 | |
	+------------+ +------------+		+------------+ +------------+
	Figure 1. Simple Reservation Flows		Figure 1. Simple Reservation Flows
	Figure 1. Legend/Rules:		Legend/Rules:
	- Flow 1 priority = 300		- Flow 1 priority = 300
	- Flow 2 priority = 100		- Flow 2 priority = 100
	- Both flows are shown in the same direction (left to		- Both flows are shown in the same direction (left to
	right). Corresponding flows in the reverse direction are		right). Corresponding flows in the reverse direction are
	not shown for diagram simplicity		not shown for diagram simplicity
	RSVP is a reservation establishment protocol in one direction only.		RSVP is a reservation establishment protocol in one direction only.
	This split path philosophy is because the routed path from one		This split-path philosophy is because the routed path from one device
	device to the other in one direction might not be the routed path		to the other in one direction might not be the routed path for
	for communicating between the same two endpoints in the reverse		communicating between the same two endpoints in the reverse
	direction. End-systems must request 2 one-way reservations if that		direction. End-systems must request 2 one-way reservations if that
	is what is needed for a particular application (like voice calls).		is what is needed for a particular application (like voice calls).
	Please refer to [1] for the details on how this functions. This		Please refer to [1] for the details on how this functions. This
	example only describes the reservation scenario in one direction for		example only describes the reservation scenario in one direction for
	simplicity sake.		simplicity's sake.
	Figure 1. depicts 2 routers, (R1 and R2) initially with only one		Figure 1 depicts 2 routers (R1 and R2) initially with only one flow
	flow (Flow 1). The flows are forwarded from R1 to R2 via		(Flow 1). The flows are forwarded from R1 to R2 via Int 2. For this
	interface 2. For this example, let us say that flow 1 and flow 2		example, let us say that Flow 1 and Flow 2 each require 80 units of
	each require 80 units of bandwidth (such as for the codec G.711 with		bandwidth (such as for the codec G.711 with no silence suppression).
	no silence suppression). Let us also say that the RSVP bandwidth
	limit for interface 2 of R1 is 100 units.		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		As described in [3], a priority indication is established for each
	flow. In fact, there are two priority indications:		flow. In fact, there are two priority indications:
	1) one to establish the reservation, and		1) one to establish the reservation, and
	2) one to defend the reservation.		2) one to defend the reservation.
	In this example, flow 1 and flow 2 have an 'establishing' and a		In this example, Flow 1 and Flow 2 have an 'establishing' and a
	'defending' priority of 300 and 100 respectively. Flow 2 will have		'defending' priority of 300 and 100, respectively. Flow 2 will have
	a higher establishing priority than flow 1 has for its defending		a higher establishing priority than Flow 1 has for its defending
	priority. This means that when flow 2 is signaled, and if no		priority. This means that when Flow 2 is signaled, and if no
	bandwidth is available at the interface, flow 1 will have to		bandwidth is available at the interface, Flow 1 will have to
	relinquish bandwidth in favor of the higher priority request of flow		relinquish bandwidth in favor of the higher-priority request of Flow
	2. The priorities assigned to a reservation are always end-to-end,		2. The priorities assigned to a reservation are always end-to-end,
	and not altered by any routers in transit.		and not altered by any routers in transit.
	Without the benefit of this specification, flow 1 will be preempted.		Without the benefit of this specification, Flow 1 will be preempted.
	This specification makes it possible for the ResvErr message to		This specification makes it possible for the ResvErr message to
	indicate that 20 units are still available for a reservation 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		remain up (the interface's 100 units maximum minus Flow 2's 80
	units). The reservation initiating node (router or end-system) for		units). The reservation initiating node (router or end-system) for
	Flow 1 has the opportunity to re-negotiate (via call signaling) for		Flow 1 has the opportunity to renegotiate (via call signaling) for
	acceptable parameters within the existing and available bandwidth		acceptable parameters within the existing and available bandwidth for
	for the flow (for example, it may decide to change to using a codec		the flow (for example, it may decide to change to using a codec such
	such as G.729)		as G.729)
	The problems avoided with the partial failure of the flow are:		The problems avoided with the partial failure of the flow are:
	- Reduced packet loss which is resulted as flow 1 attempts to		- Reduced packet loss, which results as Flow 1 attempts to
	re-establish the reservation for a lower bandwidth.		reestablish the reservation for a lower bandwidth.
	- Inefficiency caused by multiple attempts until flow 1 is able to		- Inefficiency caused by multiple attempts until Flow 1 is able to
	request bandwidth equal to or lower than what is available. If		request bandwidth equal to or lower than what is available. If
	flow 1 is established with much less than what is available then		Flow 1 is established with much less than what is available then it
	it leads to inefficient use of available bandwidth.		leads to inefficient use of available bandwidth.
	3. RSVP Aggregation Overview		3. RSVP Aggregation Overview
	The following network overview is to help visualize the concerns		The following network overview is to help visualize the concerns that
	that this specification addresses in RSVP Aggregates. Figure 2		this specification addresses in RSVP aggregates. Figure 2 consists
	consists of 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9,		of 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9, A, B, C, D,
	A, B, C, D, and E). Initially there will 5 flows per aggregate		and E). Initially, there will be 5 flows per aggregate (Flow 9 will
	(flow 9 will be introduced to cause the problem we are addressing in		be introduced to cause the problem we are addressing in this
	this document),with 2 aggregates (X & Y); (1 through 5) in aggregate		document), with 2 aggregates (X and Y); Flows 1 through 5 in
	X and (A through E) in aggregate Y. These 2 aggregates will cross		aggregate X and Flows A through E in aggregate Y. These 2 aggregates
	one router interface utilizing all available capacity (in this		will cross one router interface utilizing all available capacity (in
	example).		this example).
	RSVP aggregation [per 2] is no different from an individual		RSVP aggregation (per [2]) is no different from an individual
	reservation with respect to being unidirectional.		reservation with respect to being unidirectional.
	Aggregator of X Deaggregator of X		Aggregator of X Deaggregator of X
	| |		| |
	V V		V V
	+------+ +------+ +------+ +------+		+------+ +------+ +------+ +------+
	Flow 1-->| | | | | | | |--> Flow 1		Flow 1-->| | | | | | | |--> Flow 1
	Flow 2-->| | | | | | | |--> Flow 2		Flow 2-->| | | | | | | |--> Flow 2
	Flow 3-->| |==>| | | |==>| |--> Flow 3		Flow 3-->| |==>| | | |==>| |--> Flow 3
	Flow 4-->| | ^ | | | | ^ | |--> Flow 4		Flow 4-->| | ^ | | | | ^ | |--> Flow 4
	skipping to change at page 6, line 43		skipping to change at page 7, line 43
	Flow C-->| |::>| | | |::>| |--> Flow C		Flow C-->| |::>| | | |::>| |--> Flow C
	Flow D-->| | | | | | | |--> Flow D		Flow D-->| | | | | | | |--> Flow D
	Flow E-->| R5 | | R6 | | R7 | | R8 |--> Flow E		Flow E-->| R5 | | R6 | | R7 | | R8 |--> Flow E
	+------+ +------+ +------+ +------+		+------+ +------+ +------+ +------+
	^ ^		^ ^
	| |		| |
	Aggregator of Y Deaggregator of Y		Aggregator of Y Deaggregator of Y
	Figure 2. Generic RSVP Aggregate Topology		Figure 2. Generic RSVP Aggregate Topology
	Figure 2 legend/rules:		Legend/Rules:
	- Aggregate X priority = 100		- Aggregate X priority = 100
	- Aggregate Y priority = 200		- Aggregate Y priority = 200
	- All boxes are Routers		- All boxes are routers
	- Both aggregates are shown in the same direction (left to		- Both aggregates are shown in the same direction (left to
	right). Corresponding aggregates in the reverse direction are		right). Corresponding aggregates in the reverse direction
	not shown for diagram simplicity		are not shown for diagram simplicity.
	The path for aggregate X is:		The path for aggregate X is:
	R1 => R2 => R10 => R11 => R3 => R4		R1 => R2 => R10 => R11 => R3 => R4
	where aggregate X starts in R1, and deaggregates in R4.		where aggregate X starts in R1, and deaggregates in R4.
	Flows 1, 2, 3, 4, 5 and 9 communicate through aggregate A		Flows 1, 2, 3, 4, 5, and 9 communicate through aggregate A.
	The path for aggregate Y is:		The path for aggregate Y is:
	R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8		R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
	where aggregate Y starts in R5, and deaggregates in R8.		where aggregate Y starts in R5, and deaggregates in R8.
	Flows A, B, C, D and E communicate through aggregate B		Flows A, B, C, D, and E communicate through aggregate B.
	Both aggregates share one leg or physical link: between R10 and		Both aggregates share one leg or physical link: between R10 and R11,
	R11, thus they share one outbound interface: Int8 of R10, where		thus they share one outbound interface: Int 8 of R10, where
	contention of resources may exist. That link has an RSVP capacity		contention of resources may exist. That link has an RSVP capacity of
	of 800kbps. RSVP signaling (messages) is outside this 800kbps in		800 kbps. RSVP signaling (messages) is outside the 800 kbps in this
	this example, as is any session signaling protocol like SIP.		example, as is any session signaling protocol like SIP.
	3.1 RSVP Aggregation Reduction Scenario		3.1. RSVP Aggregation Reduction Scenario
	Figure 2 shows an established aggregated reservation (aggregate X)		Figure 2 shows an established aggregated reservation (aggregate X)
	between the routers R1 and R4. This aggregated reservation		between the routers R1 and R4. This aggregated reservation consists
	consists of 5 microflows (flow 1, 2, 3, 4, 5). For the sake of this		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		discussion, let us assume that each flow represents a voice call and
	requires 80kb (such as for the codec G.711 with no silence		requires 80kb (such as for the codec G.711 with no silence
	suppression). Aggregate X request is for 400kbps (80kbps * 5 flows).		suppression). Aggregate X request is for 400 kbps (80 kbps * 5
	The priority of the aggregate is derived from the individual		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		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		single priority are bundled as a single aggregate (another priority
	level would be in another aggregate, even if traversing the same		level would be in another aggregate, even if traversing the same path
	path through the network). There may be other ways in which the		through the network). There may be other ways in which the priority
	priority of the aggregate is derived, but for this discussion it		of the aggregate is derived, but for this discussion it is sufficient
	is sufficient to note that each aggregate contains a priority (both		to note that each aggregate contains a priority (both hold and
	hold and defending priority). The means of deriving the priority is		defending priority). The means of deriving the priority is out of
	out of scope for this discussion.		scope for this discussion.
	Aggregate Y, in Figure 2, consists of flows A, B, C, D and E and		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		requires 400 kbps (80 kbps * 5 flows), and starts at R5 and ends R8.
	R8. This means there are two aggregates occupying all 800kbps of		This means there are two aggregates occupying all 800 kbps of the
	the RSVP capacity.		RSVP capacity.
	When Flow 9 is added into aggregate X, this will occupy 80kbps more		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)		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		[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		and all its individual flows because aggregate X has a higher
	priority. This situation is where this document focuses its		priority. This situation is where this document focuses its
	requirements and calls for a solution. There should be some means		requirements and calls for a solution. There should be some means to
	to signal to all affected routers of aggregate Y that only 80kbps is		signal to all affected routers of aggregate Y that only 80 kbps is
	needed to accommodate another (higher priority) aggregate. A		needed to accommodate another (higher priority) aggregate. A
	solution that accomplishes this reduction instead of a failure		solution that accomplishes this reduction instead of a failure could:
	could:
	- reduce significant packet loss of all flows within aggregate Y		- reduce significant packet loss of all flows within aggregate Y
	During the re-reservation request period of time no packets will		During the re-reservation request period of time no packets will
	traverse the aggregate until it is reestablished.		traverse the aggregate until it is reestablished.
	- reduces the chances that the reestablishment of the aggregate		- reduces the chances that the reestablishment of the aggregate
	will reserve an inefficient amount of bandwidth, causing the		will reserve an inefficient amount of bandwidth, causing the
	likely preemption of more individual flows at the aggregator		likely preemption of more individual flows at the aggregator
	than would be necessary had the aggregator had more information		than would be necessary had the aggregator had more information
	(that RSVP does not provide at this time)		(that RSVP does not provide at this time)
	During reestablishment of the aggregation in Figure 2. (without any		During reestablishment of the aggregation in Figure 2 (without any
	modification to RSVP), R8 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,		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		and have to wait for the error that not that much bandwidth was
	available; it could request too little bandwidth and have that		available; it could request too little bandwidth and have that
	aggregation accepted, but this would meant that more individual		aggregation accepted, but this would mean that more individual flows
	flows would need to be preempted outside the aggregate than were		would need to be preempted outside the aggregate than were necessary,
	necessary, leading to inefficiencies in the opposite direction.		leading to inefficiencies in the opposite direction.
	4. Requirements for Reservation Reduction		4. Requirements for Reservation Reduction
	The following are the requirements to reduce the bandwidth of a		The following are the requirements to reduce the bandwidth of a
	reservation. This applies to both individual and aggregate		reservation. This applies to both individual and aggregate
	reservations:		reservations:
	Req#1 - MUST have the ability to differentiate one reservation from		Req#1 - MUST have the ability to differentiate one reservation from
	another. In the case of aggregates, it MUST distinguish one		another. In the case of aggregates, it MUST distinguish one
	aggregate from other flows.		aggregate from other flows.
	Req#2 - MUST have the ability to indicate within an RSVP error		Req#2 - MUST have the ability to indicate within an RSVP error
	message (generated at the router with the congested		message (generated at the router with the congested
	interface) that a specific reservation (individual or		interface) that a specific reservation (individual or
	aggregate) is to be reduced in bandwidth.		aggregate) is to be reduced in bandwidth.
	Req#3 - MUST have the ability to indicate within the same error		Req#3 - MUST have the ability to indicate within the same error
	message the new maximum amount of bandwidth that is		message the new maximum amount of bandwidth that is available
	available to be utilized within the existing reservation,		to be utilized within the existing reservation, but no more.
	but no more.
	Req#4 - MUST NOT produce a case in which retransmitted reduction		Req#4 - MUST NOT produce a case in which retransmitted reduction
	indications further reduce the bandwidth of a reservation.		indications further reduce the bandwidth of a reservation.
	Any additional reduction in bandwidth for a specified		Any additional reduction in bandwidth for a specified
	reservation MUST be signaled in a new message.		reservation MUST be signaled in a new message.
	RSVP messages are unreliable and can get lost. This specification		RSVP messages are unreliable and can get lost. This specification
	should not compound any error in the network. If a reduction		should not compound any error in the network. If a reduction message
	message were lost, another one needs to be sent. If the receiver		were lost, another one needs to be sent. If the receiver ends up
	ends up receiving two copies to reduce the bandwidth of a		receiving two copies to reduce the bandwidth of a reservation by some
	reservation by some amount, it is likely the router will reduce the		amount, it is likely the router will reduce the bandwidth by twice
	bandwidth by twice the amount than was actually called for. This		the amount that was actually called for. This will be in error.
	will be in error.
	5. RSVP Bandwidth Reduction Solution		5. RSVP Bandwidth Reduction Solution
	When a reservation is partially failed, a ResvErr (Reservation		When a reservation is partially failed, a ResvErr (Reservation Error)
	Error) message is generated just as it is done currently with		message is generated just as it is done currently with preemptions.
	preemptions. The error spec object and the preemption_pri policy		The ERROR_SPEC object and the PREEMPTION_PRI object are included as
	object are included as well. Very few additions/changes are needed		well. Very few additions/changes are needed to the ResvErr message
	to the ResvErr message to support partial preemptions. A new error		to support partial preemptions. A new error subcode is required and
	sub code is required and is defined in section 5.1. The error		is defined in Section 5.1. The ERROR_SPEC object contained in the
	flowspec contained in the ResvErr message indicates the flowspec		ResvErr message indicates the flowspec that is reserved. The
	that is reserved and this flowspec may not match or be less than the		bandwidth indication in this flowspec SHOULD be less than the
	original reservation request. This is defined in section 5.2.		original reservation request. This is defined in Section 5.2.
	A comment about RESV message not using a reliable transport. This		A comment about RESV messages that do not use reliable transport:
	document recommends that ResvErr message be made reliable by		This document RECOMMENDS that ResvErr messages be made reliable by
	implementing mechanisms in [6].		implementing mechanisms in [6].
	The current behavior in RSVP requires a ResvTear message to be		The current behavior in RSVP requires a ResvTear message to be
	transmitted upstream when the ResvErr message is transmitted		transmitted upstream when the ResvErr message is transmitted
	downstream (per [1]). This ResvTear message terminates the		downstream (per [1]). This ResvTear message terminates the
	reservation in all routers upstream of the router where the failure		reservation in all routers upstream of the router where the failure
	occurred. This document requires that the ResvTear is only		occurred. This document requires that the ResvTear is only generated
	generated when the reservation is to be completely removed. In cases		when the reservation is to be completely removed. In cases where the
	where the reservation is only to be reduced, routers compliant with		reservation is only to be reduced, routers compliant with this
	this specification requires that the ResvTear message MUST NOT be		specification require that the ResvTear message MUST NOT be sent.
	sent.
	An appendix has been written to walk through the overall solution to		The appendix has been written to walk through the overall solution to
	the problems presented in sections 2 and 3. There is mention of		the problems presented in Sections 2 and 3. There is mention of this
	this ResvTear transmission behavior within the appendix.		ResvTear transmission behavior in the appendix.
	5.1 Partial Preemption Error Code		5.1. Partial Preemption Error Code
	The ResvErr message generated due to preemption includes the Error		The ResvErr message generated due to preemption includes the
	Spec object as well as the Preemption Priority Policy object. The		ERROR_SPEC object as well as the PREEMPTION_PRI object. The format
	format of Error-spec objects is defined in [1]. The error code		of ERROR_SPEC objects is defined in [1]. The error code listed in
	listed in the ERROR_SPEC object for preemption [5] currently is as		the ERROR_SPEC object for preemption [5] currently is as follows:
	follows:
	Errcode = 2 (Policy Control Failure) and		Errcode = 2 (Policy Control Failure) and
	ErrSubCode = 5 (ERR_PREEMPT)		ErrSubCode = 5 (ERR_PREEMPT)
	The following error code is suggested in the Error_spec object for		The following error code is suggested in the ERROR_SPEC object for
	partial preemption:		partial preemption:
	Errcode = 2 (Policy Control Failure) and		Errcode = 2 (Policy Control Failure) and
	ErrSubCode = X (ERR_PARTIAL_PREEMPT)		ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)
	Where 'X' is the number assigned by IANA for this error code		There is also an error code in the PREEMPTION-PRI object. This error
	There is also an error code in the preemption-pri policy object.		code takes a value of 1 to indicate that the admitted flow was
	This error code takes a value of 1 to indicate that the admitted		preempted [3]. The same error value of 1 may be used for the partial
	flow was preempted [3]. The same error value of 1 may be used for		preemption case as well.
	the partial preemption case as well.
	5.2 Error Flow Descriptor		5.2. Error Flow Descriptor
	The error flow descriptor is defined in [1] & [7]. In the case of		The error flow descriptor is defined in [1] and [7]. In the case of
	partial failure, the flowspec contained in the error flow		partial failure, the flowspec contained in the error flow descriptor
	descriptor indicates the highest average and peak rates that the		indicates the highest average and peak rates that the preempting
	preempting system can accept in the next RESV message. The		system can accept in the next RESV message. The deaggregator must
	deaggregator must reduce its reservation to a number less than or		reduce its reservation to a number less than or equal to that,
	equal to that, whether by changing codecs, by dropping reservations,		whether by changing codecs, dropping reservations, or some other
	or some other mechanism.		mechanism.
	5.3 Individual Reservation Flow Reduction		5.3. Individual Reservation Flow Reduction
	When a router requires part of the bandwidth that has been allocated		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		to a reservation be used for another flow, the router engages in the
	partial-reduction of bandwidth as described in this document. The		partial reduction of bandwidth as described in this document. The
	router sends a ResvErr downstream to indicate the partial error with		router sends a ResvErr downstream to indicate the partial error with
	the error code and sub code as described in section 5.1. The		the error code and subcode as described in section 5.1. The flowspec
	flowspec contained in the ResvErr message will be used to indicate		contained in the ResvErr message will be used to indicate the
	the bandwidth that is currently allocated.		bandwidth that is currently allocated.
	The requesting endpoint that receives the ResvErr can then negotiate		The requesting endpoint that receives the ResvErr can then negotiate
	with the transmitting endpoint to lower the bandwidth requirement		with the transmitting endpoint to lower the bandwidth requirement (by
	(by selecting another lower bandwidth codec, for example). After the		selecting another lower bandwidth codec, for example). After the
	negotiations, both endpoints will issue the RSVP PATH and RESV		negotiations, both endpoints will issue the RSVP PATH and RESV
	message with the new, lowered bandwidth.		message with the new, lowered bandwidth.
	5.4 Aggregation Reduction of Individual Flows		5.4. Aggregation Reduction of Individual Flows
	When a partial-failure occurs in a aggregation scenario, the		When a partial failure occurs in an aggregation scenario, the
	deaggregator receives the ResvErr message with the reduction		deaggregator receives the ResvErr message with the reduction
	indication from a router in the path of the aggregate. It then		indication from a router in the path of the aggregate. It then
	decides whether one or more individual flows from the aggregate are		decides whether one or more individual flows from the aggregate are
	to be affected by this ResvErr message. The following choices are		to be affected by this ResvErr message. The following choices are
	possible:		possible:
	o If that (deaggregator) router determines one or more individual		o If that (deaggregator) router determines that one or more
	flow(s) are to partially failed, then it sends a ResvErr message		individual flow(s) are to partially failed, then it sends a
	with a reduced bandwidth indication to those individual flow(s).		ResvErr message with a reduced bandwidth indication to those
	This is as per the descriptions in the previous section (5.3).		individual flow(s). This is as per the descriptions in the
			previous section (5.3).
	o If that (deaggregator) router determines one individual flow is to		o If that (deaggregator) router determines that one individual flow
	be preempted to satisfy the aggregate ResvErr, it determines which		is to be preempted to satisfy the aggregate ResvErr, it determines
	flow is affected. That router transmits a new ResvErr message		which flow is affected. That router transmits a new ResvErr
	downstream per [3]. That same router transmits a ResvTear message		message downstream per [3]. That same router transmits a ResvTear
	upstream. This ResvTear message of an individual flow does not		message upstream. This ResvTear message of an individual flow
	tear down the aggregate. Only the individual flow is affected.		does not tear down the aggregate. Only the individual flow is
			affected.
	o If that (deaggregator) router determines multiple individual flows		o If that (deaggregator) router determines that multiple individual
	are to be preempted to satisfy the aggregate ResvErr, it chooses		flows are to be preempted to satisfy the aggregate ResvErr, it
	which flows are affected. That router transmits a new ResvErr		chooses which flows are affected. That router transmits a new
	message downstream as per [3] to each individual flow. The router		ResvErr message downstream as per [3] to each individual flow.
	also transmits ResvTear messages upstream for the same individual		The router also transmits ResvTear messages upstream for the same
	flows. These ResvTear messages of an individual flow do not tear		individual flows. These ResvTear messages of an individual flow
	down the aggregate. Only the individual flows are affected.		do not tear down the aggregate. Only the individual flows are
			affected.
	In all cases, the Deaggregator lowers the bandwidth requested in the		In all cases, the deaggregator lowers the bandwidth requested in the
	Aggregate Resv message to reflect the change.		Aggregate Resv message to reflect the change.
	Which particular flow or series of flows within an aggregate are		Which particular flow or series of flows within an aggregate are
	picked by the deaggregator for bandwidth reduction or preemption is		picked by the deaggregator for bandwidth reduction or preemption is
	outside the scope of this document.		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		RFC 2207 (per [8]) specifies how RSVP reservations function in IPsec
	data flows. The nodes initiating the IPSec flow can be an end-		data flows. The nodes initiating the IPsec flow can be an end-system
	system like a computer, or it can router between two end-systems, or		like a computer, or it can router between two end-systems, or it can
	it can be an in-line bulk encryption device immediately adjacent to		be an in-line bulk encryption device immediately adjacent to a router
	a router interface, [11] directly addresses this later scenario.		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		different from non-encrypted flows, but how the reduction mechanism
	specified within this document functions is not.		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		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		be a series of individual flows or disjointed best-effort packets
	between two systems. But to this specification, this tunnel is an		between two systems. But to this specification, this tunnel is an
	individual RSVP reservation.		individual RSVP reservation.
	Anywhere within this specification that mentions an individual		Anywhere within this specification that mentions an individual
	reservation flow, the same rules of bandwidth reduction and		reservation flow, the same rules of bandwidth reduction and
	preemption MUST apply.		preemption MUST apply.
	5.6 Reduction of Multiple Flows at Once		5.6. Reduction of Multiple Flows at Once
	As a cautionary note, bandwidth SHOULD NOT be reduced across		As a cautionary note, bandwidth SHOULD NOT be reduced across multiple
	multiple reservations at the same time, in reaction to the same		reservations at the same time, in reaction to the same reduction
	reduction event. A router not knowing the impact of reservation		event. A router not knowing the impact of reservation bandwidth
	bandwidth reduction on more than one flow may cause more wide spread		reduction on more than one flow may cause more widespread ill effects
	ill effects than is necessary.		than is necessary.
	This says nothing to a policy where preemption should or should not		This says nothing to a policy where preemption should or should not
	occur across multiple flows.		occur across multiple flows.
	6. Backwards Compatibility		6. Backwards Compatibility
	Backwards compatibility with this extension will result in RSVP		Backwards compatibility with this extension will result in RSVP
	operating as it does without this extension, and no worse. The two		operating as it does without this extension, and no worse. The two
	routers involved in this extension are the router that had the		routers involved in this extension are the router that had the
	congested interface and the furthest downstream router that		congested interface and the furthest downstream router that
	determines what to do with the reduction indication.		determines what to do with the reduction indication.
	In the case of the router that experiences congestion or otherwise		In the case of the router that experiences congestion or otherwise
	needs to reduce the bandwidth of an existing reservation:		needs to reduce the bandwidth of an existing reservation:
	- If that router supports this extension:		- If that router supports this extension:
	#1 - it generates the ResvErr message with the error code		#1 - it generates the ResvErr message with the error code
	indicating the reduction in bandwidth		indicating the reduction in bandwidth.
	#2 - it does not generate the ResvTear message		#2 - it does not generate the ResvTear message.
	- If that router does not support this extension, it generates both		- If that router does not support this extension, it generates both
	ResvErr and ResvTear messages according to [1].		ResvErr and ResvTear messages according to [1].
	In the case of the router at the extreme downstream of a reservation		In the case of the router at the extreme downstream of a reservation
	that receives the ResvErr message with the reduction indication		that receives the ResvErr message with the reduction indication:
	- If that router does support this extension:		- If that router does support this extension:
	#1 - it processes this error message and applies whatever local		#1 - it processes this error message and applies whatever local
	policy it is configured to do to determine how to reduce the		policy it is configured to do to determine how to reduce the
	bandwidth of this designated flow		bandwidth of this designated flow.
	- If the router does not support this extension:		- If the router does not support this extension:
	#1 - it processes the ResvErr message according to [1] and all		#1 - it processes the ResvErr message according to [1] and all
	extensions it is able to understand, but not this extension		extensions it is able to understand, but not this extension
	from this document.		from this document.
	Thus, this extension does not cause ill effects within RSVP if one		Thus, this extension does not cause ill effects within RSVP if one or
	or more routers support this extension, and one or more routers do		more routers support this extension, and one or more routers do not
	not support this extension.		support this extension.
	7. Security Considerations		7. Security Considerations
	This document does not lessen the overall security of RSVP or of		This document does not lessen the overall security of RSVP or of
	reservation flows through an aggregate.		reservation flows through an aggregate.
	If this specification is implemented poorly - which is never		If this specification is implemented poorly - which is never
	intended, but is a consideration - the following issues may arise:		intended, but is a consideration - the following issues may arise:
	1) If the ResvTear messages are transmitted initially (at the same		1) If the ResvTear messages are transmitted initially (at the same
	time as the ResvErr messages indicating a reduction in bandwidth		time as the ResvErr messages indicating a reduction in bandwidth
	is necessary), all upstream routers will tear down the entire		is necessary), all upstream routers will tear down the entire
	reservation. This will free up the total amount of bandwidth of		reservation. This will free up the total amount of bandwidth of
	this reservation inadvertently. This may cause the re-		this reservation inadvertently. This may cause the re-
	establishment of an otherwise good reservation to fail. This has		establishment of an otherwise good reservation to fail. This has
	the most severe affects on an aggregate that has many individual		the most severe affects on an aggregate that has many individual
	flows that would have remained operational.		flows that would have remained operational.
	2) Just as RSVP has the vulnerability of premature termination of		2) Just as RSVP has the vulnerability of premature termination of
	valid reservations by rouge flows without authentication		valid reservations by rogue flows without authentication [12, 13],
	[12 & 13], this mechanism will have the same vulnerability.		this mechanism will have the same vulnerability. Usage of RSVP
	Usage of RSVP authentication mechanisms is encouraged.		authentication mechanisms is encouraged.
	8. IANA Considerations		8. IANA Considerations
	IANA is to assign the following from RFC [XXXX] (i.e. this		The IANA has assigned the following from RFC 4495 (i.e., this
	document):		document):
	The following error code is to be defined in the Error_spec object		The following error code has been defined in the ERROR_SPEC object
	for partial reservation failure under "Errcode = 2 (Policy Control		for partial reservation failure under "Errcode = 2 (Policy Control
	Failure)":		Failure)":
	ErrSubCode = X (ERR_PARTIAL_PREEMPT)		ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)
	Where 'X' is assigned by IANA for this error code
	The behavior of this ErrSubCode is defined in this document.		The behavior of this ErrSubCode is defined in this document.
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank Fred Baker for contributing text and		The authors would like to thank Fred Baker for contributing text and
	guidance in this effort and to Roger Levesque and Francois Le		guidance in this effort and to Roger Levesque and Francois Le
	Faucheur for helpful comments.		Faucheur for helpful comments.
	Appendix 1. Walking Through the Solution		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.
			[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.
			Appendix A. Walking through the Solution
	Here is a concise explanation of roughly how RSVP behaves with the		Here is a concise explanation of roughly how RSVP behaves with the
	solution to the problems presented in sections 2 & 3 of this		solution to the problems presented in Sections 2 and 3 of this
	document. There is no normative text in this appendix.		document. There is no normative text in this appendix.
	Here is a duplicate of Figure 2 from section 3 of the document body		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).		(to bring it closer to the detailed description of the solution).
	Aggregator of X Deaggregator of X		Aggregator of X Deaggregator of X
	| |		| |
	V V		V V
	+------+ +------+ +------+ +------+		+------+ +------+ +------+ +------+
	Flow 1-->| | | | | | | |--> Flow 1		Flow 1-->| | | | | | | |--> Flow 1
	skipping to change at page 14, line 42		skipping to change at page 18, line 4
	Flow B-->| | V | | | | V | |--> Flow B		Flow B-->| | V | | | | V | |--> Flow B
	Flow C-->| |::>| | | |::>| |--> Flow C		Flow C-->| |::>| | | |::>| |--> Flow C
	Flow D-->| | | | | | | |--> Flow D		Flow D-->| | | | | | | |--> Flow D
	Flow E-->| R5 | | R6 | | R7 | | R8 |--> Flow E		Flow E-->| R5 | | R6 | | R7 | | R8 |--> Flow E
	+------+ +------+ +------+ +------+		+------+ +------+ +------+ +------+
	^ ^		^ ^
	| |		| |
	Aggregator of Y Deaggregator of Y		Aggregator of Y Deaggregator of Y
	Duplicate of Figure 2. Generic RSVP Aggregate Topology		Duplicate of Figure 2. Generic RSVP Aggregate Topology
			Looking at Figure 2, aggregate X (with five 80 kbps flows) traverses:
	Looking at Figure 2., aggregate X (with five 80kbps flows)
	traverses:
	R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4		R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4
	And aggregate Y (with five 80kbps flows) traverses:		And aggregate Y (with five 80kbps flows) traverses:
	R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8		R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
	Both aggregates are 400kbps. This totals 800kbps at Interface-7 in		Both aggregates are 400 kbps. This totals 800 kbps at Int 7 in R10,
	R10, which is the maximum bandwidth RSVP has access to at this		which is the maximum bandwidth that RSVP has access to at this
	interface. Signaling messages still traverse the interface without		interface. Signaling messages still traverse the interface without
	problem. Aggregate X is at a higher relative priority than		problem. Aggregate X is at a higher relative priority than aggregate
	aggregate Y. Local policy in this example is for higher relative		Y. Local policy in this example is for higher relative priority
	priority flows to preempt lower priority flows during times of		flows to preempt lower-priority flows during times of congestion.
	congestion. The following points describe the flow when aggregate A		The following points describe the flow when aggregate A is increased
	is increased to include flow 9.		to include Flow 9.
	o When flow 9 (at 80kbps) is added to aggregate X, R1 will		o When Flow 9 (at 80 kbps) is added to aggregate X, R1 will initiate
	initiate the PATH message towards the destination endpoint of		the PATH message towards the destination endpoint of the flow.
	the flow. This hop-by-hop message will take it through R2,		This hop-by-hop message will take it through R2, R10, R11, R3, and
	R10, R11, R3 and R4 which is the aggregate X path (that		R4, which is the aggregate X path (that was built per [2] from the
	was built per [2] from the aggregate's initial set up) to the		aggregate's initial setup) to the endpoint node.
	endpoint node.
	o In response, R4 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		(defined behavior per [1]). This RESV from the deaggregator
	indicates an increase bandwidth sufficient to accommodate the		indicates an increase bandwidth sufficient to accommodate the
	existing 5 flows (1,2,3,4,5) and the new flow (9) [as stated in		existing 5 flows (1, 2, 3, 4, and 5) and the new flow (9), as
	2].		stated in [2].
	o As mentioned before, in this example, Int8 in R 10 can only		o As mentioned before, in this example, Int8 in R 10 can only
	accommodate 800kbps, and aggregates X and Y have each already		accommodate 800kbps, and aggregates X and Y have each already
	established 400kbps flows comprised of five 80kbps individual		established 400kbps flows comprised of five 80kbps individual
	flows. Therefore, R10 (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		event in this example) must make a decision about this new
	congestion generating condition in regard to the RESV message		congestion generating condition in regard to the RESV message
	received at Int8.		received at Int8.
	o Local Policy in this scenario is to preempt lower priority		o Local policy in this scenario is to preempt lower-priority
	reservations to place higher priority reservations. This would		reservations to place higher-priority reservations. This would
	normally cause all of aggregate Y to be preempted just to		normally cause all of aggregate Y to be preempted just to
	accommodate aggregate X's request for an additional 80kbps.		accommodate aggregate X's request for an additional 80kbps.
	o This document defines how aggregate Y is not completely		o This document defines how aggregate Y is not completely preempted,
	preempted, but reduced in bandwidth by 80kbps. This is		but reduced in bandwidth by 80 kbps. This is contained in the
	contained in the ResvErr message that R10 generates		ResvErr message that R10 generates (downstream) towards R11, R7,
	(downstream) towards R11, R7 and R8. See section 5 for		and R8. See section 5 for the details of the error message.
	the details of the error message.
	o Normal operation of RSVP is to have the router that generates a		o Normal operation of RSVP is to have the router that generates a
	ResvErr message downstream to also generate a ResvTear message		ResvErr message downstream to also generate a ResvTear message
	upstream (in the opposite direction towards R5). The ResvTear		upstream (in the opposite direction, i.e., towards R5). The
	message terminates an individual flow or aggregate flow. This		ResvTear message terminates an individual flow or aggregate flow.
	document calls for that message to not be sent on any partial		This document calls for that message not to be sent on any partial
	failure of reservation.		failure of reservation.
	o R8 is the deaggregator of aggregate Y. The deaggregator		o R8 is the deaggregator of aggregate Y. The deaggregator controls
	controls all the parameters of an aggregate reservation. This		all the parameters of an aggregate reservation. This will be the
	will be the node that reduces the necessary bandwidth of the		node that reduces the necessary bandwidth of the aggregate as a
	aggregate as a response to the reception of an ResvErr message		response to the reception of an ResvErr message (from R10)
	(from R10) indicating such an action is called for. In this		indicating such an action is called for. In this example,
	example, bandwidth reduction is accomplished by preempting an		bandwidth reduction is accomplished by preempting an individual
	individual flow within the aggregate (perhaps picking on Flow D		flow within the aggregate (perhaps picking on Flow D for
	for individual preemption by generating a ResvErr downstream on		individual preemption by generating a ResvErr downstream on that
	that individual flow).		individual flow).
	o At the same time, a ResvTear message is transmitted upstream on		o At the same time, a ResvTear message is transmitted upstream on
	that individual flow (Flow D) by R8. 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		aggregate directly, but is an indication to the routers (and the
	source end-system) which individual flow is to be preempted.		source end-system) which individual flow is to be preempted.
	o Once R8 preempts whichever individual flow (or 'bandwidth' at		o Once R8 preempts whichever individual flow (or 'bandwidth' at the
	the aggregate ingress), it transmits a new RESV message for that		aggregate ingress), it transmits a new RESV message for that
	aggregate (Y), 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		deaggregator indicates a decrease in bandwidth sufficient to
	accommodate the remaining 4 flows (A,B,C,E), which is now		accommodate the remaining 4 flows (A, B, C, and E), which is now
	320kbps (in this example).		320kbps (in this example).
	o This RESV message travels the entire path of the reservation,		o This RESV message travels the entire path of the reservation,
	resetting all routers to this new aggregate bandwidth value.		resetting all routers to this new aggregate bandwidth value. This
	This should be what is necessary to prevent a ResvTear message		should be what is necessary to prevent a ResvTear message from
	from being generated by R10 towards R6 and R5.		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.
	10. References
	10.1 Normative References
	[1] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
	"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
	Specification", RFC 2205, September 1997
	[2] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of
	RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001
	[3] S. Herzog, "Signaled Preemption Priority Policy Element", RFC
	3181, October 2001
	[4] Bradner S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997
	[5] S. Herzog, "RSVP Extensions for Policy Control", RFC 2750,
	January 2000
	[6] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini,
	"RSVP Refresh Overhead Reduction Extensions" RFC 2961, April 2001
	[7] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
	RFC 2210, September 1997
	[8] L. Berger, T. O'Malley, "RSVP Extensions for IPSEC Data Flows",
	RFC 2207, September 1997
	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,
	July 2005, "work in progress"
	[12] F. Baker, B. Lindell, M. Talwar, "RSVP Cryptographic
	Authentication", RFC 2747, January 2000
	[13] R. Braden, L. Zhang, "RSVP Cryptographic Authentication --		R5 will not know through this RESV message which individual flow was
	Updated Message Type Value", RFC 3097, April 2001		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.
	Author Information		Authors' Addresses
	James M. Polk		James M. Polk
	Cisco Systems		Cisco Systems
	2200 East President George Bush Turnpike		2200 East President George Bush Turnpike
	Richardson, Texas 75082 USA		Richardson, Texas 75082 USA
	Email: jmpolk@cisco.com		EMail: jmpolk@cisco.com
	Subha Dhesikan		Subha Dhesikan
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134 USA		San Jose, CA 95134 USA
	Email: sdhesika@cisco.com		EMail: sdhesika@cisco.com
	Intellectual Property Statement		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		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed to
	to pertain to the implementation or use of the technology described		pertain to the implementation or use of the technology described in
	in this document or the extent to which any license under such		this document or the extent to which any license under such rights
	rights might or might not be available; nor does it represent that		might or might not be available; nor does it represent that it has
	it has made any independent effort to identify any such rights.		made any independent effort to identify any such rights. Information
	Information on the procedures with respect to rights in RFC		on the procedures with respect to rights in RFC documents can be
	documents can be found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use of
	of such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository at
	at http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity		Acknowledgement
	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 (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:
	July 24th, 2006		Funding for the RFC Editor function is provided by the IETF
			Administrative Support Activity (IASA).
End of changes. 110 change blocks.
	416 lines changed or deleted		390 lines changed or added
This html diff was produced by rfcdiff 1.30. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/