draft-ietf-tsvwg-rsvp-bw-reduction-01.txt		draft-ietf-tsvwg-rsvp-bw-reduction-02.txt
	Transport Area Working Group James Polk		Transport Area Working Group James Polk
	Internet Draft Subha Dhesikan		Internet Draft Subha Dhesikan
	Expiration: March 8th, 2005 Cisco Systems		Expiration: July 24th, 2005 Cisco Systems
	File: draft-ietf-tsvwg-rsvp-bw-reduction-01.txt September 8th, 2005		File: draft-ietf-tsvwg-rsvp-bw-reduction-02.txt January 24th, 2005
	A Resource Reservation Protocol Extension for the		A Resource Reservation Protocol 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		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 8th, 2006.		This Internet-Draft will expire on July 24th, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2006). All Rights Reserved.
	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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 4		1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 4
	1.2 Changes From Previous Versions . . . . . . . . . . . . . 4		2. Individual Reservation Reduction Scenario . . . . . . . . . . 4
	2. Individual Reservation Reduction Scenario . . . . . . . . . . 5		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 . . . . . . . . . . . . . 10		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 . . . . . . . 11		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
	6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12		6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	Appendix. Walking Through the Solution . . . . . . . . . . . . . 14		Appendix. Walking Through the Solution . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1 Normative References . . . . . . . . . . . . . . . . . . 17		10.1 Normative References . . . . . . . . . . . . . . . . . . 16
	10.2 Informational References . . . . . . . . . . . . . . . . 17		10.2 Informational References . . . . . . . . . . . . . . . . 17
	11. Author Information . . . . . . . . . . . . . . . . . . . . . 18		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 allocated bandwidth in lieu of tearing that reservation down when		in 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
	skipping to change at page 3, line 17		skipping to change at page 3, line 17
	terminate all the individual flows if an aggregate is torn down,		terminate all the individual flows if an aggregate is torn down,
	this event will cause packets to be discarded during aggregate		this event will cause packets to be discarded during aggregate
	reservation reestablishment. This document describes a method where		reservation reestablishment. This document describes a method where
	only the minimum required bandwidth is taken away from the lower-		only the minimum required bandwidth is taken away from the lower-
	priority aggregated reservation and the entire reservation is not		priority aggregated reservation and the entire reservation is not
	preempted. This has the advantage that only some of the microflows		preempted. This has the advantage that only some of the microflows
	making up the aggregate are affected. Without this extension, all		making up the aggregate are affected. Without this extension, all
	individual flows are affected and the deaggregator will have to		individual flows are affected and the deaggregator will have to
	attempt the reservation request with a reduced bandwidth.		attempt the reservation request with a reduced bandwidth.
	RSVP tunnels utilizing IPsec [8] also require an indication that		RSVP tunnels utilizing IPSec [8] also require an indication that
	the reservation must be reduced to a certain amount (or less). RSVP		the reservation must be reduced to a certain amount (or less). RSVP
	aggregation with IPsec Tunnels is being defined in [11], which		aggregation with IPSec Tunnels is being defined in [11], which
	should be able to take advantage of the mechanism created here in		should be able to take advantage of the mechanism created here in
	this specification.		this 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 been used. Policies for real-time traffic routinely reserve		has been used. Policies for real-time traffic routinely reserve
	capacity for routing and inelastic applications, and may distinguish		capacity for routing and inelastic applications, and may distinguish
	between voice, video, and other real time applications.		between voice, video, and other real time applications.
	skipping to change at page 4, line 11		skipping to change at page 4, line 11
	This document is intended to be classified as an 'update' to RFC		This document is intended to be classified as an 'update' to RFC
	2205 [1], as this mechanism affects the behaviors of the ResvErr and		2205 [1], as this mechanism affects the behaviors of the ResvErr and
	ResvTear indications defined in that document.		ResvTear indications defined in that 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].
	1.2 Changes from previous versions
	This is a listing of the changes that have taken place to this
	Internet Draft since the previous version:
	o Changed the filename to reflect this now being a Working Group
	item within the TSVWG
	o Added a informative reference to the new Internet Draft involving
	Aggregates inside IPsec tunnels that use RSVP
	o Made minor editorial changes to make document more concise
	o Added a new section 6 on Backwards Compatibility
	This is a listing of the changes that have taken place to this
	Internet Draft since from the Aggregation only version to the
	Reservation version:
	o Changed the filename to remove "aggregation" as the focus of the
	draft to open up this solution to a wider applicability
	o Reduced text in the introductory section to be more succinct
	o Added the use-case for this mechanism with individual reservations
	o Added the use-case for this mechanism with reservations of
	individual IPsec data flows
	o Opened up the text in the document body for this wider
	applicability
	o Mentioned why ECN is inappropriate for reducing bandwidth
	allocations of RSVP reservations.
	2. Individual Reservation Reduction Scenario		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.
	+--------------+ +--------------+		+------------+ +------------+
	| |Int 1 | |Int 7 | |		| |Int 1 | |Int 7 | |
	Flow 1===> | +----- | |------+ | Flow 1===>		Flow 1===> | +----- | |------+ | Flow 1===>
	| Rtr1 |Int 2 |===========>|Int 8 | Rtr2 |		| 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:		Figure 1. 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
	skipping to change at page 5, line 39		skipping to change at page 4, line 45
	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 to the other in one direction might not be the routed path		device to the other in one direction might not be the routed path
	for communicating between the same two endpoints in the reverse		for 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 sake.
	Figure 1. depicts 2 routers, (Rtr1 and Rtr2) initially with only one		Figure 1. depicts 2 routers, (R1 and R2) initially with only one
	flow (Flow 1). The flows are forwarded from Rtr1 to Rtr2 via		flow (Flow 1). The flows are forwarded from R1 to R2 via
	interface 2. For this example, let us say that flow 1 and flow 2		interface 2. For this example, let us say that flow 1 and flow 2
	each require 80 units of bandwidth (such as for the codec G.711 with		each require 80 units of bandwidth (such as for the codec G.711 with
	no silence suppression). Let us also say that the RSVP bandwidth		no silence suppression). Let us also say that the RSVP bandwidth
	limit for interface 2 of Rtr1 is 100 units.		limit for interface 2 of R1 is 100 units.
	As described in [3], a priority indication is established for each		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.
	skipping to change at page 6, line 36		skipping to change at page 5, line 42
	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 leads to inefficient use of available bandwidth.		it 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 this specification addresses in RSVP Aggregates. Figure 2		that this specification addresses in RSVP Aggregates. Figure 2
	consists of 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9,		consists of 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9,
	A, B, C, D, and E). Initially there will 5 flows per aggregate		A, B, C, D, and E). Initially there will 5 flows per aggregate
	(flow 9 will be introduced to cause the problem we are addressing in		(flow 9 will be introduced to cause the problem we are addressing in
	this document),with 2 aggregates (A & B); (1 through 5) in aggregate		this document),with 2 aggregates (X & Y); (1 through 5) in aggregate
	A and (A through E) in aggregate B. These 2 aggregates will cross		X and (A through E) in aggregate Y. These 2 aggregates will cross
	one router interface utilizing all available capacity (in this		one router interface utilizing all available capacity (in this
	example).		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 A Deaggregator of A		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
	Flow 5-->| | | | | | | | | |--> Flow 5		Flow 5-->| | | | | | | | | |--> Flow 5
	Flow 9 | Rtr1 | | | Rtr2 | | Rtr3 | | | Rtr4 | Flow 9		Flow 9 | R1 | | | R2 | | R3 | | | R4 | Flow 9
	+------+ | +------+ +------+ | +------+		+------+ | +------+ +------+ | +------+
	| || || |		| || || |
	Aggregate A-->|| Aggregate A ||<--Aggregate A		Aggregate X-->|| Aggregate X ||<--Aggregate X
	|| | ||		|| | ||
	+--------------+ | +--------------+		+--------------+ | +--------------+
	| |Int 7 | | |Int 1 | |		| |Int 7 | | |Int 1 | |
	| +----- | V |------+ |		| +----- | V |------+ |
	| Rtr10 |Int 8 |===========>|Int 2 | Rtr11 |		| R10 |Int 8 |===========>|Int 2 | R11 |
	| | |:::::::::::>| | |		| | |:::::::::::>| | |
	| +----- | ^ |------+ |		| +----- | ^ |------+ |
	| |Int 9 | | |Int 3 | |		| |Int 9 | | |Int 3 | |
	+--------------+ | +--------------+		+--------------+ | +--------------+
	.. | ..		.. | ..
	Aggregate B--->.. Aggregate B ..<---Aggregate B		Aggregate Y--->.. Aggregate Y ..<---Aggregate Y
	| .. .. |		| .. .. |
	+------+ | +------+ +------+ | +------+		+------+ | +------+ +------+ | +------+
	Flow A-->| | | | | | | | | |--> Flow A		Flow A-->| | | | | | | | | |--> Flow A
	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-->| Rtr5 | | Rtr6 | | Rtr7 | | Rtr8 |--> Flow E		Flow E-->| R5 | | R6 | | R7 | | R8 |--> Flow E
	+------+ +------+ +------+ +------+		+------+ +------+ +------+ +------+
	^ ^		^ ^
	| |		| |
	Aggregator of B Deaggregator of B		Aggregator of Y Deaggregator of Y
	Figure 2. Generic RSVP Aggregate Topology		Figure 2. Generic RSVP Aggregate Topology
	Figure 2 legend/rules:		Figure 2 legend/rules:
	- Aggregate A priority = 100		- Aggregate X priority = 100
	- Aggregate B 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 are
	not shown for diagram simplicity		not shown for diagram simplicity
	The path for aggregate A is:		The path for aggregate X is:
	Rtr1 => Rtr2 => Rtr10 => Rtr11 => Rtr3 => Rtr4		R1 => R2 => R10 => R11 => R3 => R4
	where aggregate A starts in Rtr1, and deaggregates in Rtr4.
			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 B is:		The path for aggregate Y is:
	Rtr5 ::> Rtr6 ::> Rtr10 ::> Rtr11 ::> Rtr7 ::> Rtr8		R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
	where aggregate B starts in Rtr5, and deaggregates in Rtr8.		where aggregate Y starts in R5, and deaggregates in R8.
	Flows A, B, C, D and E communicate through aggregate B		Flows A, B, C, D and E communicate through aggregate B
	Both aggregates share one leg or physical link: between Rtr10 and		Both aggregates share one leg or physical link: between R10 and
	Rtr11, thus they share one outbound interface: Int8 of Rtr10, where		R11, thus they share one outbound interface: Int8 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 800kbps. RSVP signaling (messages) is outside this 800kbps in		of 800kbps. RSVP signaling (messages) is outside this 800kbps in
	this example, as is any session signaling protocol like SIP.		this 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 A)		Figure 2 shows an established aggregated reservation (aggregate X)
	between the routers rtr1 and rtr4. This aggregated reservation		between the routers R1 and R4. This aggregated reservation
	consists of 5 microflows (flow 1, 2, 3, 4, 5). For the sake of this		consists of 5 microflows (flow 1, 2, 3, 4, 5). For the sake of this
	discussion, let us assume that each flow represents a voice call and		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 A request is for 400kbps (80kbps * 5 flows).		suppression). Aggregate X request is for 400kbps (80kbps * 5 flows).
	The priority of the aggregate is derived from the individual		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 through the network). There may be other ways in which the		path through the network). There may be other ways in which the
	priority of the aggregate is derived, but for this discussion it		priority of the aggregate is derived, but for this discussion it
	is sufficient to note that each aggregate contains a priority (both		is sufficient to note that each aggregate contains a priority (both
	hold and defending priority). The means of deriving the priority is		hold and defending priority). The means of deriving the priority is
	out of scope for this discussion.		out of scope for this discussion.
	Aggregate B, 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 rtr5 and ends		requires 400kbps (80kbps * 5 flows), and starts at R5 and ends
	rtr8. This means there are two aggregates occupying all 800kbps of		R8. This means there are two aggregates occupying all 800kbps of
	the RSVP capacity.		the RSVP capacity.
	When Flow 9 is added into aggregate A, this will occupy 80kbps more		When Flow 9 is added into aggregate X, this will occupy 80kbps more
	than Int8 on rtr10 has available (880k offered 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 B		[1] and [2] create a behavior in RSVP to deny the entire aggregate Y
	and all its individual flows because aggregate A 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 signal to all affected routers of aggregate B that only 80kbps is		to signal to all affected routers of aggregate Y that only 80kbps is
	needed to accommodate another (higher priority) aggregate. A		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 B		- 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), rtr8 would guess at how much bandwidth to ask		modification to RSVP), R8 would guess at how much bandwidth to ask
	for in the new RESV message. It could request too much bandwidth,		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 meant that more individual
	flows would need to be preempted outside the aggregate than were		flows would need to be preempted outside the aggregate than were
	necessary, leading to inefficiencies in the opposite direction.		necessary, 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
	skipping to change at page 11, line 4		skipping to change at page 9, line 52
	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 = X (ERR_PARTIAL_PREEMPT)
	Where 'X' is the number assigned by IANA for this error code
			Where 'X' is the number assigned by IANA for this error code
	There is also an error code in the preemption-pri policy object.		There is also an error code in the preemption-pri policy object.
	This error code takes a value of 1 to indicate that the admitted		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		flow was preempted [3]. The same error value of 1 may be used for
	the partial 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] & [7]. In the case of
	partial failure, the flowspec contained in the error flow		partial failure, the flowspec contained in the error flow
	descriptor indicates the highest average and peak rates that the		descriptor indicates the highest average and peak rates that the
	skipping to change at page 12, line 24		skipping to change at page 11, line 23
	flows. These ResvTear messages of an individual flow do not tear		flows. These ResvTear messages of an individual flow do not tear
	down the aggregate. Only the individual flows are affected.		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 like a computer, or it can router between two end-systems, or		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		it can be an in-line bulk encryption device immediately adjacent to
	a router interface, [11] directly addresses this later scenario.		a router interface, [11] directly addresses this later scenario.
	The methods of identification of an IPsec with reservation flow are		The methods of identification of an IPSec with reservation flow are
	different than non-encrypted flows, but how the reduction mechanism		different than 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
			As a cautionary note, bandwidth SHOULD NOT be reduced across
			multiple reservations at the same time, in reaction to the same
			reduction event. A router not knowing the impact of reservation
			bandwidth reduction on more than one flow may cause more wide spread
			ill effects than is necessary.
			This says nothing to a policy where preemption should or should not
			occur across multiple flows.
	6. Backwards Compatibility		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:
	skipping to change at page 13, line 43		skipping to change at page 12, line 52
	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 more routers support this extension, and one or more routers do		or more routers support this extension, and one or more routers do
	not support this extension.		not 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 issue 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
			valid reservations by rouge flows without authentication
			[12 & 13], this mechanism will have the same vulnerability.
			Usage of RSVP authentication mechanisms is encouraged.
	8. IANA Considerations		8. IANA Considerations
	IANA is to assign the following from RFC [XXXX] (this document):		IANA is to assign the following from RFC [XXXX] (i.e. this
			document):
	The following error code is to be defined in the Error_spec object		The following error code is to be 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 = X (ERR_PARTIAL_PREEMPT)
	Where 'X' is assigned by IANA for this error code		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.
	skipping to change at page 14, line 34		skipping to change at page 14, line 5
	Appendix 1. Walking Through the Solution		Appendix 1. 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 & 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 A Deaggregator of A		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
	Flow 5-->| | | | | | | | | |--> Flow 5		Flow 5-->| | | | | | | | | |--> Flow 5
	Flow 9-->| Rtr1 | | | Rtr2 | | Rtr3 | | | Rtr4 |--> Flow 9		Flow 9-->| R1 | | | R2 | | R3 | | | R4 |--> Flow 9
	+------+ | +------+ +------+ | +------+		+------+ | +------+ +------+ | +------+
	| || || |		| || || |
	Aggregate A--->|| Aggregate A ||<--Aggregate A		Aggregate X--->|| Aggregate X ||<--Aggregate X
	|| | ||		|| | ||
	+--------------+ | +--------------+		+--------------+ | +--------------+
	| |Int 7 | | |Int 1 | |		| |Int 7 | | |Int 1 | |
	| +----- | V |------+ |		| +----- | V |------+ |
	| Rtr10 |Int 8 |===========>|Int 2 | Rtr11 |		| R10 |Int 8 |===========>|Int 2 | R11 |
	| | |:::::::::::>| | |		| | |:::::::::::>| | |
	| +----- | ^ |------+ |		| +----- | ^ |------+ |
	| |Int 9 | | |Int 3 | |		| |Int 9 | | |Int 3 | |
	+--------------+ | +--------------+		+--------------+ | +--------------+
	.. | ..		.. | ..
	Aggregate B--->.. Aggregate B ..<---Aggregate B		Aggregate Y--->.. Aggregate Y ..<---Aggregate Y
	| .. .. |		| .. .. |
	+------+ | +------+ +------+ | +------+		+------+ | +------+ +------+ | +------+
	Flow A-->| | | | | | | | | |--> Flow A		Flow A-->| | | | | | | | | |--> Flow A
	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-->| Rtr5 | | Rtr6 | | Rtr7 | | Rtr8 |--> Flow E		Flow E-->| R5 | | R6 | | R7 | | R8 |--> Flow E
	+------+ +------+ +------+ +------+		+------+ +------+ +------+ +------+
	^ ^		^ ^
	| |		| |
	Aggregator of B Deaggregator of B		Aggregator of Y Deaggregator of Y
	Duplicate of Figure 2. Generic RSVP Aggregate Topology		Duplicate of Figure 2. Generic RSVP Aggregate Topology
	Looking at Figure 2., aggregate A (with five 80kbps flows)		Looking at Figure 2., aggregate X (with five 80kbps flows)
	traverses:		traverses:
	Rtr1 ==> Rtr2 ==> Rtr10 ==> Rtr11 ==> Rtr3 ==> Rtr4		R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4
	And aggregate B (with five 80kbps flows) traverses:		And aggregate Y (with five 80kbps flows) traverses:
	Rtr5 ::> Rtr6 ::> Rtr10 ::> Rtr11 ::> Rtr7 ::> Rtr8		R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
	Both aggregates are 400kbps. This totals 800kbps at Interface-7 in		Both aggregates are 400kbps. This totals 800kbps at Interface-7 in
	Rtr10, which is the maximum bandwidth RSVP has access to at this		R10, which is the maximum bandwidth RSVP has access to at this
	interface. Signaling messages still traverse the interface without		interface. Signaling messages still traverse the interface without
	problem. Aggregate A is at a higher relative priority than		problem. Aggregate X is at a higher relative priority than
	aggregate B. Local policy in this example is for higher relative		aggregate Y. Local policy in this example is for higher relative
	priority flows to preempt lower priority flows during times of		priority flows to preempt lower priority flows during times of
	congestion. The following points describe the flow when aggregate A		congestion. The following points describe the flow when aggregate A
	is increased to include flow 9.		is increased to include flow 9.
	o When flow 9 (at 80kbps) is added to aggregate A, Rtr1 will		o When flow 9 (at 80kbps) is added to aggregate X, R1 will
	initiate the PATH message towards the destination endpoint of		initiate the PATH message towards the destination endpoint of
	the flow. This hop-by-hop message will take it through Rtr2,		the flow. This hop-by-hop message will take it through R2,
	Rtr10, Rtr11, Rtr3 and Rtr4 which is the aggregate A path (that		R10, R11, R3 and R4 which is the aggregate X path (that
	was built per [2] from the aggregate's initial set up) to the		was built per [2] from the aggregate's initial set up) to the
	endpoint node.		endpoint node.
	o In response, Rtr4 will generate the RESV (reservation) message		o In response, R4 will generate the RESV (reservation) message
	[defined behavior per 1]. This RESV from the deaggregator		[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,5) and the new flow (9) [as stated in
	2].		2].
	o As mentioned before, in this example, Int8 in RTR 10 can only		o As mentioned before, in this example, Int8 in R 10 can only
	accommodate 800kbps, and aggregates A and B 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, Rtr10 (the interface that detects a congestion		flows. Therefore, R10 (the interface that detects a congestion
	event in this example) must make a decision about this new		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 B to be preempted just to		normally cause all of aggregate Y to be preempted just to
	accommodate aggregate A's request for an additional 80kbps.		accommodate aggregate X's request for an additional 80kbps.
	o This document defines how aggregate B is not completely		o This document defines how aggregate Y is not completely
	preempted, but reduced in bandwidth by 80kbps. This is		preempted, but reduced in bandwidth by 80kbps. This is
	contained in the ResvErr message that Rtr10 generates		contained in the ResvErr message that R10 generates
	(downstream) towards Rtr11, Rtr7 and Rtr8. See section 5 for		(downstream) towards R11, R7 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 Rtr5). The ResvTear		upstream (in the opposite direction towards R5). The ResvTear
	message terminates an individual flow or aggregate flow. This		message terminates an individual flow or aggregate flow. This
	document calls for that message to not be sent on any partial		document calls for that message to not be sent on any partial
	failure of reservation.		failure of reservation.
	o Rtr8 is the deaggregator of aggregate B. The deaggregator		o R8 is the deaggregator of aggregate Y. The deaggregator
	controls all the parameters of an aggregate reservation. This		controls all the parameters of an aggregate reservation. This
	will be the node that reduces the necessary bandwidth of the		will be the node that reduces the necessary bandwidth of the
	aggregate as a response to the reception of an ResvErr message		aggregate as a response to the reception of an ResvErr message
	(from Rtr10) indicating such an action is called for. In this		(from R10) indicating such an action is called for. In this
	example, bandwidth reduction is accomplished by preempting an		example, bandwidth reduction is accomplished by preempting an
	individual flow within the aggregate (perhaps picking on Flow D		individual flow within the aggregate (perhaps picking on Flow D
	for individual preemption by generating a ResvErr downstream on		for individual preemption by generating a ResvErr downstream on
	that individual flow).		that 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 Rtr8. This will not affect the		that individual flow (Flow D) by R8. This will not affect the
	aggregate directly, but is an indication to the routers (and the		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 Rtr8 preempts whichever individual flow (or 'bandwidth' at		o Once R8 preempts whichever individual flow (or 'bandwidth' at
	the aggregate ingress), it transmits a new RESV message for that		the aggregate ingress), it transmits a new RESV message for that
	aggregate (B), not for a new aggregate. This RESV from the		aggregate (Y), not for a new aggregate. This RESV from the
	deaggregator indicates an decrease in bandwidth sufficient to		deaggregator indicates an 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,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 should be what is necessary to prevent a ResvTear message		This should be what is necessary to prevent a ResvTear message
	from being generated by Rtr10 towards Rtr6 and Rtr5.		from being generated by R10 towards R6 and R5.
	Rtr5 will not know through this RESV message which individual flow		R5 will not know through this RESV message which individual flow
	was preempted. If in this example, Rtr8 was given more bandwidth to		was preempted. If in this example, R8 was given more bandwidth to
	keep, it might have transmitted a bandwidth reduction ResvErr		keep, it might have transmitted a bandwidth reduction ResvErr
	indication towards the end-system of Flow D. In that case, a voice		indication towards the end-system of Flow D. In that case, a voice
	signaling protocol (such as SIP) could have attempted a		signaling protocol (such as SIP) could have attempted a
	renegotiation of that individual flow to a reduced bandwidth (say,		renegotiation of that individual flow to a reduced bandwidth (say,
	but changing the voice codec from G.711 to G. 729). This could have		but changing the voice codec from G.711 to G. 729). This could have
	saved Flow D from preemption.		saved Flow D from preemption.
	10. References		10. References
	10.1 Normative References		10.1 Normative References
	skipping to change at page 17, line 50		skipping to change at page 17, line 20
	10.2 Informational References		10.2 Informational References
	[9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,		[9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
	J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:		J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, May 2002.		Session Initiation Protocol", RFC 3261, May 2002.
	[10] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit		[10] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit
	Congestion Notification (ECN) to IP", RFC 3168, September 2001		Congestion Notification (ECN) to IP", RFC 3168, September 2001
	[11] F. Le Faucheur, B. Davie, P. Bose, C. Christou, " Aggregate		[11] F. Le Faucheur, B. Davie, P. Bose, C. Christou, " Aggregate
	reservations for IPsec Tunnel", draft-lefaucheur-rsvp-ipsec-01,		reservations for IPSec Tunnel", draft-lefaucheur-rsvp-ipsec-01,
	July 2005, "work in progress"		July 2005, "work in progress"
	11. Author Information		[12] F. Baker, B. Lindell, M. Talwar, "RSVP Cryptographic
			Authentication", RFC 2747, January 2000
			[13] R. Braden, L. Zhang, "RSVP Cryptographic Authentication --
			Updated Message Type Value", RFC 3097, April 2001
			Author Information
	James M. Polk		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
	skipping to change at page 19, line 7		skipping to change at page 18, line 31
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
	INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR		INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
	The Expiration date for this Internet Draft is:		The Expiration date for this Internet Draft is:
	March 8th, 2006		July 24th, 2006
End of changes. 81 change blocks.
	145 lines changed or deleted		133 lines changed or added
This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/