draft-ietf-tsvwg-rsvp-dste-02.txt		draft-ietf-tsvwg-rsvp-dste-03.txt
	RSVP Aggregation over MPLS TE tunnels February 2006
	Internet Draft Francois Le Faucheur		Internet Draft Francois Le Faucheur
	Michael DiBiasio		Editor
	Bruce Davie
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Michael Davenport		draft-ietf-tsvwg-rsvp-dste-03.txt
	Chris Christou
	Booz Allen Hamilton
	Jerry Ash
	Bur Goode
	AT&T
	draft-ietf-tsvwg-rsvp-dste-02.txt
	Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels		Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels
	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.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 2, line 4		skipping to change at page 1, line 36
	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.
	Abstract		Abstract
	RFC 3175 specifies aggregation of RSVP end-to-end reservations over		RFC 3175 specifies aggregation of RSVP end-to-end reservations over
	aggregate RSVP reservations. This document specifies aggregation of		aggregate RSVP reservations. This document specifies aggregation of
	RSVP end-to-end reservations over MPLS Traffic Engineering (TE)		RSVP end-to-end reservations over MPLS Traffic Engineering (TE)
	RSVP Aggregation over MPLS TE tunnels February 2006
	tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE)		tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE)
	Tunnels. This approach is based on RFC 3175 and simply modifies the		Tunnels. This approach is based on RFC 3175 and simply modifies the
	corresponding procedures for operations over MPLS TE tunnels instead		corresponding procedures for operations over MPLS TE tunnels instead
	of aggregate RSVP reservations. This approach can be used to achieve		of aggregate RSVP reservations. This approach can be used to achieve
	admission control of a very large number of flows in a scalable		admission control of a very large number of flows in a scalable
	manner since the devices in the core of the network are unaware of		manner since the devices in the core of the network are unaware of
	the end-to-end RSVP reservations and are only aware of the MPLS TE		the end-to-end RSVP reservations and are only aware of the MPLS TE
	tunnels.		tunnels.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Specification of Requirements		Specification of Requirements
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	1. Introduction		Table of Contents
			1. Introduction...................................................2
			2. Contributing Authors...........................................6
			3. Definitions....................................................7
			4. Operations of RSVP Aggregation over TE with pre-established
			Tunnels...........................................................8
			4.1. Reference Model...........................................9
			4.2. Receipt of E2E Path message By the Aggregator............10
			4.3. Handling of E2E Path message By Transit LSRs.............11
			4.4. Receipt of E2E Path Message by Deaggregator..............11
			4.5. Handling of E2E Resv Message by Deaggregator.............12
			4.6. Handling of E2E Resv Message by the Aggregator...........13
			4.7. Forwarding of E2E traffic by Aggregator..................14
			4.8. Removal of E2E reservations..............................14
			4.9. Removal of TE Tunnel.....................................15
			4.10. Example Signaling Flow..................................16
			5. IPv4 and IPv6 Applicability...................................17
			6. E2E Reservations Applicability................................17
			7. Example Deployment Scenarios..................................17
			7.1. Voice and Video Reservations Scenario....................17
			7.2. PSTN/3G Voice Trunking Scenario..........................18
			8. Optional Use of RSVP Proxy on RSVP Aggregator.................19
			9. Security Considerations.......................................21
			10. IANA Considerations..........................................22
			11. Acknowledgments..............................................22
			12. Normative References.........................................22
			13. Informative References.......................................23
			14. Editor's Address:............................................24
			Appendix A - Example Usage of RSVP Aggregation over DSTE Tunnels for
			VoIP Call Admission Control (CAC)................................25
			1. Introduction
	The Integrated Services (Intserv) [INT-SERV] architecture provides a		The Integrated Services (Intserv) [INT-SERV] architecture provides a
	means for the delivery of end-to-end Quality of Service (QoS) to		means for the delivery of end-to-end Quality of Service (QoS) to
	applications over heterogeneous networks.		applications over heterogeneous networks.
	[RSVP] defines the Resource reSerVation Protocol which can be used by		[RSVP] defines the Resource reSerVation Protocol which can be used by
	applications to request resources from the network. The network		applications to request resources from the network. The network
	responds by explicitely admitting or rejecting these RSVP requests.		responds by explicitely admitting or rejecting these RSVP requests.
	Certain applications that have quantifiable resource requirements		Certain applications that have quantifiable resource requirements
	express these requirements using Intserv parameters as defined in the		express these requirements using Intserv parameters as defined in the
	appropriate Intserv service specifications ([GUARANTEED],		appropriate Intserv service specifications ([GUARANTEED],
	skipping to change at page 3, line 4		skipping to change at page 3, line 31
	codepoint (DSCP) in the packet IP header. At each Diffserv router,		codepoint (DSCP) in the packet IP header. At each Diffserv router,
	packets are subjected to a "per-hop behavior" (PHB), which is invoked		packets are subjected to a "per-hop behavior" (PHB), which is invoked
	by the DSCP. The primary benefit of Diffserv is its scalability.		by the DSCP. The primary benefit of Diffserv is its scalability.
	Diffserv eliminates the need for per-flow state and per-flow		Diffserv eliminates the need for per-flow state and per-flow
	processing and therefore scales well to large networks.		processing and therefore scales well to large networks.
	However, DiffServ does not include any mechanism for communication		However, DiffServ does not include any mechanism for communication
	between applications and the network. Thus, as detailed in [INT-DIFF],		between applications and the network. Thus, as detailed in [INT-DIFF],
	significant benefits can be achieved by using Intserv over Diffserv		significant benefits can be achieved by using Intserv over Diffserv
	including resource based admission control, policy based admission		including resource based admission control, policy based admission
	RSVP Aggregation over MPLS TE tunnels February 2006
	control, assistance in traffic identification /classification and		control, assistance in traffic identification /classification and
	traffic conditioning. As discussed in [INT-DIFF], Intserv can operate		traffic conditioning. As discussed in [INT-DIFF], Intserv can operate
	over Diffserv in multiple ways. For example, the Diffserv region may		over Diffserv in multiple ways. For example, the Diffserv region may
	be statically provisioned or may be RSVP aware. When it is RSVP aware,		be statically provisioned or may be RSVP aware. When it is RSVP aware,
	several mechanisms may be used to support dynamic provisioning and		several mechanisms may be used to support dynamic provisioning and
	topology aware admission control including aggregate RSVP		topology aware admission control including aggregate RSVP
	reservations, per flow RSVP or a bandwidth broker. The advantage of		reservations, per flow RSVP or a bandwidth broker. The advantage of
	using aggregate RSVP reservations is that it offers dynamic,		using aggregate RSVP reservations is that it offers dynamic,
	topology-aware admission control over the Diffserv region without		topology-aware admission control over the Diffserv region without
	per-flow reservations and the associated level of RSVP signaling in		per-flow reservations and the associated level of RSVP signaling in
	skipping to change at page 3, line 37		skipping to change at page 4, line 12
	"aggregation region", can be mapped onto a single aggregate		"aggregation region", can be mapped onto a single aggregate
	reservation within the aggregation region. This considerably reduces		reservation within the aggregation region. This considerably reduces
	the amount of reservation state that needs to be maintained by		the amount of reservation state that needs to be maintained by
	routers within the aggregation region. Furthermore, traffic belonging		routers within the aggregation region. Furthermore, traffic belonging
	to aggregate reservations is classified in the data path purely using		to aggregate reservations is classified in the data path purely using
	Diffserv marking.		Diffserv marking.
	[MPLS-TE] describes how MPLS Traffic Engineering (TE) Tunnels can be		[MPLS-TE] describes how MPLS Traffic Engineering (TE) Tunnels can be
	used to carry arbitrary aggregates of traffic for the purposes of		used to carry arbitrary aggregates of traffic for the purposes of
	traffic engineering. [RSVP-TE] specifies how such MPLS TE Tunnels can		traffic engineering. [RSVP-TE] specifies how such MPLS TE Tunnels can
	be established using RSVP-TE signaling. . MPLS TE uses Constraint		be established using RSVP-TE signaling. MPLS TE uses Constraint Based
	Based Routing to compute the path for a TE tunnel. Then, Admission		Routing to compute the path for a TE tunnel. Then, Admission Control
	Control is performed during the establishment of TE Tunnels to ensure		is performed during the establishment of TE Tunnels to ensure they
	they are granted their requested resources.		are granted their requested resources.
	[DSTE-REQ] presents the Service Providers requirements for support of		[DSTE-REQ] presents the Service Providers requirements for support of
	Diff-Serv-aware MPLS Traffic Engineering (DS-TE). With DS-TE,		Diff-Serv-aware MPLS Traffic Engineering (DS-TE). With DS-TE,
	separate DS-TE tunnels can be used to carry different Diffserv		separate DS-TE tunnels can be used to carry different Diffserv
	classes of traffic and different resource constraints can be enforced		classes of traffic and different resource constraints can be enforced
	for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling		for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling
	extensions as well as OSPF and ISIS extensions for support of DS-TE.		extensions as well as OSPF and ISIS extensions for support of DS-TE.
	In the rest of this document we will refer to both TE tunnels and DS-		In the rest of this document we will refer to both TE tunnels and DS-
	TE tunnels simply as "TE tunnels".		TE tunnels simply as "TE tunnels".
	TE tunnels have much in common with the aggregate RSVP reservations		TE tunnels have much in common with the aggregate RSVP reservations
	used in [RSVP-AGG]:		used in [RSVP-AGG]:
	- a TE tunnel is subject to Admission Control and thus is		- a TE tunnel is subject to Admission Control and thus is
	effectively an aggregate bandwidth reservation		effectively an aggregate bandwidth reservation
	RSVP Aggregation over MPLS TE tunnels February 2006
	- In the data plane, packet scheduling relies exclusively on		- In the data plane, packet scheduling relies exclusively on
	Diff-Serv classification and PHBs		Diff-Serv classification and PHBs
	- Both TE tunnels and aggregate RSVP reservations are controlled		- Both TE tunnels and aggregate RSVP reservations are controlled
	by "intelligent" devices on the edge of the "aggregation core"		by "intelligent" devices on the edge of the "aggregation core"
	(Head-end and Tail-end in the case of TE tunnels, Aggregator		(Head-end and Tail-end in the case of TE tunnels, Aggregator
	and Deaggregator in the case of aggregate RSVP reservations		and Deaggregator in the case of aggregate RSVP reservations
	- Both TE tunnels and aggregate RSVP reservations are signaled		- Both TE tunnels and aggregate RSVP reservations are signaled
	using the RSVP protocol (with some extensions defined in [RSVP-		using the RSVP protocol (with some extensions defined in [RSVP-
	TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE		TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE
	tunnels).		tunnels).
	skipping to change at page 4, line 46		skipping to change at page 5, line 21
	with RSVP-TE and reserve resources at every hop, this can be looked		with RSVP-TE and reserve resources at every hop, this can be looked
	at as a form of aggregation of RSVP(-TE) reservations over MPLS TE		at as a form of aggregation of RSVP(-TE) reservations over MPLS TE
	Tunnels. This document capitalizes on the similarities between		Tunnels. This document capitalizes on the similarities between
	nesting of TE LSPs over TE tunnels and RSVP aggregation over TE		nesting of TE LSPs over TE tunnels and RSVP aggregation over TE
	tunnels and reuses the procedures of [LSP-HIER] wherever possible.		tunnels and reuses the procedures of [LSP-HIER] wherever possible.
	This document also builds on the "RSVP over Tunnels" concepts of RFC		This document also builds on the "RSVP over Tunnels" concepts of RFC
	2746 [RSVP-TUN]. It differs from that specification in the following		2746 [RSVP-TUN]. It differs from that specification in the following
	ways		ways
	- Whereas RFC 2746 describes operation with IP tunnels, this		- Whereas RFC 2746 describes operation with IP tunnels, this
	draft describes operation over MPLS tunnels. One consequence of		document describes operation over MPLS tunnels. One consequence
	this difference is the need to deal with penultimate hop		of this difference is the need to deal with penultimate hop
	popping (PHP).		popping (PHP).
	- MPLS-TE tunnels inherently reserve resources, whereas the		- MPLS-TE tunnels inherently reserve resources, whereas the
	tunnels in RFC 2746 do not have resource reservations by		tunnels in RFC 2746 do not have resource reservations by
	default. This leads to some simplifications in the current		default. This leads to some simplifications in the current
	draft.		document.
	- There is exactly one reservation per MPLS-TE tunnel, whereas		- There is exactly one reservation per MPLS-TE tunnel, whereas
	RFC 2746 permits many reservations per tunnel.		RFC 2746 permits many reservations per tunnel.
			- We have assumed in the current document that a given MPLS-TE
	RSVP Aggregation over MPLS TE tunnels February 2006
	- We have assumed in the current draft that a given MPLS-TE
	tunnel will carry reserved traffic and nothing but reserved		tunnel will carry reserved traffic and nothing but reserved
	traffic, which negates the requirement of RFC 2746 to		traffic, which negates the requirement of RFC 2746 to
	distinguish reserved and non-reserved traffic traversing the		distinguish reserved and non-reserved traffic traversing the
	same tunnel by using distinct encapsulations.		same tunnel by using distinct encapsulations.
	- There may be several MPLS-TE tunnels that share common head and		- There may be several MPLS-TE tunnels that share common head and
	tail end routers, with head-end policy determining which tunnel		tail end routers, with head-end policy determining which tunnel
	is appropriate for a particular flow. This scenario does not		is appropriate for a particular flow. This scenario does not
	appear to be addressed in RFC 2746.		appear to be addressed in RFC 2746.
	At the same time, this draft does have many similarities with RFC		At the same time, this document does have many similarities with RFC
	2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC		2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC
	2746:		2746:
	"		"
	The (logical) link may be able to promise that some overall		The (logical) link may be able to promise that some overall
	level of resources is available to carry traffic, but not to		level of resources is available to carry traffic, but not to
	allocate resources specifically to individual data flows.		allocate resources specifically to individual data flows.
	"		"
	Aggregation of end-to-end RSVP reservations over TE tunnels combines		Aggregation of end-to-end RSVP reservations over TE tunnels combines
	the benefits of [RSVP-AGG] with the benefits of MPLS including the		the benefits of [RSVP-AGG] with the benefits of MPLS including the
	skipping to change at page 6, line 5		skipping to change at page 6, line 32
	- the aggregate reservation (and thus the traffic from the		- the aggregate reservation (and thus the traffic from the
	corresponding end to end reservations) can be network		corresponding end to end reservations) can be network
	engineered via the use of Constraint based routing (e.g.		engineered via the use of Constraint based routing (e.g.
	affinity, optimization on different metrics) and when needed		affinity, optimization on different metrics) and when needed
	can take advantage of resources on other paths than the		can take advantage of resources on other paths than the
	shortest path		shortest path
	- the aggregate reservations (and thus the traffic from the		- the aggregate reservations (and thus the traffic from the
	corresponding end to end reservations) can be protected against		corresponding end to end reservations) can be protected against
	failure through the use of MPLS Fast Reroute		failure through the use of MPLS Fast Reroute
	RSVP Aggregation over MPLS TE tunnels February 2006
	This document, like [RSVP-AGG], covers aggregation of unicast		This document, like [RSVP-AGG], covers aggregation of unicast
	sessions. Aggregation of multicast sessions is for further study.		sessions. Aggregation of multicast sessions is for further study.
	1.1. Changes from previous versions		2. Contributing Authors
	The changes from version draft-ietf-tsvwg-rsvp-dste-01 to version		This document was the collective work of several authors. The text
	draft-ietf-tsvwg-rsvp-dste-02 are:		and content were contributed by the editor and the co-authors listed
	- clarification in text describing handling of E2E Path		below. (The contact information for the editor appears in the
	- added text on handling of E2E PathTear and ResvConf.		Editor's Address section.)
	The changes from version draft-ietf-tsvwg-rsvp-dste-00 to version		Michael DiBiasio
	draft-ietf-tsvwg-rsvp-dste-01 of this draft address comments from the		Cisco Systems, Inc.
	"RSVP Review team" and from the Working Group Last Call. The		300 Beaver Brook Road
	significant changes are:		Boxborough, MA 01719
	- added text in multiple sub-sections of section 3 to describe		USA
	operations when the Aggregator and Deaggregator also behave as		Email: dibiasio@cisco.com
	IPsec security gateways.
	- added text in section 3 to further clarify relationship with
	[LSP-HIER]
	- added text in section 8 to refer to some security
	considerations of [LSP-HIER] which are applicable to this
	document
	- edits in section 3.2 about forwarding of E2E path
	- edits in section 3.4 about processing of E2E Path
	- edits in section 3.6 to describe operations in case of TE
	tunnel mapping change
	- added section 3.7 to clarify forwarding of E2E traffic by
	Aggregator
	- cleaned up usage of MUST/SHOULD/MAY
	- clarifications and editorials.
	The significant changes from version draft-lefaucheur-rsvp-dste-02		Bruce Davie
	to version draft-ietf-tsvwg-rsvp-dste-00 of this draft were:		Cisco Systems, Inc.
	- added a SHOULD for use of Make-Before-Break when resizing TE
	tunnel
	- added clarification text about E2E Resv hiding from Transit
	LSRs
	- added reference to [RSVP-GEN-AGG] in section 5.
	- added definition of E2E reservation in section 2.
	- removed the case where E2E reservation is a TE tunnel (already
	covered in [LSP-HIER])
	The significant changes from version draft-lefaucheur-rsvp-dste-01 to		300 Beaver Brook Road
	version draft-lefaucheur-rsvp-dste-02 of this draft were:		Boxborough, MA 01719
	- Alignment with RSVP operations of draft-ietf-mpls-lsp-hierarchy		USA
	- Addition of an appendix providing an example usage scenario for		Email: bdavie@cisco.com
	information purposes
	RSVP Aggregation over MPLS TE tunnels February 2006		Christou Christou
			Booz Allen Hamilton
			8283 Greensboro Drive
			McLean, VA 22102
			USA
			Email: christou_chris@bah.com
	The significant changes from version draft-lefaucheur-rsvp-dste-00 to		Michael Davenport
	version draft-lefaucheur-rsvp-dste-01 of this draft were:		Booz Allen Hamilton
	- added discussion of the relationship to RFC 2746 [RSVP-TUN]		8283 Greensboro Drive
	- added discussion of mapping policy at aggregator		McLean, VA 22102
	- added discussion of "RSVP proxy" behavior in conjunction with		USA
	the aggregation scheme described here		Email: davenport_michael@bah.com
	- added discussion on TTL processing on Deaggregator
	2. Definitions		Jerry Ash
			AT&T
			200 Laurel Avenue
			Middletown, NJ 07748, USA
			USA
			Email: gash@att.com
			Bur Goode
			AT&T
			32 Old Orchard Drive
			Weston, CT 06883
			USA
			Email: bgoode@att.com
			3. Definitions
	For readability, a number of definitions from [RSVP-AGG] as well as		For readability, a number of definitions from [RSVP-AGG] as well as
	definitions for commonly used MPLS TE terms are provided here:		definitions for commonly used MPLS TE terms are provided here:
	Aggregator This is the process in (or associated with) the router		Aggregator This is the process in (or associated with) the router
	at the ingress edge of the aggregation region (with		at the ingress edge of the aggregation region (with
	respect to the end to end RSVP reservation) and		respect to the end to end RSVP reservation) and
	behaving in accordance with [RSVP-AGG]. In this		behaving in accordance with [RSVP-AGG]. In this
	document, it is also the TE Tunnel Head-end.		document, it is also the TE Tunnel Head-end.
	skipping to change at page 7, line 48		skipping to change at page 8, line 27
	(ii) corresponding Resv messages are initiated		(ii) corresponding Resv messages are initiated
	downstream of the Deaggregator and		downstream of the Deaggregator and
	terminated upstream of the Aggregator, and		terminated upstream of the Aggregator, and
	(iii) this RSVP reservation is to be aggregated		(iii) this RSVP reservation is to be aggregated
	over an MPLS TE tunnel between the		over an MPLS TE tunnel between the
	Aggregator and Deaggregator.		Aggregator and Deaggregator.
	An E2E RSVP reservation may be a per-flow		An E2E RSVP reservation may be a per-flow
	reservation. Alternatively, the E2E reservation		reservation. Alternatively, the E2E reservation
	may itself be an aggregate reservation of various		may itself be an aggregate reservation of various
	types (e.g. Aggregate IP reservation, Aggregate		types (e.g. Aggregate IP reservation, Aggregate
	IPsec reservation). See section 4 and 5 for more		IPsec reservation). See section 5 and 6 for more
	details on the types of E2E RSVP reservations. As		details on the types of E2E RSVP reservations. As
	per regular RSVP operations, E2E RSVP reservations		per regular RSVP operations, E2E RSVP reservations
	are unidirectional.		are unidirectional.
	RSVP Aggregation over MPLS TE tunnels February 2006
	Head-end		Head-end
	This is the Label Switch Router responsible for		This is the Label Switch Router responsible for
	establishing, maintaining and tearing down a given TE		establishing, maintaining and tearing down a given TE
	tunnel.		tunnel.
	Tail-end		Tail-end
	This is the Label Switch Router responsible for		This is the Label Switch Router responsible for
	terminating a given TE tunnel		terminating a given TE tunnel
	Transit LSR This is a Label Switch router that is on the path of a		Transit LSR This is a Label Switch router that is on the path of a
	given TE tunnel and is neither the Head-end nor the		given TE tunnel and is neither the Head-end nor the
	Tail-end		Tail-end
	3. Operations of RSVP Aggregation over TE with pre-established Tunnels		4. Operations of RSVP Aggregation over TE with pre-established Tunnels
	[RSVP-AGG] supports operations both in the case where aggregate RSVP		[RSVP-AGG] supports operations both in the case where aggregate RSVP
	reservations are pre-established and in the case where Aggregators		reservations are pre-established and in the case where Aggregators
	and Deaggregators have to dynamically discover each other and		and Deaggregators have to dynamically discover each other and
	dynamically establish the necessary aggregate RSVP reservations.		dynamically establish the necessary aggregate RSVP reservations.
	Similarly, RSVP Aggregation over TE tunnels could operate both in the		Similarly, RSVP Aggregation over TE tunnels could operate both in the
	case where the TE tunnels are pre-established and in the case where		case where the TE tunnels are pre-established and in the case where
	the tunnels need to be dynamically established.		the tunnels need to be dynamically established.
	skipping to change at page 9, line 4		skipping to change at page 9, line 35
	The signaling aspects discussed in section 6.2 of [LSP-HIER] apply to		The signaling aspects discussed in section 6.2 of [LSP-HIER] apply to
	the establishment/termination of the aggregate TE tunnels when this		the establishment/termination of the aggregate TE tunnels when this
	is triggered by GMPLS mechanisms (e.g. as a result of an end-to-end		is triggered by GMPLS mechanisms (e.g. as a result of an end-to-end
	TE LSP establishment request received at the aggregation boundary) .		TE LSP establishment request received at the aggregation boundary) .
	As this document assumes pre-established tunnels, those aspects are		As this document assumes pre-established tunnels, those aspects are
	not relevant here. The signaling aspects discussed in section 6.1 of		not relevant here. The signaling aspects discussed in section 6.1 of
	[LSP-HIER] relate to the establishment/maintenance of the end-to-end		[LSP-HIER] relate to the establishment/maintenance of the end-to-end
	TE LSPs over the aggregate TE tunnel. This document describes how to		TE LSPs over the aggregate TE tunnel. This document describes how to
	use the same procedures as those specified in section 6.1 of [LSP-		use the same procedures as those specified in section 6.1 of [LSP-
	HIER], but for the establishment of end-to-end RSVP reservations		HIER], but for the establishment of end-to-end RSVP reservations
	RSVP Aggregation over MPLS TE tunnels February 2006
	(instead of end-to-end TE LSPs) over the TE tunnels. This is covered		(instead of end-to-end TE LSPs) over the TE tunnels. This is covered
	further in section 3 of the present document.		further in section 4 of the present document.
	Pre-establishment of the TE tunnels may be triggered by any		Pre-establishment of the TE tunnels may be triggered by any
	mechanisms including for example manual configuration or automatic		mechanisms including for example manual configuration or automatic
	establishment of a TE tunnel mesh through dynamic discovery of TE		establishment of a TE tunnel mesh through dynamic discovery of TE
	Mesh membership as allowed in [AUTOMESH].		Mesh membership as allowed in [AUTOMESH].
	Procedures in the case of dynamically established TE tunnels are for		Procedures in the case of dynamically established TE tunnels are for
	further studies.		further studies.
	3.1. Reference Model		4.1. Reference Model
	I----I I----I		I----I I----I
	H--I R I\ I-----I I------I /I R I--H		H--I R I\ I-----I I------I /I R I--H
	H--I I\\I I I---I I I//I I--H		H--I I\\I I I---I I I//I I--H
	I----I \I He/ I I T I I Te/ I/ I----I		I----I \I He/ I I T I I Te/ I/ I----I
	I Agg I=======================I Deag I		I Agg I=======================I Deag I
	/I I I I I I\		/I I I I I I\
	H--------//I I I---I I I\\--------H		H--------//I I I---I I I\\--------H
	H--------/ I-----I I------I \--------H		H--------/ I-----I I------I \--------H
	H = Host requesting end-to-end RSVP reservations		H = Host requesting end-to-end RSVP reservations
	R = RSVP router		R = RSVP router
	He/Agg = TE tunnel Head-end/Aggregator		He/Agg = TE tunnel Head-end/Aggregator
	Te/Deag = TE tunnel Tail-end/Deaggregator		Te/Deag = TE tunnel Tail-end/Deaggregator
	T = Transit LSR		T = Transit LSR
	-- = E2E RSVP reservation		-- = E2E RSVP reservation
	== = TE Tunnel		== = TE Tunnel
	3.2. Receipt of E2E Path message By the Aggregator		4.2. Receipt of E2E Path message By the Aggregator
	The first event is the arrival of the E2E Path message at the		The first event is the arrival of the E2E Path message at the
	Aggregator. The Aggregator MUST follow traditional RSVP procedures		Aggregator. The Aggregator MUST follow traditional RSVP procedures
	for processing of this E2E path message augmented with the extensions		for processing of this E2E path message augmented with the extensions
	documented in this section.		documented in this section.
	The Aggregator MUST first attempt to map the E2E reservation onto a		The Aggregator MUST first attempt to map the E2E reservation onto a
	TE tunnel. This decision is made in accordance with routing		TE tunnel. This decision is made in accordance with routing
	information as well as any local policy information that may be		information as well as any local policy information that may be
	available at the Aggregator. Examples of such policies appear in the		available at the Aggregator. Examples of such policies appear in the
	following paragraphs. Just for illustration purposes, among many		following paragraphs. Just for illustration purposes, among many
	other criteria, such mapping policies might take into account the		other criteria, such mapping policies might take into account the
	Intserv service type, the Application Identity [RSVP-APPID] and/or		Intserv service type, the Application Identity [RSVP-APPID] and/or
	the signaled preemption [RSVP-PREEMP] of the E2E reservation (for		the signaled preemption [RSVP-PREEMP] of the E2E reservation (for
	example, the aggregator may take into account the E2E reservations		example, the aggregator may take into account the E2E reservations
	RSVP Aggregation over MPLS TE tunnels February 2006
	RSVP preemption priority and the MPLS TE Tunnel set-up and/or hold		RSVP preemption priority and the MPLS TE Tunnel set-up and/or hold
	priorities when mapping the E2E reservation onto an MPLS TE tunnel).		priorities when mapping the E2E reservation onto an MPLS TE tunnel).
	There are situations where the Aggregator is able to make a final		There are situations where the Aggregator is able to make a final
	mapping decision. That would be the case, for example, if there is a		mapping decision. That would be the case, for example, if there is a
	single TE tunnel towards the destination and if the policy is to map		single TE tunnel towards the destination and if the policy is to map
	any E2E RSVP reservation onto TE Tunnels.		any E2E RSVP reservation onto TE Tunnels.
	There are situations where the Aggregator is not able to make a final		There are situations where the Aggregator is not able to make a final
	determination. That would be the case, for example, if routing		determination. That would be the case, for example, if routing
	skipping to change at page 11, line 4		skipping to change at page 11, line 34
	Regardless of the encapsulation method, the Router Alert is not set.		Regardless of the encapsulation method, the Router Alert is not set.
	Thus, the E2E Path message will not be visible to routers along the		Thus, the E2E Path message will not be visible to routers along the
	path from the Aggregator to the Deaggregator. Therefore, in contrast		path from the Aggregator to the Deaggregator. Therefore, in contrast
	to the procedures of [RSVP-AGG], the IP Protocol number need not be		to the procedures of [RSVP-AGG], the IP Protocol number need not be
	modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating		modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating
	"RSVP") by the Aggregator.		"RSVP") by the Aggregator.
	In some environments, the Aggregator and Deaggregator MAY also act as		In some environments, the Aggregator and Deaggregator MAY also act as
	IPsec Security Gateways in order to provide IPsec protection to E2E		IPsec Security Gateways in order to provide IPsec protection to E2E
	RSVP Aggregation over MPLS TE tunnels February 2006
	traffic when it transits between the Aggregator and the Deaggregator.		traffic when it transits between the Aggregator and the Deaggregator.
	In that case, to transmit the E2E Path message to the Deaggregator,		In that case, to transmit the E2E Path message to the Deaggregator,
	the Aggregator MUST send the E2E Path message into the relevant IPsec		the Aggregator MUST send the E2E Path message into the relevant IPsec
	tunnel terminating on the Deaggregator.		tunnel terminating on the Deaggregator.
	E2E PathTear and ResvConf messages MUST be forwarded by the		E2E PathTear and ResvConf messages MUST be forwarded by the
	Aggregator to the Deaggregator exactly like Path messages.		Aggregator to the Deaggregator exactly like Path messages.
	3.3. Handling of E2E Path message By Transit LSRs		4.3. Handling of E2E Path message By Transit LSRs
	Since the E2E Path message is addressed directly to the Deaggregator		Since the E2E Path message is addressed directly to the Deaggregator
	and does not have Router Alert set, it is hidden from all transit		and does not have Router Alert set, it is hidden from all transit
	LSRs.		LSRs.
	3.4. Receipt of E2E Path Message by Deaggregator		4.4. Receipt of E2E Path Message by Deaggregator
	On receipt of the E2E Path message addressed to it, the Deaggregator		On receipt of the E2E Path message addressed to it, the Deaggregator
	will notice that the IP Protocol number is set to "RSVP" and will		will notice that the IP Protocol number is set to "RSVP" and will
	thus perform RSVP processing of the E2E Path message.		thus perform RSVP processing of the E2E Path message.
	As with [LSP-HIER], the IP TTL vs. RSVP TTL check MUST not be made.		As with [LSP-HIER], the IP TTL vs. RSVP TTL check MUST NOT be made.
	The Deaggregator is informed that this check is not to be made		The Deaggregator is informed that this check is not to be made
	because of the presence of the IF_ID RSVP HOP object.		because of the presence of the IF_ID RSVP HOP object.
	The Deaggregator MAY support the option to perform the following		The Deaggregator MAY support the option to perform the following
	checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID		checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID
	RSVP_HOP object:		RSVP_HOP object:
	1. Make sure that the data interface identified in the IF_ID		1. Make sure that the data interface identified in the IF_ID
	RSVP_HOP object actually terminates on Y.		RSVP_HOP object actually terminates on Y.
	2. Find the "other end" of the above data interface, say X.		2. Find the "other end" of the above data interface, say X.
	skipping to change at page 12, line 5		skipping to change at page 12, line 36
	The Deaggregator MUST forward the E2E Path downstream towards the		The Deaggregator MUST forward the E2E Path downstream towards the
	receiver. In doing so, the Deaggregator sets the destination address		receiver. In doing so, the Deaggregator sets the destination address
	in the IP header of the E2E Path message to the IP address found in		in the IP header of the E2E Path message to the IP address found in
	the destination address field of the Session object. The Deaggregator		the destination address field of the Session object. The Deaggregator
	also sets the Router Alert.		also sets the Router Alert.
	An E2E PathErr sent by the Deaggregator in response to the E2E Path		An E2E PathErr sent by the Deaggregator in response to the E2E Path
	message (which contains an IF_ID RSVP_HOP object) SHOULD contain an		message (which contains an IF_ID RSVP_HOP object) SHOULD contain an
	IF_ID RSVP_HOP object.		IF_ID RSVP_HOP object.
	RSVP Aggregation over MPLS TE tunnels February 2006		4.5. Handling of E2E Resv Message by Deaggregator
	3.5. Handling of E2E Resv Message by Deaggregator
	As per regular RSVP operations, after receipt of the E2E Path, the		As per regular RSVP operations, after receipt of the E2E Path, the
	receiver generates an E2E Resv message which travels upstream hop-by-		receiver generates an E2E Resv message which travels upstream hop-by-
	hop towards the sender.		hop towards the sender.
	On receipt of the E2E Resv, the Deaggregator MUST follow traditional		On receipt of the E2E Resv, the Deaggregator MUST follow traditional
	RSVP procedures on receipt of the E2E Resv message. This includes		RSVP procedures on receipt of the E2E Resv message. This includes
	performing admission control for the segment downstream of the		performing admission control for the segment downstream of the
	Deaggregator and forwarding the E2E Resv message to the PHOP signaled		Deaggregator and forwarding the E2E Resv message to the PHOP signaled
	earlier in the E2E Path message and which identifies the Aggregator.		earlier in the E2E Path message and which identifies the Aggregator.
	Since the E2E Resv message is directly addressed to the Aggregator		Since the E2E Resv message is directly addressed to the Aggregator
	and does not carry the Router Alert option (as per traditional RSVP		and does not carry the Router Alert option (as per traditional RSVP
	Resv procedures), the E2E Resv message is hidden from the routers		Resv procedures), the E2E Resv message is hidden from the routers
	between the Deaggregator and the Aggregator which, therefore, handle		between the Deaggregator and the Aggregator which, therefore, handle
	the E2E Resv message as a regular IP packet.		the E2E Resv message as a regular IP packet.
	If the Aggregator and Deaggregator are also acting as IPsec Security		If the Aggregator and Deaggregator are also acting as IPsec Security
	Gateways, the Deaggregator MUST send the E2E Resv message into the		Gateways, the Deaggregator MUST send the E2E Resv message into the
	relevant IPsec tunnel terminating on the Aggregator.		relevant IPsec tunnel terminating on the Aggregator.
	3.6. Handling of E2E Resv Message by the Aggregator		4.6. Handling of E2E Resv Message by the Aggregator
	The Aggregator is responsible for ensuring that there is sufficient		The Aggregator is responsible for ensuring that there is sufficient
	bandwidth available and reserved over the appropriate TE tunnel to		bandwidth available and reserved over the appropriate TE tunnel to
	the Deaggregator for the E2E reservation.		the Deaggregator for the E2E reservation.
	On receipt of the E2E Resv message, the Aggregator MUST first perform		On receipt of the E2E Resv message, the Aggregator MUST first perform
	the final mapping onto the final TE tunnel (if the previous mapping		the final mapping onto the final TE tunnel (if the previous mapping
	was only a tentative one).		was only a tentative one).
	If the tunnel did not change during the final mapping, the Aggregator		If the tunnel did not change during the final mapping, the Aggregator
	continues processing of the E2E Resv as described in the four		continues processing of the E2E Resv as described in the four
	following paragraphs.		following paragraphs.
	The aggregator calculates the size of the resource request using		The aggregator calculates the size of the resource request using
	traditional RSVP procedures. That is, it follows the procedures in		traditional RSVP procedures. That is, it follows the procedures in
	[RFC2205] to determine the resource requirements from the Sender		[RSVP] to determine the resource requirements from the Sender Tspec
	Tspec and the Flowspec contained in the Resv. Then it compares the		and the Flowspec contained in the Resv. Then it compares the resource
	resource request with the available resources of the selected TE		request with the available resources of the selected TE tunnel.
	tunnel.
	If sufficient bandwidth is available on the final TE tunnel, the		If sufficient bandwidth is available on the final TE tunnel, the
	Aggregator MUST update its internal understanding of how much of the		Aggregator MUST update its internal understanding of how much of the
	TE Tunnel is in use and MUST forward the E2E Resv messages to the		TE Tunnel is in use and MUST forward the E2E Resv messages to the
	corresponding PHOP.		corresponding PHOP.
	RSVP Aggregation over MPLS TE tunnels February 2006
	As noted in [RSVP-AGG], a range of policies MAY be applied to the re-		As noted in [RSVP-AGG], a range of policies MAY be applied to the re-
	sizing of the aggregate reservation (in this case, the TE tunnel.)		sizing of the aggregate reservation (in this case, the TE tunnel.)
	For example, the policy may be that the reserved bandwidth of the		For example, the policy may be that the reserved bandwidth of the
	tunnel can only be changed by configuration. More dynamic policies		tunnel can only be changed by configuration. More dynamic policies
	are also possible, whereby the aggregator may attempt to increase the		are also possible, whereby the aggregator may attempt to increase the
	reserved bandwidth of the tunnel in response to the amount of		reserved bandwidth of the tunnel in response to the amount of
	allocated bandwidth that has been used by E2E reservations.		allocated bandwidth that has been used by E2E reservations.
	Furthermore, to avoid the delay associated with the increase of the		Furthermore, to avoid the delay associated with the increase of the
	Tunnel size, the Aggregator may attempt to anticipate the increases		Tunnel size, the Aggregator may attempt to anticipate the increases
	in demand and adjust the TE tunnel size ahead of actual needs by E2E		in demand and adjust the TE tunnel size ahead of actual needs by E2E
	skipping to change at page 13, line 52		skipping to change at page 14, line 33
	successful the E2E Resv message is generated upstream towards the		successful the E2E Resv message is generated upstream towards the
	sender.		sender.
	On receipt of an E2E ResvConf from the Aggregator, the Deaggregator		On receipt of an E2E ResvConf from the Aggregator, the Deaggregator
	MUST forward the E2E ResvConf downstream towards the receiver. In		MUST forward the E2E ResvConf downstream towards the receiver. In
	doing so, the Deaggregator sets the destination address in the IP		doing so, the Deaggregator sets the destination address in the IP
	header of the E2E ResvConf message to the IP address found in the		header of the E2E ResvConf message to the IP address found in the
	RESV_CONFIRM object of the corresponding Resv. The Deaggregator also		RESV_CONFIRM object of the corresponding Resv. The Deaggregator also
	sets the Router Alert.		sets the Router Alert.
	3.7. Forwarding of E2E traffic by Aggregator		4.7. Forwarding of E2E traffic by Aggregator
	RSVP Aggregation over MPLS TE tunnels February 2006
	When the Aggregator receives a data packet belonging to an E2E		When the Aggregator receives a data packet belonging to an E2E
	reservations currently mapped over a given TE tunnel, the Aggregator		reservations currently mapped over a given TE tunnel, the Aggregator
	MUST encapsulate the packet into that TE tunnel.		MUST encapsulate the packet into that TE tunnel.
	If the Aggregator and Deaggregator are also acting as IPsec Security		If the Aggregator and Deaggregator are also acting as IPsec Security
	Gateways, the Aggregator MUST also encapsulate the data packet into		Gateways, the Aggregator MUST also encapsulate the data packet into
	the relevant IPsec tunnel terminating on the Deaggregator before		the relevant IPsec tunnel terminating on the Deaggregator before
	transmission into the MPLS TE tunnel.		transmission into the MPLS TE tunnel.
	3.8. Removal of E2E reservations		4.8. Removal of E2E reservations
	E2E reservations are removed in the usual way via PathTear, ResvTear,		E2E reservations are removed in the usual way via PathTear, ResvTear,
	timeout, or as the result of an error condition. When a reservation		timeout, or as the result of an error condition. When a reservation
	is removed, the Aggregator MUST update its local view of the		is removed, the Aggregator MUST update its local view of the
	resources available on the corresponding TE tunnel accordingly.		resources available on the corresponding TE tunnel accordingly.
	3.9. Removal of TE Tunnel		4.9. Removal of TE Tunnel
	Should a TE Tunnel go away (presumably due to a configuration change,		Should a TE Tunnel go away (presumably due to a configuration change,
	route change, or policy event), the aggregator behaves much like a		route change, or policy event), the aggregator behaves much like a
	conventional RSVP router in the face of a link failure. That is, it		conventional RSVP router in the face of a link failure. That is, it
	may try to forward the Path messages onto another tunnel, if routing		may try to forward the Path messages onto another tunnel, if routing
	and policy permit, or it may send Path_Error messages to the sender		and policy permit, or it may send Path_Error messages to the sender
	if no suitable tunnel exists. In case the Path messages are forwarded		if no suitable tunnel exists. In case the Path messages are forwarded
	onto another tunnel which terminates on a different Deaggregator, or		onto another tunnel which terminates on a different Deaggregator, or
	the reservation is torn-down via Path Error messages, the reservation		the reservation is torn-down via Path Error messages, the reservation
	state established on the router acting as the Deaggregator before the		state established on the router acting as the Deaggregator before the
	TE tunnel went away, will time out since it will no longer be		TE tunnel went away, will time out since it will no longer be
	refreshed.		refreshed.
	RSVP Aggregation over MPLS TE tunnels February 2006		4.10. Example Signaling Flow
	3.10. Example Signaling Flow
	Aggregator Deaggregator		Aggregator Deaggregator
	(*)		(*)
	RSVP-TE Path		RSVP-TE Path
	=========================>		=========================>
	RSVP-TE Resv		RSVP-TE Resv
	<=========================		<=========================
	(**)		(**)
	skipping to change at page 16, line 4		skipping to change at page 17, line 4
	(1) Aggregator tentatively selects the TE tunnel and forwards		(1) Aggregator tentatively selects the TE tunnel and forwards
	E2E path to Deaggregator		E2E path to Deaggregator
	(2) Deaggregator forwards the E2E Path towards receiver		(2) Deaggregator forwards the E2E Path towards receiver
	(3) Deaggregator forwards the E2E Resv to the Aggregator		(3) Deaggregator forwards the E2E Resv to the Aggregator
	(4) Aggregator selects final TE tunnel, checks that there is		(4) Aggregator selects final TE tunnel, checks that there is
	sufficient bandwidth on TE tunnel and forwards E2E Resv to		sufficient bandwidth on TE tunnel and forwards E2E Resv to
	RSVP Aggregation over MPLS TE tunnels February 2006
	PHOP. If final tunnel is different from tunnel tentatively		PHOP. If final tunnel is different from tunnel tentatively
	selected, the Aggregator re-sends an E2E Path.		selected, the Aggregator re-sends an E2E Path.
	4. IPv4 and IPv6 Applicability		5. IPv4 and IPv6 Applicability
	The procedures defined in this document are applicable to all the		The procedures defined in this document are applicable to all the
	following cases:		following cases:
	(1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE		(1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE
	Tunnels		Tunnels
	(2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE		(2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE
	Tunnels		Tunnels
	(3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE		(3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE
	tunnels, provided a mechanism such as [6PE] is used by the		tunnels, provided a mechanism such as [6PE] is used by the
	Aggregator and Deaggregator for routing of IPv6 traffic over		Aggregator and Deaggregator for routing of IPv6 traffic over
	an IPv4 MPLS core,		an IPv4 MPLS core,
	(4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE		(4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE
	tunnels, provided a mechanism is used by the Aggregator and		tunnels, provided a mechanism is used by the Aggregator and
	Deaggregator for routing IPv4 traffic over IPv6 MPLS.		Deaggregator for routing IPv4 traffic over IPv6 MPLS.
	5. E2E Reservations Applicability		6. E2E Reservations Applicability
	The procedures defined in this document are applicable to many types		The procedures defined in this document are applicable to many types
	of E2E RSVP reservations including the following cases:		of E2E RSVP reservations including the following cases:
	(1) the E2E RSVP reservation is a per-flow reservation where the		(1) the E2E RSVP reservation is a per-flow reservation where the
	flow is characterized by the usual 5-tuple		flow is characterized by the usual 5-tuple
	(2) the E2E reservation is an aggregate reservation for multiple		(2) the E2E reservation is an aggregate reservation for multiple
	flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the		flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the
	set of flows is characterized by the <source address,		set of flows is characterized by the <source address,
	destination address, DSCP>		destination address, DSCP>
	(3) the E2E reservation is a reservation for an IPsec protected		(3) the E2E reservation is a reservation for an IPsec protected
	flow. For example, where the flow is characterized by the		flow. For example, where the flow is characterized by the
	<source address, destination address, SPI> as described in		<source address, destination address, SPI> as described in
	[RSVP-IPSEC].		[RSVP-IPSEC].
	6. Example Deployment Scenarios		7. Example Deployment Scenarios
	6.1. Voice and Video Reservations Scenario		7.1. Voice and Video Reservations Scenario
	An example application of the procedures specified in this document		An example application of the procedures specified in this document
	is admission control of voice and video in environments with very		is admission control of voice and video in environments with very
	high numbers of hosts. In the example illustrated below, hosts		high numbers of hosts. In the example illustrated below, hosts
	generate end-to-end per-flow reservations for each of their video		generate end-to-end per-flow reservations for each of their video
	streams associated with a video-conference, each of their audio		streams associated with a video-conference, each of their audio
	streams associated with a video-conference and each of their voice		streams associated with a video-conference and each of their voice
	calls. These reservations are aggregated over MPLS DS-TE tunnels over		calls. These reservations are aggregated over MPLS DS-TE tunnels over
	RSVP Aggregation over MPLS TE tunnels February 2006
	the packet core. The mapping policy defined by the user maybe that		the packet core. The mapping policy defined by the user maybe that
	all the reservations for audio and voice streams are mapped onto DS-		all the reservations for audio and voice streams are mapped onto DS-
	TE tunnels of Class-Type 1 while reservations for video streams are		TE tunnels of Class-Type 1 while reservations for video streams are
	mapped onto DS-TE tunnels of Class-Type 0.		mapped onto DS-TE tunnels of Class-Type 0.
	------ ------		------ ------
	I H I# ------- -------- #I H I		I H I# ------- -------- #I H I
	I I\#I I ----- I I#/I I		I I\#I I ----- I I#/I I
	-----I \I Agg I I T I I Deag I/ ------		-----I \I Agg I I T I I Deag I/ ------
	I I==========================I I		I I==========================I I
	skipping to change at page 17, line 32		skipping to change at page 18, line 29
	H = Host		H = Host
	Agg = Aggregator (TE Tunnel Head-end)		Agg = Aggregator (TE Tunnel Head-end)
	Deagg = Deaggregator (TE Tunnel Tail-end)		Deagg = Deaggregator (TE Tunnel Tail-end)
	T = Transit LSR		T = Transit LSR
	/ = E2E RSVP reservation for a Voice flow		/ = E2E RSVP reservation for a Voice flow
	# = E2E RSVP reservation for a Video flow		# = E2E RSVP reservation for a Video flow
	== = DS-TE Tunnel from Class-Type 1		== = DS-TE Tunnel from Class-Type 1
	:: = DS-TE Tunnel from Class-Type 0		:: = DS-TE Tunnel from Class-Type 0
	6.2. PSTN/3G Voice Trunking Scenario		7.2. PSTN/3G Voice Trunking Scenario
	An example application of the procedures specified in this document		An example application of the procedures specified in this document
	is voice call admission control in large scale telephony trunking		is voice call admission control in large scale telephony trunking
	environments. A Trunk VoIP Gateway may generate one aggregate RSVP		environments. A Trunk VoIP Gateway may generate one aggregate RSVP
	reservation for all the calls in place towards another given remote		reservation for all the calls in place towards another given remote
	Trunk VoIP Gateway (with resizing of this aggregate reservation in a		Trunk VoIP Gateway (with resizing of this aggregate reservation in a
	step function depending on current number of calls). In turn, these		step function depending on current number of calls). In turn, these
	reservations may be aggregated over MPLS TE tunnels over the packet		reservations may be aggregated over MPLS TE tunnels over the packet
	core so that tunnel Head-ends act as Aggregators and perform		core so that tunnel Head-ends act as Aggregators and perform
	admission control of Trunk Gateway reservations into MPLS TE Tunnels.		admission control of Trunk Gateway reservations into MPLS TE Tunnels.
	The MPLS TE tunnels may be protected by MPLS Fast Reroute.		The MPLS TE tunnels may be protected by MPLS Fast Reroute.
	This scenario is illustrated below:		This scenario is illustrated below:
	RSVP Aggregation over MPLS TE tunnels February 2006
	------ ------		------ ------
	I GW I\ ------- -------- /I GW I		I GW I\ ------- -------- /I GW I
	I I\\I I ----- I I//I I		I I\\I I ----- I I//I I
	-----I \I Agg I I T I I Deag I/ ------		-----I \I Agg I I T I I Deag I/ ------
	I I==========================I I		I I==========================I I
	------ /I I I I I I\ ------		------ /I I I I I I\ ------
	I GW I//I I ----- I I\\I GW I		I GW I//I I ----- I I\\I GW I
	I I/ ------- -------- \I I		I I/ ------- -------- \I I
	------ ------		------ ------
	GW = VoIP Gateway		GW = VoIP Gateway
	Agg = Aggregator (TE Tunnel Head-end)		Agg = Aggregator (TE Tunnel Head-end)
	Deagg = Deaggregator (TE Tunnel Tail-end)		Deagg = Deaggregator (TE Tunnel Tail-end)
	T = Transit LSR		T = Transit LSR
	/ = Aggregate Gateway to Gateway E2E RSVP reservation		/ = Aggregate Gateway to Gateway E2E RSVP reservation
	== = TE Tunnel		== = TE Tunnel
	7. Optional Use of RSVP Proxy on RSVP Aggregator		8. Optional Use of RSVP Proxy on RSVP Aggregator
	A number of approaches ([RSVP-PROXY], [L-RSVP]) have been, or are		A number of approaches ([RSVP-PROXY], [L-RSVP]) have been, or are
	being, discussed in the IETF in order to allow a network node to		being, discussed in the IETF in order to allow a network node to
	behave as an RSVP proxy which:		behave as an RSVP proxy which:
	- originates the Resv Message (in response to the Path message) on		- originates the Resv Message (in response to the Path message) on
	behalf of the destination node		behalf of the destination node
	- originates the Path message (in response to some trigger) on		- originates the Path message (in response to some trigger) on
	behalf of the source node.		behalf of the source node.
	We observe that such approaches may optionally be used in conjunction		We observe that such approaches may optionally be used in conjunction
	skipping to change at page 19, line 4		skipping to change at page 20, line 4
	"The proxy functionality does not imply merely generating a single		"The proxy functionality does not imply merely generating a single
	Resv message. Proxying the Resv involves installing state in the node		Resv message. Proxying the Resv involves installing state in the node
	doing the proxy i.e. the proxying node should act as if it had		doing the proxy i.e. the proxying node should act as if it had
	received a Resv from the true endpoint. This involves reserving		received a Resv from the true endpoint. This involves reserving
	resources (if required), sending periodic refreshes of the Resv		resources (if required), sending periodic refreshes of the Resv
	message and tearing down the reservation if the Path is torn down."		message and tearing down the reservation if the Path is torn down."
	Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may		Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may
	effectively perform resource reservation over the MPLS TE Tunnel (and		effectively perform resource reservation over the MPLS TE Tunnel (and
	hence over the whole segment between the RSVP Aggregator and the RSVP		hence over the whole segment between the RSVP Aggregator and the RSVP
	RSVP Aggregation over MPLS TE tunnels February 2006
	Deaggregator) even if the RSVP signaling only takes place upstream of		Deaggregator) even if the RSVP signaling only takes place upstream of
	the MPLS TE Tunnel (i.e. between the host and the RSVP aggregator).		the MPLS TE Tunnel (i.e. between the host and the RSVP aggregator).
	Also, the RSVP Proxy can generate the Path message on behalf of the		Also, the RSVP Proxy can generate the Path message on behalf of the
	remote source host in order to achieve reservation in the return		remote source host in order to achieve reservation in the return
	direction (i.e. from RSVP aggregator/Deaggregator to host).		direction (i.e. from RSVP aggregator/Deaggregator to host).
	The resulting Signaling Flow is illustrated below, covering		The resulting Signaling Flow is illustrated below, covering
	reservations for both directions:		reservations for both directions:
	skipping to change at page 20, line 4		skipping to change at page 21, line 4
	(3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message		(3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message
	towards Host for reservation in return direction. The actual trigger		towards Host for reservation in return direction. The actual trigger
	for this depends on the actual RSVP proxy solution. As an example,		for this depends on the actual RSVP proxy solution. As an example,
	(3) and (iii) may simply be triggered respectively by (1) and (i).		(3) and (iii) may simply be triggered respectively by (1) and (i).
	Note that the details of the signaling flow may vary slightly		Note that the details of the signaling flow may vary slightly
	depending on the actual approach used for RSVP Proxy. For example, if		depending on the actual approach used for RSVP Proxy. For example, if
	the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional		the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional
	PathRequest message would be needed from host to		PathRequest message would be needed from host to
	RSVP Aggregation over MPLS TE tunnels February 2006
	Aggregator/Deaggregator/Proxy in order to trigger the generation of		Aggregator/Deaggregator/Proxy in order to trigger the generation of
	the Path message for return direction.		the Path message for return direction.
	But regardless of the details of the call flow and of the actual RSVP		But regardless of the details of the call flow and of the actual RSVP
	Proxy approach, RSVP proxy may optionally be deployed in combination		Proxy approach, RSVP proxy may optionally be deployed in combination
	with RSVP Aggregation over MPLS TE Tunnels, in such a way which		with RSVP Aggregation over MPLS TE Tunnels, in such a way which
	ensures (when used on both the Host-Aggregator and Deaggregator-Host		ensures (when used on both the Host-Aggregator and Deaggregator-Host
	sides, and when both end systems support RSVP) that:		sides, and when both end systems support RSVP) that:
	(i) admission control and resource reservation is performed on		(i) admission control and resource reservation is performed on
	skipping to change at page 20, line 33		skipping to change at page 21, line 30
	(ii) this is achieved in both direction		(ii) this is achieved in both direction
	(iii) RSVP signaling is localized between hosts and		(iii) RSVP signaling is localized between hosts and
	Aggregator/Deaggregator, which may result in significant		Aggregator/Deaggregator, which may result in significant
	reduction in reservation establishment delays (and in turn		reduction in reservation establishment delays (and in turn
	in post dial delay in the case where these reservations		in post dial delay in the case where these reservations
	are pre-conditions for voice call establishment),		are pre-conditions for voice call establishment),
	particularly in the case where the MPLS TE tunnels span		particularly in the case where the MPLS TE tunnels span
	long distances with high propagation delays.		long distances with high propagation delays.
	8. Security Considerations		9. Security Considerations
	The security issues inherent to the use of RSVP, RSVP Aggregation and		The security issues inherent to the use of RSVP, RSVP Aggregation and
	MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP-		MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP-
	AGG] and [RSVP-TE].		AGG] and [RSVP-TE].
	Section 7 of [LSP-HIER] discusses security considerations stemming		Section 7 of [LSP-HIER] discusses security considerations stemming
	from the fact that the implicit assumption of a binding between data		from the fact that the implicit assumption of a binding between data
	interface and the interface over which a control message is sent is		interface and the interface over which a control message is sent is
	no longer valid. These security considerations are equally applicable		no longer valid. These security considerations are equally applicable
	to the present document.		to the present document.
	skipping to change at page 21, line 5		skipping to change at page 22, line 5
	TE tunnels based on the current level of reservation, there are risks		TE tunnels based on the current level of reservation, there are risks
	that the TE tunnels used for RSVP aggregation hog resources in the		that the TE tunnels used for RSVP aggregation hog resources in the
	core which could prevent other TE Tunnels from being established.		core which could prevent other TE Tunnels from being established.
	There are also potential risks that such resizing results in		There are also potential risks that such resizing results in
	significant computation and signaling as well as churn on tunnel		significant computation and signaling as well as churn on tunnel
	paths. Such risks can be mitigated by configuration options allowing		paths. Such risks can be mitigated by configuration options allowing
	control of TE tunnel dynamic resizing (maximum Te tunnel size,		control of TE tunnel dynamic resizing (maximum Te tunnel size,
	maximum resizing frequency,...) and/or possibly by the use of TE		maximum resizing frequency,...) and/or possibly by the use of TE
	preemption.		preemption.
	RSVP Aggregation over MPLS TE tunnels February 2006
	If the Aggregator and Deaggregator are also acting as IPsec Security		If the Aggregator and Deaggregator are also acting as IPsec Security
	Gateways, the Security Considerations of [SEC-ARCH] apply.		Gateways, the Security Considerations of [SEC-ARCH] apply.
	9. IANA Considerations		10. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	10. Acknowledgments		11. Acknowledgments
	This document builds on the [RSVP-AGG], [RSVP-TUN] and [LSP-HIER]		This document builds on the [RSVP-AGG], [RSVP-TUN] and [LSP-HIER]
	specifications. Also, we would like to thank Tom Phelan, John Drake,		specifications. Also, we would like to thank Tom Phelan, John Drake,
	Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol		Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol
	Iturralde and James Gibson for their input into this document.		Iturralde and James Gibson for their input into this document.
	11. Normative References		12. Normative References
	[RFC2119] S. Bradner, Key words for use in RFCs to Indicate		[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
	Requirement Levels, RFC2119, March 1997.		Requirement Levels, RFC2119, March 1997.
	[RFC3668] S. Bradner, Intellectual Property Rights in IETF Technology,		[RFC3668] S. Bradner, Intellectual Property Rights in IETF Technology,
	RFC 3668, February 2004.		RFC 3668, February 2004.
	[BCP-78], S. Bradner, IETF Rights in Contributions, RFC3978, March		[BCP-78], S. Bradner, IETF Rights in Contributions, RFC3978, March
	2005.		2005.
	skipping to change at page 22, line 5		skipping to change at page 23, line 5
	[DIFFSERV] Blake et al., An Architecture for Differentiated Services,		[DIFFSERV] Blake et al., An Architecture for Differentiated Services,
	RFC 2475		RFC 2475
	[INT-DIFF] A Framework for Integrated Services Operation over		[INT-DIFF] A Framework for Integrated Services Operation over
	Diffserv Networks, RFC 2998, November 2000.		Diffserv Networks, RFC 2998, November 2000.
	[RSVP-AGG] Baker et al, Aggregation of RSVP for IPv4 and IPv6		[RSVP-AGG] Baker et al, Aggregation of RSVP for IPv4 and IPv6
	Reservations, RFC 3175, September 2001.		Reservations, RFC 3175, September 2001.
	RSVP Aggregation over MPLS TE tunnels February 2006
	[MPLS-TE] Awduche et al., "Requirements for Traffic Engineering over		[MPLS-TE] Awduche et al., "Requirements for Traffic Engineering over
	MPLS", RFC 2702, September 1999.		MPLS", RFC 2702, September 1999.
	[RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels,		[RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels,
	RFC 3209, December 2001.		RFC 3209, December 2001.
	[DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of		[DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of
	Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005.		Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005.
	[LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with		[LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with
	Generalized Multi-Protocol Label Switching (GMPLS) Traffic		Generalized Multi-Protocol Label Switching (GMPLS) Traffic
	Engineering (TE), RFC 4206, October 2005		Engineering (TE), RFC 4206, October 2005
	[SEC-ARCH] Kent and Seo, Security Architecture for the Internet		[SEC-ARCH] Kent and Seo, Security Architecture for the Internet
	Protocol, RFC 4301, December 2005		Protocol, RFC 4301, December 2005
	12. Informative References		13. Informative References
	[DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270,		[DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270,
	May 2002.		May 2002.
	[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-		[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
	aware MPLS Traffic Engineering, RFC3564, July 2003.		aware MPLS Traffic Engineering, RFC3564, July 2003.
	[6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using		[6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using
	IPv6 Provider Edge Routers (6PE), work in progress		IPv6 Provider Edge Routers (6PE), work in progress
	skipping to change at page 23, line 5		skipping to change at page 24, line 5
	[L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt,		[L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt,
	work in progress.		work in progress.
	[RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt		[RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt
	(expired), work in progress.		(expired), work in progress.
	[RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC		[RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC
	3182.		3182.
	RSVP Aggregation over MPLS TE tunnels February 2006
	[AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of		[AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of
	Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering		Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering
	(TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in		(TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in
	progress.		progress.
	[SIP-RSVP] Camarillo, Integration of Resource Management and Session		[SIP-RSVP] Camarillo, Integration of Resource Management and Session
	Initiation Protocol (SIP), RFC 3312		Initiation Protocol (SIP), RFC 3312
	13. Authors Address:		14. Editor's Address:
	Francois Le Faucheur		Francois Le Faucheur
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Village d'Entreprise Green Side - Batiment T3		Village d'Entreprise Green Side - Batiment T3
	400, Avenue de Roumanille		400, Avenue de Roumanille
	06410 Biot Sophia-Antipolis		06410 Biot Sophia-Antipolis
	France		France
	Email: flefauch@cisco.com		Email: flefauch@cisco.com
	Michael DiBiasio		IPR Statements
	Cisco Systems, Inc.
	300 Beaver Brook Road
	Boxborough, MA 01719
	USA
	Email: dibiasio@cisco.com
	Bruce Davie
	Cisco Systems, Inc.
	300 Beaver Brook Road
	Boxborough, MA 01719
	USA
	Email: bdavie@cisco.com
	Christou Christou
	Booz Allen Hamilton
	8283 Greensboro Drive
	McLean, VA 22102
	USA
	Email: christou_chris@bah.com
	Michael Davenport
	Booz Allen Hamilton
	8283 Greensboro Drive
	McLean, VA 22102
	RSVP Aggregation over MPLS TE tunnels February 2006
	USA
	Email: davenport_michael@bah.com
	Jerry Ash
	AT&T
	200 Laurel Avenue
	Middletown, NJ 07748, USA
	USA
	Email: gash@att.com
	Bur Goode
	AT&T
	32 Old Orchard Drive
	Weston, CT 06883
	USA
	Email: bgoode@att.com
	14. IPR Statements
	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 to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 24, line 48		skipping to change at page 24, line 47
	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 at		specification can be obtained from the IETF on-line IPR repository 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.		this standard.
	Please address the information to the IETF at ietf-ipr@ietf.org.		Please address the information to the IETF at ietf-ipr@ietf.org.
	15. Disclaimer of Validity		Disclaimer of Validity
	RSVP Aggregation over MPLS TE tunnels February 2006
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		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.
	16. Copyright Notice		Copyright Notice
	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.
	Appendix A - Example Usage of RSVP Aggregation over DSTE Tunnels for		Appendix A - Example Usage of RSVP Aggregation over DSTE Tunnels for
	VoIP Call Admission Control (CAC)		VoIP Call Admission Control (CAC)
	This Appendix presents an example scenario where the mechanisms		This Appendix presents an example scenario where the mechanisms
	described in this document are used, in combination with other		described in this document are used, in combination with other
	mechanisms specified by the IETF, to achieve Call Admission Control		mechanisms specified by the IETF, to achieve Call Admission Control
	(CAC) of Voice over IP (VoIP) traffic over the packet core.		(CAC) of Voice over IP (VoIP) traffic over the packet core.
	skipping to change at page 26, line 5		skipping to change at page 26, line 7
	To determine whether there is sufficient bandwidth in the MPLS core		To determine whether there is sufficient bandwidth in the MPLS core
	to complete a connection, the originating and destination GWs each		to complete a connection, the originating and destination GWs each
	send for each connection a Resource Reservation Protocol (RSVP)		send for each connection a Resource Reservation Protocol (RSVP)
	bandwidth request to the network PE router to which it is connected.		bandwidth request to the network PE router to which it is connected.
	The bandwidth request takes into account VoIP header compression,		The bandwidth request takes into account VoIP header compression,
	where applicable. As part of its Aggregator role, the PE router		where applicable. As part of its Aggregator role, the PE router
	effectively performs admission control of the bandwidth request		effectively performs admission control of the bandwidth request
	generated by the GW onto the resources of the corresponding DS-TE		generated by the GW onto the resources of the corresponding DS-TE
	tunnel.		tunnel.
	RSVP Aggregation over MPLS TE tunnels February 2006
	In this example, in addition to behaving as Aggregator/Deaggregator,		In this example, in addition to behaving as Aggregator/Deaggregator,
	PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path		PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path
	message from a GW, it does not propagate the Path message any further.		message from a GW, it does not propagate the Path message any further.
	Rather, the PE performs admission control of the bandwidth signaled		Rather, the PE performs admission control of the bandwidth signaled
	in the Path message over the DSTE tunnel towards the destination.		in the Path message over the DSTE tunnel towards the destination.
	Assuming there is enough bandwidth available on that tunnel, the PE		Assuming there is enough bandwidth available on that tunnel, the PE
	adjusts its book-keeping of remaining available bandwidth on the		adjusts its book-keeping of remaining available bandwidth on the
	tunnel and generates a Resv message back towards the GW to confirm		tunnel and generates a Resv message back towards the GW to confirm
	resources have been reserved over the DSTE tunnel.		resources have been reserved over the DSTE tunnel.
	skipping to change at page 27, line 4		skipping to change at page 27, line 6
	| '`''' |		| '`''' |
	C1 C2		C1 C2
	Figure A1. Integration of SIP Resource Management, DSTE		Figure A1. Integration of SIP Resource Management, DSTE
	and RSVP Aggregation		and RSVP Aggregation
	[SIP-RSVP] discusses how network quality of service can be made a		[SIP-RSVP] discusses how network quality of service can be made a
	precondition for establishment of sessions initiated by the Session		precondition for establishment of sessions initiated by the Session
	Initiation Protocol (SIP). These preconditions require that the		Initiation Protocol (SIP). These preconditions require that the
	participant reserve network resources before continuing with the		participant reserve network resources before continuing with the
	RSVP Aggregation over MPLS TE tunnels February 2006
	session. The reservation of network resources are performed through a		session. The reservation of network resources are performed through a
	signaling protocol such as RSVP.		signaling protocol such as RSVP.
	Our example environment relies of [SIP-RSVP] to synchronize RSVP		Our example environment relies of [SIP-RSVP] to synchronize RSVP
	bandwidth reservations with SIP. For example, the RSVP bandwidth		bandwidth reservations with SIP. For example, the RSVP bandwidth
	requests may be integrated into the call setup flow as follows (See		requests may be integrated into the call setup flow as follows (See
	call setup flow diagram in Figure A2):		call setup flow diagram in Figure A2):
	- Caller C1 initiates a call by sending a SIP INVITE to VoIP		- Caller C1 initiates a call by sending a SIP INVITE to VoIP
	gateway GW1, which passes the INVITE along to the call control		gateway GW1, which passes the INVITE along to the call control
	skipping to change at page 28, line 5		skipping to change at page 28, line 5
	destination phone, which responds with SIP message 180 RINGING.		destination phone, which responds with SIP message 180 RINGING.
	- When (and if) the called party answers, the destination phone		- When (and if) the called party answers, the destination phone
	responds with another SIP 200 OK which completes the connection		responds with another SIP 200 OK which completes the connection
	and tells the calling party that there is now reserved		and tells the calling party that there is now reserved
	bandwidth in both directions so that conversation can begin.		bandwidth in both directions so that conversation can begin.
	- RTP media streams in both directions pass through the DSTE		- RTP media streams in both directions pass through the DSTE
	tunnels as they traverse the MPLS network.		tunnels as they traverse the MPLS network.
	RSVP Aggregation over MPLS TE tunnels February 2006
	IP-Phone/ IP-Phone/		IP-Phone/ IP-Phone/
	TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2		TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2
	| INVITE|(SDP1) | INVITE | INVITE | | |		| INVITE|(SDP1) | INVITE | INVITE | | |
	|---------->|-------|---------->|------------|------->| |		|---------->|-------|---------->|------------|------->| |
	| 100|TRYING | | | | |		| 100|TRYING | | | | |
	|<----------|-------|-----------| | | |		|<----------|-------|-----------| | | |
	| 183|(SDP2) | | | | |		| 183|(SDP2) | | | | |
	|<----------|-------|-----------|------------|--------| |		|<----------|-------|-----------|------------|--------| |
	| | PATH | | | PATH | |		| | PATH | | | PATH | |
	| |------>| | |<-------| |		| |------>| | |<-------| |
	skipping to change at page 29, line 5		skipping to change at page 29, line 5
	a) the PE and GW collaborate to determine whether there is enough		a) the PE and GW collaborate to determine whether there is enough
	bandwidth on the tunnel between the calling and called GWs to		bandwidth on the tunnel between the calling and called GWs to
	accommodate the connection,		accommodate the connection,
	b) the corresponding accept/reject decision is communicated to the		b) the corresponding accept/reject decision is communicated to the
	GWs on a connection-by-connection basis, and		GWs on a connection-by-connection basis, and
	c) the PE can optimize network resources by dynamically adjusting		c) the PE can optimize network resources by dynamically adjusting
	the bandwidth of each tunnel according to the load over that tunnel.		the bandwidth of each tunnel according to the load over that tunnel.
	For example, if a tunnel is operating near capacity, the network may		For example, if a tunnel is operating near capacity, the network may
	dynamically adjust the tunnel size within a set of parameters.		dynamically adjust the tunnel size within a set of parameters.
	RSVP Aggregation over MPLS TE tunnels February 2006
	We note that admission Control of voice calls over the core network		We note that admission Control of voice calls over the core network
	capacity is achieved in a hierarchical manner whereby:		capacity is achieved in a hierarchical manner whereby:
	- DSTE tunnels are subject to Admission Control over the		- DSTE tunnels are subject to Admission Control over the
	resources of the MPLS TE core		resources of the MPLS TE core
	- Voice calls are subject to CAC over the DSTE tunnel bandwidth		- Voice calls are subject to CAC over the DSTE tunnel bandwidth
	This hierarchy is a key element in the scalability of this CAC		This hierarchy is a key element in the scalability of this CAC
	solution for voice calls over an MPLS Core.		solution for voice calls over an MPLS Core.
	It is also possible for the GWs to use aggregate RSVP reservations		It is also possible for the GWs to use aggregate RSVP reservations
	themselves instead of per-call RSVP reservations. For example,		themselves instead of per-call RSVP reservations. For example,
End of changes. 70 change blocks.
	217 lines changed or deleted		120 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/