draft-ietf-tsvwg-rsvp-proxy-proto-01.txt		draft-ietf-tsvwg-rsvp-proxy-proto-02.txt
	TSVWG F. Le Faucheur		TSVWG F. Le Faucheur
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track J. Manner		Intended status: Standards Track J. Manner
	Expires: December 28, 2007 University of Helsinki		Expires: April 13, 2008 University of Helsinki
	A. Narayanan		A. Narayanan
	Cisco		Cisco
	A. Guillou		A. Guillou
	Neuf		Neuf
	H. Malik		H. Malik
	Bharti		Bharti
	June 26, 2007		October 11, 2007
	RSVP Extensions for Path-Triggered RSVP Receiver Proxy		RSVP Extensions for Path-Triggered RSVP Receiver Proxy
	draft-ietf-tsvwg-rsvp-proxy-proto-01.txt		draft-ietf-tsvwg-rsvp-proxy-proto-02.txt
	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
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		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 December 28, 2007.		This Internet-Draft will expire on April 13, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	RSVP signaling can be used to make end-to-end resource reservations		RSVP signaling can be used to make end-to-end resource reservations
	in an IP network in order to guarantee the QoS required by certain		in an IP network in order to guarantee the QoS required by certain
	flows. With conventional RSVP, both the data sender and receiver of		flows. With conventional RSVP, both the data sender and receiver of
	skipping to change at page 3, line 11		skipping to change at page 3, line 11
	an RSVP Receiver Proxy whose signaling is triggered by receipt of		an RSVP Receiver Proxy whose signaling is triggered by receipt of
	RSVP Path messages from the sender. This document specifies these		RSVP Path messages from the sender. This document specifies these
	extensions.		extensions.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conventions Used in This Document . . . . . . . . . . . . 5		1.1. Conventions Used in This Document . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. RSVP Extensions for Sender Notification . . . . . . . . . . . 7		3. RSVP Extensions for Sender Notification . . . . . . . . . . . 7
	3.1. Sender Notification via PathErr Message . . . . . . . . . 9		3.1. Sender Notification via PathErr Message . . . . . . . . . 10
	3.1.1. Composition of SESSION and <Sender descriptor> . . . . 12		3.1.1. Composition of SESSION and <Sender descriptor> . . . . 12
	3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13		3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13
	3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14		3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14
	3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15		3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15
	3.2. Sender Notification via Notify Message . . . . . . . . . . 15		3.2. Sender Notification via Notify Message . . . . . . . . . . 16
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 18		4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 22		7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
	7.2. Informative References . . . . . . . . . . . . . . . . . . 22		7.2. Informative References . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
	Intellectual Property and Copyright Statements . . . . . . . . . . 25		Intellectual Property and Copyright Statements . . . . . . . . . . 27
	1. Introduction		1. Introduction
	Guaranteed QoS for some applications with tight Qos requirements may		Guaranteed QoS for some applications with tight Qos requirements may
	be achieved by reserving resources in each node on the end-to-end		be achieved by reserving resources in each node on the end-to-end
	path. The main IETF protocol for these resource reservations is RSVP		path. The main IETF protocol for these resource reservations is RSVP
	specified in [RFC2205]. RSVP does not require that all intermediate		specified in [RFC2205]. RSVP does not require that all intermediate
	nodes support RSVP, however it assumes that both the sender and the		nodes support RSVP, but it assumes that both the sender and the
	receiver of the data flow support RSVP. There are environments where		receiver of the data flow support RSVP. However, there are
	it would be useful to be able to reserve resources for a flow on at		environments where it would be useful to be able to reserve resources
	least a subset of the flow path even when the sender or the receiver		for a flow (at least a subset of the flow path) even when the sender
	(or both) is not RSVP-capable.		or the receiver (or both) is not RSVP-capable.
	Since either the data sender or receiver may be unaware of RSVP,		Since both the data sender and receiver may be unaware of RSVP, there
	there are two distinct use cases. In the first case, an entity in		are two distinct RSVP Proxy cases. In the first case, an entity in
	the network must operate on behalf of the data sender, generate RSVP		the network must operate on behalf of the data sender, generate RSVP
	Path messages, and eventually receive, process and sink Resv		Path messages, and eventually receive, process and sink Resv
	messages. We refer to this entity as the RSVP Sender Proxy. In the		messages. We refer to this entity as the RSVP Sender Proxy. In the
	second case, an entity in the network must receive Path messages sent		second case, an entity in the network must receive Path messages sent
	by a data sender (or by an RSVP Sender Proxy), and reply to those		by a data sender (or by an RSVP Sender Proxy), and reply to those
	with Resv messages generated on behalf of the data receiver(s). We		with Resv messages generated on behalf of the data receiver(s). We
	refer to this entity as the RSVP Receiver Proxy.		refer to this entity as the RSVP Receiver Proxy.
	RSVP Proxy approaches are presented in		RSVP Proxy approaches are presented in
	[I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also		[I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also
	discusses, for each approach, how the reservations controlled by the		discusses, for each approach, how the reservations controlled by the
	RSVP Proxy can be synchronised with the application requirements		RSVP Proxy can be synchronised with the application requirements
	(e.g. when to establish, maintain, tear down the RSVP reservation to		(e.g. when to establish, maintain and tear down the RSVP reservation
	satisfy application requirements).		to satisfy application requirements).
	One RSVP Proxy approach is referred to as the Path-Triggered RSVP		One RSVP Proxy approach is referred to as the Path-Triggered RSVP
	Receiver Proxy approach. With this approach, the RSVP Receiver Proxy		Receiver Proxy approach. With this approach, the RSVP Receiver Proxy
	uses the RSVP Path messages generated by the sender as the cue for		uses the RSVP Path messages generated by the sender (or RSVP Sender
	establishing the RSVP reservation on behalf of the non-RSVP-capable		Proxy) as the cue for establishing the RSVP reservation on behalf of
	receiver. The RSVP Receiver Proxy is effectively acting as a slave		the non-RSVP-capable receiver. The RSVP Receiver Proxy is
	making reservations (on behalf of the receiver) under the sender's		effectively acting as an intermediary making reservations (on behalf
	control. This changes somewhat the usual RSVP reservation model		of the receiver) under the sender's control (or RSVP Sender Proxy's
			control). This changes somewhat the usual RSVP reservation model
	where reservations are normally controlled by receivers. Such a		where reservations are normally controlled by receivers. Such a
	change greatly facilitates operations in the scenario of interest		change greatly facilitates operations in the scenario of interest
	here, which is where the receiver is not RSVP-capable. Indeed it		here, which is where the receiver is not RSVP-capable. Indeed it
	allows the RSVP Receiver Proxy to remain application unaware by		allows the RSVP Receiver Proxy to remain application unaware by
	taking advantage of the application awareness and RSVP awareness of		taking advantage of the application awareness and RSVP awareness of
	the sender.		the sender (or RSVP Sender Proxy).
	Since the synchronisation between RSVP reservation and application		Since the synchronisation between RSVP reservation and application
	requirement is now effectively performed by the sender, it is		requirement is now effectively performed by the sender (or RSVP
	important that the sender is aware of the reservation state.		Sender Proxy), it is important that the sender (or RSVP Sender Proxy)
	However, as conventional RSVP assumes that the reservation is to be		is aware of the reservation state. However, as conventional RSVP
	controlled by the receiver, some notifications about reservation		assumes that the reservation is to be controlled by the receiver,
	state (notably the error message sent in case of admission control		some notifications about reservation state (notably the error message
	rejection of the reservation) are only sent to the receiver. This		sent in case of admission control rejection of the reservation) are
	document specifies extension to RSVP procedures allowing such		only sent towards the receiver and therefore, in our case, sunk by
	notifications to be also conveyed to the sender. This facilitates		the RSVP Receiver Proxy. This document specifies extension to RSVP
	synchronization by the sender between RSVP reservation and		procedures allowing such notifications to be also conveyed towards
	application requirements in scenarios involving a Path-Triggered RSVP		the sender. This facilitates synchronization by the sender (or RSVP
	receiver Proxy.		Sender Proxy) between RSVP reservation and application requirements
			in scenarios involving a Path-Triggered RSVP receiver Proxy.
			This document discusses extension to facilitate operations in the
			presence of an RSVP Receiver Proxy. As explicitely pointed out in
			the text above, those apply equally whether RSVP signaling is
			initiated by a regular RSVP sender or by an RSVP Sender Proxy (with
			some means to synchronize reservation state with application level
			requirements that are outside the scope of this document). For
			readability, the rest of this document discusses operation assuming a
			regular RSVP sender; however, such operation is equallly applicable
			where an RSVP Sender Proxy is used to initiated RSVP signaling on
			behalf of a non-RSVP-capable sender.
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Terminology		2. Terminology
	RSVP-capable (or RSVP-aware): which supports the RSVP protocol as per		The following terminology is borrowed from
			[I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the
			present document:
			o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per
	[RFC2205]		[RFC2205]
	RSVP Receiver Proxy: an RSVP-capable router performing, on behalf of		o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf
	a receiver, the RSVP operations which would normally be performed by		of a receiver, the RSVP operations which would normally be
	an RSVP-capable receiver if end-to-end RSVP signaling was used. Note		performed by an RSVP-capable receiver if end-to-end RSVP signaling
	that while RSVP is used upstream of the RSVP Receiver Proxy, RSVP is		was used. Note that while RSVP is used upstream of the RSVP
	not used downstream of the RSVP Receiver Proxy.		Receiver Proxy, RSVP is not used downstream of the RSVP Receiver
			Proxy.
	RSVP Sender Proxy: an RSVP-capable router performing, on behalf of a		o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of
	sender, the RSVP operations which would normally be performed by an		a sender, the RSVP operations which would normally be performed by
	RSVP-capable sender if end-to-end RSVP signaling was used. Note that		an RSVP-capable sender if end-to-end RSVP signaling was used.
	while RSVP is used downstream of the RSVP Sender Proxy, RSVP is not		Note that while RSVP is used downstream of the RSVP Sender Proxy,
	used upstream of the RSVP Sender Proxy.		RSVP is not used upstream of the RSVP Sender Proxy.
	Regular RSVP Router: an RSVP-capable router which is not behaving as		o Regular RSVP Router: an RSVP-capable router which is not behaving
	a RSVP Receiver Proxy nor as a RSVP Sender Proxy.		as a RSVP Receiver Proxy nor as a RSVP Sender Proxy.
	Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy,		o Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy,
	Regular RSVP Router are all relative to one unidirectional flow. A		Regular RSVP Router are all relative to one unidirectional flow.
	given router may act as the RSVP Receiver Proxy for a flow, as the		A given router may act as the RSVP Receiver Proxy for a flow, as
	RSVP Sender Proxy for another flow and as a Regular RSVP router for		the RSVP Sender Proxy for another flow and as a Regular RSVP
	yet another flow.		router for yet another flow.
			The following terminology is also used in the present document:
			o Regular RSVP Sender: an RSVP-capable host behaving as the sender
			for the considered flow and participating in RSVP signaling in
			accordance with the sender behavior specified in [RFC2205].
			o Regular RSVP Receiver: an RSVP-capable host behaving as the
			receiver for the considered flow and participating in RSVP
			signaling in accordance with the receiver behavior specified in
			[RFC2205].
	3. RSVP Extensions for Sender Notification		3. RSVP Extensions for Sender Notification
	This section defines extensions to RSVP procedures allowing		This section defines extensions to RSVP procedures allowing sender
	notification of the sender of reservation failure. This facilitates		notification of reservation failure. This facilitates
	synchronization by the sender between RSVP reservation and		synchronization by the sender between RSVP reservation and
	application requirements in scenarios involving a Path-Triggered RSVP		application requirements in scenarios involving a Path-Triggered RSVP
	receiver Proxy.		Receiver Proxy.
	As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the		As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the
	Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be		Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be
	configured to use receipt of a regular RSVP Path message as the		configured to use receipt of a regular RSVP Path message as the
	trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP		trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP
	Path message, the RSVP Receiver Proxy:		Path message, the RSVP Receiver Proxy:
	1. establishes the RSVP Path state as per regular RSVP processing		1. establishes the RSVP Path state as per regular RSVP processing
	2. identifies the downstream interface towards the receiver		2. identifies the downstream interface towards the receiver
	skipping to change at page 8, line 5		skipping to change at page 8, line 5
	was received on the downstream interface. This includes		was received on the downstream interface. This includes
	performing admission control on the downstream interface,		performing admission control on the downstream interface,
	establishing a Resv state (in case of successful admission		establishing a Resv state (in case of successful admission
	control) and forwarding the Resv message upstream, sending		control) and forwarding the Resv message upstream, sending
	periodic refreshes of the Resv message and tearing down the		periodic refreshes of the Resv message and tearing down the
	reservation if the Path state is torn down.		reservation if the Path state is torn down.
	Operation of the Path-Triggered Receiver Proxy in the case of a		Operation of the Path-Triggered Receiver Proxy in the case of a
	successful reservation is illustrated in Figure 1.		successful reservation is illustrated in Figure 1.
	|----| *** *** |----------| |----|		|----| *** *** *** |----------| |----|
	| S |---------*r*----------*r*---------| RSVP |----------| R |		| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
	|----| *** *** | Receiver | |----|		|----| *** *** *** | Receiver | |----|
	| Proxy |		| Proxy |
	|----------|		|----------|
	*************************************************************>		************************************************************>
	===================RSVP======================>		===================RSVP===================>
	---Path---> ----Path----> ---Path---->		--Path---> --Path---> --Path---> --Path--->
	<--Resv---> <---Resv----- <--Resv----		<---Resv-- <---Resv-- <---Resv-- <---Resv--
	|----| RSVP-capable |----| Non-RSVP-capable ***		|----| RSVP-capable |----| Non-RSVP-capable ***
	| S | Sender | R | Receiver *r* regular RSVP		| S | Sender | R | Receiver *r* regular RSVP
	|----| |----| *** router		|----| |----| *** router
	***> media flow		***> media flow
	==> segment of flow path protected by RSVP reservation		==> segment of flow path protected by RSVP reservation
	Figure 1: Successful Reservation		Figure 1: Successful Reservation
	skipping to change at page 9, line 5		skipping to change at page 9, line 5
	notified of the reservation failure. Specifically, in case of an		notified of the reservation failure. Specifically, in case of an
	admission control rejection on a regular RSVP router, a ResvErr		admission control rejection on a regular RSVP router, a ResvErr
	message is sent downstream towards the receiver. In the presence of		message is sent downstream towards the receiver. In the presence of
	an RSVP Receiver Proxy, if we simply follow conventional RSVP		an RSVP Receiver Proxy, if we simply follow conventional RSVP
	procedures, this means that the RSVP Receiver Proxy is notified of		procedures, this means that the RSVP Receiver Proxy is notified of
	the reservation failure, but the sender is not. Operation of the		the reservation failure, but the sender is not. Operation of the
	Path-Triggered RSVP Receiver Proxy in the case of an admission		Path-Triggered RSVP Receiver Proxy in the case of an admission
	control failure, assuming conventional RSVP procedures, is		control failure, assuming conventional RSVP procedures, is
	illustrated in Figure 2.		illustrated in Figure 2.
	|----| *** *** |----------| |----|		|----| *** *** *** |----------| |----|
	| S |---------*r*----------*r*---------| RSVP |----------| R |		| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
	|----| *** *** | Receiver | |----|		|----| *** *** *** | Receiver | |----|
	| Proxy |		| Proxy |
	|----------|		|----------|
	*************************************************************>		************************************************************>
	===================RSVP======================>		===================RSVP===================>
	---Path---> ----Path----> ---Path---->		--Path---> --Path---> --Path---> --Path--->
	<---Resv----- <--Resv------		<---Resv-- <---Resv--
	---ResvErr---> --ResvErr--->		-ResvErr-> -ResvErr->
	|----| |----| ***		|----| |----| ***
	| S | Sender | R | Receiver *r* regular RSVP		| S | Sender | R | Receiver *r* regular RSVP
	|----| |----| *** router		|----| |----| *** router
	***> media flow		***> media flow
	==> segment of flow path protected by RSVP reservation		==> segment of flow path protected by RSVP reservation
	Figure 2: Reservation Failure With Conventional RSVP		Figure 2: Reservation Failure With Conventional RSVP
	While the sender could infer reservation failure from the fact that		While the sender could infer reservation failure from the fact that
	it has not received a Resv message after a certain time, there are		it has not received a Resv message after a certain time, there are
	clear benefits in ensuring that the sender gets a prompt explicit		clear benefits in ensuring that the sender gets a prompt explicit
	notification in case of reservation failure.		notification in case of reservation failure. This includes faster
			enduser notification at application layer (e.g. busy signal), faster
			application level reaction (e.g. application level rerouting), as
			well as faster release of application-level resources.
	Section 3.1 defines a method which can be used to achieve sender		Section 3.1 defines a method which can be used to achieve sender
	notification of reservation failure. An implementation of this		notification of reservation failure. A router implementation
	document MUST support the method defined in Section 3.1.		claiming compliance with this document MUST support the method
			defined in Section 3.1.
	Section 3.2 defines another method which can be used to achieve		Section 3.2 defines another method which can be used to achieve
	sender notification of reservation failure. An implementation of		sender notification of reservation failure. A router implementation
	this document MAY support the method defined in Section 3.2.		claiming compliance with this document MAY support the method defined
			in Section 3.2.
			In a given network environment, a network administrator may elect to
			use the method defined in Section 3.1, or the method defined in
			Section 3.2, or possibly combine the two.
	3.1. Sender Notification via PathErr Message		3.1. Sender Notification via PathErr Message
	With this method, the RSVP Receiver Proxy MUST generate a PathErr		With this method, the RSVP Receiver Proxy MUST generate a PathErr
	message whenever the two following conditions are met:		message whenever the two following conditions are met:
	1. The reservation establishment has failed (or the previously		1. The reservation establishment has failed (or the previously
	established reservation has been torn down)		established reservation has been torn down)
	2. The RSVP Receiver Proxy determines that it cannot re-establish		2. The RSVP Receiver Proxy determines that it cannot re-establish
	skipping to change at page 11, line 5		skipping to change at page 11, line 5
	completely new. It is borrowed from [RFC3209] where it has been		completely new. It is borrowed from [RFC3209] where it has been
	introduced in order to achieve a similar requirement, which is to		introduced in order to achieve a similar requirement, which is to
	allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end		allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end
	(i.e. the sender) of a failure to establish (or maintain) a TE Tunnel		(i.e. the sender) of a failure to establish (or maintain) a TE Tunnel
	Label Switch Path.		Label Switch Path.
	Operation of the Path-Triggered RSVP Receiver Proxy in the case of an		Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
	admission control failure, using sender notification via PathErr		admission control failure, using sender notification via PathErr
	Message, is illustrated in Figure 3.		Message, is illustrated in Figure 3.
	|----| *** *** |----------| |----|		|----| *** *** *** |----------| |----|
	| S |---------*r*----------*r*---------| RSVP |----------| R |		| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
	|----| *** *** | Receiver | |----|		|----| *** *** *** | Receiver | |----|
	| Proxy |		| Proxy |
	|----------|		|----------|
	*************************************************************>		************************************************************>
	===================RSVP======================>		===================RSVP===================>
	---Path---> ----Path----> ---Path---->		--Path---> --Path---> --Path---> --Path--->
	<---Resv----- <--Resv------		<---Resv-- <---Resv--
	---ResvErr---> --ResvErr--->		-ResvErr-> -ResvErr->
	<--PathErr- <--PathErr--- <--PathErr---		<-PathErr- <-PathErr- <-PathErr- <-PathErr-
	|----| |----| ***		|----| |----| ***
	| S | Sender | R | Receiver *r* regular RSVP		| S | Sender | R | Receiver *r* regular RSVP
	|----| |----| *** router		|----| |----| *** router
	***> media flow		***> media flow
	==> segment of flow path protected by RSVP reservation		==> segment of flow path protected by RSVP reservation
	Figure 3: Reservation Failure With Sender Notification via PathErr		Figure 3: Reservation Failure With Sender Notification via PathErr
	skipping to change at page 12, line 45		skipping to change at page 12, line 45
	2. Errors which the sender has no control over. For these errors,		2. Errors which the sender has no control over. For these errors,
	it is sufficient to notify the sender that the reservation was		it is sufficient to notify the sender that the reservation was
	not set up successfully. An example of this is "Class 13:		not set up successfully. An example of this is "Class 13:
	Unknown Object", because the sender has no control over the		Unknown Object", because the sender has no control over the
	objects inserted into the reservation by the Receiver Proxy.		objects inserted into the reservation by the Receiver Proxy.
	The PathErr message generated by the Receiver Proxy has the same		The PathErr message generated by the Receiver Proxy has the same
	format as regular PathErr messages defined in [RFC2205]. The		format as regular PathErr messages defined in [RFC2205]. The
	SESSION, ERROR_SPEC and sender descriptor are composed by the		SESSION, ERROR_SPEC and sender descriptor are composed by the
	Receiver Proxy as specified in the following subsections. The		Receiver Proxy as specified in the following subsections. The
	Receiver Proxy MAY reflect back to the sender in the PathErr any		Receiver Proxy MAY reflect back towards the sender in the PathErr any
	POLICY_DATA objects received in the ResvErr.		POLICY_DATA objects received in the ResvErr.
	3.1.1. Composition of SESSION and <Sender descriptor>		3.1.1. Composition of SESSION and <Sender descriptor>
	The Receiver Proxy MUST insert the SESSION object corresponding to		The Receiver Proxy MUST insert the SESSION object corresponding to
	the failed reservation, into the PathErr. For Fixed-Filter (FF)		the failed reservation, into the PathErr. For Fixed-Filter (FF)
	style reservations, the Receiver Proxy MUST insert a <sender		style reservations, the Receiver Proxy MUST insert a <sender
	descriptor> corresponding to the failed reservation, into the		descriptor> corresponding to the failed reservation, into the
	PathErr. This is equal to the <flow descriptor> in the ResvErr		PathErr. This is equal to the <flow descriptor> in the ResvErr
	received by the Receiver Proxy. For Shared-Explicit (SE) style		received by the Receiver Proxy. For Shared-Explicit (SE) style
	skipping to change at page 14, line 38		skipping to change at page 14, line 38
	3.1.3. Use of Path_State_Removed Flag		3.1.3. Use of Path_State_Removed Flag
	[RFC3473] defines an optional behavior whereby a node forwarding a		[RFC3473] defines an optional behavior whereby a node forwarding a
	PathErr message can remove the Path State associated with the PathErr		PathErr message can remove the Path State associated with the PathErr
	message and indicate so by including the Path_State_Removed flag in		message and indicate so by including the Path_State_Removed flag in
	the ERROR_SPEC object of the PathErr message. This can be used in		the ERROR_SPEC object of the PathErr message. This can be used in
	some situations to expedite release of resources and minimise		some situations to expedite release of resources and minimise
	signaling load.		signaling load.
			This section discusses aspects of the use of the Path_State_Removed
			flag that are specific to the RSVP Receiver Proxy. In any other
			aspects, the Path_State_Removed flag operates as per [RFC3473].
	By default, the RSVP Receiver Proxy MUST not include the		By default, the RSVP Receiver Proxy MUST not include the
	Path_State_Removed flag in the ERROR_SPEC of the PathErr message.		Path_State_Removed flag in the ERROR_SPEC of the PathErr message.
	This ensures predictable operations in all environments including		This ensures predictable operations in all environments including
	those where some RSVP routers do not understand the		those where some RSVP routers do not understand the
	Path_State_Removed flag.		Path_State_Removed flag.
	Optionally, the RSVP Receiver Proxy MAY support a configurable mode		Optionally, the RSVP Receiver Proxy MAY support an optional mode that
	whereby the RSVP Receiver Proxy includes the Path_State_Removed flag		can be activated by configuration whereby the RSVP Receiver Proxy
	in the ERROR_SPEC of the PathErr message and removes its local Path		includes the Path_State_Removed flag in the ERROR_SPEC of the PathErr
	state. This can be used in environments where all RSVP routers are		message and removes its local Path state. Where all routers on the
	known to support the Path_State_Removed flag thereby reliably		path of a reservation support the Path_State_Removed flag, its use
	achieving expedited resource release.		will indeed result in expedited resource release and reduced
			signaling. However, if there is one (or more) "old" router on the
			path of the reservation that does not support the Path_State_Removed
			flag, its use will actually result in slower resource release and
			increased signaling. This is because the Path_State_Removed flag
			will be propagated upstream by an "old" router (even if it does not
			understand it and does not tear its Path state). Thus, the sender
			will not send a Path Tear and the "old" router will only release its
			Path state through refresh time-out. A network administrator needs
			to keep these considerations in mind when deciding whether to
			activate the use of the Path_State_Removed flag on the RSVP Receiver
			Proxy. In a controlled environment where all routers are known to
			support the Path_State_Removed flag, its use can be safely activated
			on the RSVP Receiver Proxy. In other environments, the network
			administrator needs to assess whether the improvement achieved with
			some reservations outweighs the degradation experienced by other
			reservations.
	3.1.4. Use of PathErr by Regular Receivers		3.1.4. Use of PathErr by Regular Receivers
	Note that while this document specifies that an RSVP Receiver Proxy		Note that while this document specifies that an RSVP Receiver Proxy
	generates a PathErr upstream in case of reservation failure, this		generates a PathErr upstream in case of reservation failure, this
	document does NOT propose that the same be done by regular receivers.		document does NOT propose that the same be done by regular receivers.
	In other words, this document does NOT propose to modify the behavior		In other words, this document does NOT propose to modify the behavior
	of regular receivers as currently specified in [RFC2205]. The		of regular receivers as currently specified in [RFC2205]. The
	rationale for this includes the following:		rationale for this includes the following:
	skipping to change at page 15, line 42		skipping to change at page 16, line 12
	sender can. This motivation does not apply in case of regular		sender can. This motivation does not apply in case of regular
	receiver.		receiver.
	o there is a lot of existing code and deployed systems successfully		o there is a lot of existing code and deployed systems successfully
	working under the current [RFC2205] model in the absence of proxy		working under the current [RFC2205] model in the absence of proxy
	today. The current behavior should not be changed for those		today. The current behavior should not be changed for those
	unless there were a very strong motivation.		unless there were a very strong motivation.
	3.2. Sender Notification via Notify Message		3.2. Sender Notification via Notify Message
	The optional method for sender notification of reservation failure		The OPTIONAL method for sender notification of reservation failure
	defined in this section aims at providing a more efficient method		defined in this section aims at providing a more efficient method
	than the one defined in Section 3.1. Its objectives include :		than the one defined in Section 3.1. Its objectives include :
	o allow the failure notification to be sent directly upstream to the		o allow the failure notification to be sent directly upstream to the
	sender by the router where the failure occurs (as opposed to first		sender by the router where the failure occurs (as opposed to first
	travelling downstream towards the Receiver Proxy and then		travelling downstream towards the Receiver Proxy and then
	travelling upstream from the Receiver Proxy to the sender, as		travelling upstream from the Receiver Proxy to the sender, as
	effectively happens with the method defined in Section 3.1)		effectively happens with the method defined in Section 3.1)
	o allow the failure notification to travel directly to the sender		o allow the failure notification to travel directly to the sender
	without hop-by-hop RSVP processing		without hop-by-hop RSVP processing
	o ensure that such a notification is only sent to senders which are		o ensure that such a notification is only sent to senders which are
	capable and willing to process it (i.e. to synchronize reservation		capable and willing to process it (i.e. to synchronize reservation
	status with application)		status with application)
	o ensure that such a notification is only sent in case the receiver		o ensure that such a notification is only sent in case the receiver
	is not itself capable and willing to do the synchronisation with		is not itself capable and willing to do the synchronisation with
	the application (i.e. because we are in the presence of a receiver		the application (i.e. because we are in the presence of a receiver
	skipping to change at page 16, line 23		skipping to change at page 16, line 41
	the application (i.e. because we are in the presence of a receiver		the application (i.e. because we are in the presence of a receiver
	proxy so that RSVP signaling is not visible to the receiver)		proxy so that RSVP signaling is not visible to the receiver)
	Note, however, that such benefits come at the cost of more		Note, however, that such benefits come at the cost of more
	sophistication and of a requirement for RSVP routers and senders to		sophistication and of a requirement for RSVP routers and senders to
	support the Notify messages and procedures defined in [RFC3473].		support the Notify messages and procedures defined in [RFC3473].
	[RFC3473] defines (in section "4.3 Notify Messages") the Notify		[RFC3473] defines (in section "4.3 Notify Messages") the Notify
	message that provides a mechanism to inform non-adjacent nodes of		message that provides a mechanism to inform non-adjacent nodes of
	events related to the RSVP reservation. The Notify message differs		events related to the RSVP reservation. The Notify message differs
	from the currently defined error messages (i.e., PathErr and ResvErr		from the error messages defined in [RFC2205] (i.e., PathErr and
	messages) in that it can be "targeted" to a node other than the		ResvErr messages) in that it can be "targeted" to a node other than
	immediate upstream or downstream neighbor and that it is a		the immediate upstream or downstream neighbor and that it is a
	generalized notification mechanism. Notify messages are normally		generalized notification mechanism. Notify messages are normally
	generated only after a Notify Request object has been received.		generated only after a Notify Request object has been received.
			This section discusses aspects of the use of the Notify message that
			are specific to the RSVP Receiver Proxy. In any other aspects, the
			Notify message operates as per [RFC3473].
	In order to achieve sender notification of reservation failure in the		In order to achieve sender notification of reservation failure in the
	context of the present document:		context of the present document:
	o an RSVP sender interested in being notified of reservation failure		o an RSVP sender interested in being notified of reservation failure
	MUST include a Notify Request object (containing the sender's IP		MUST include a Notify Request object (containing the sender's IP
	address) in the Path messages it generates		address) in the Path messages it generates
	o Upon receiving a Path message with a Notify Request object, the		o Upon receiving a Path message with a Notify Request object, the
	RSVP Receiver Proxy MUST include a Notify Request object in the		RSVP Receiver Proxy MUST include a Notify Request object in the
	Resv messages it generates. This Notify Request object MUST		Resv messages it generates. This Notify Request object MUST
	contain the address that was included in the Notify Request of the		contain the address that was included in the Notify Request of the
	received Path message- a.k.a. the sender's address- and not an		received Path message- a.k.a. the sender's address- and not an
	address of the Receiver Proxy.		address of the Receiver Proxy.
	As a result, as per existing Notify procedures, if an RSVP router		As a result, as per existing Notify procedures, if an RSVP router
	detects an error relating to a Resv state (e.g. Admission Control		detects an error relating to a Resv state (e.g. Admission Control
	rejection after IP reroute), the RSVP router will send a Notify		rejection after IP reroute), the RSVP router will send a Notify
	message (conveying the Resv Err code) to the IP address contained in		message (conveying the Resv Err code) to the IP address contained in
	the Resv Notify Request object. Since this address has been set to		the Resv Notify Request object. Since this address has been set to
	the sender's address by the Receiver Proxy, the Notify message is		the sender's address by the Receiver Proxy, the Notify message is
	sent directly to the sender.		sent to the sender.
	Operation of the Path-Triggered RSVP Receiver Proxy in the case of an		Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
	admission control failure, using sender notification via Notify		admission control failure, using sender notification via Notify
	Message, is illustrated in Figure 4.		Message, is illustrated in Figure 4.
	|----| *** *** |----------| |----|		|----| *** *** *** |----------| |----|
	| S |---------*r*----------*r*---------| RSVP |----------| R |		| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
	|----| *** *** | Receiver | |----|		|----| *** *** *** | Receiver | |----|
	| Proxy |		| Proxy |
	|----------|		|----------|
	*************************************************************>		************************************************************>
	===================RSVP======================>		===================RSVP===================>
	---Path*--> ----Path*---> ---Path*--->		--Path---> --Path---> --Path---> --Path--->
	<---Resv*--- <--Resv*----		<---Resv-- <---Resv--
	<--Notify--		<------Notify-------
	---ResvErr---> --ResvErr--->		-ResvErr-> -ResvErr->
	|----| |----| ***		|----| |----| ***
	| S | Sender | R | Receiver *r* regular RSVP		| S | Sender | R | Receiver *r* regular RSVP
	|----| |----| *** router		|----| |----| *** router
	***> media flow		***> media flow
	==> segment of flow path protected by RSVP reservation		==> segment of flow path protected by RSVP reservation
	Path* = Path message containing a Notify Request object		Path* = Path message containing a Notify Request object
	with sender IP Address		with sender IP Address
	Resv* = Resv message containing a Notify Request object		Resv* = Resv message containing a Notify Request object
	with sender IP address		with sender IP address
			Notify = Notify message
	Figure 4: Reservation Failure With Sender Notification via Notify		Figure 4: Reservation Failure With Sender Notification via Notify
	For local failures on the Receiver Proxy node, if a similar failure		For local failures on the Receiver Proxy node, if a similar failure
	on an RSVP midpoint would cause the generation of a ResvErr (for		on an RSVP midpoint would cause the generation of a ResvErr (for
	example, CAC failure), the Receiver Proxy MUST generate a Notify		example, CAC failure), the Receiver Proxy MUST generate a Notify
	towards the sender. The Receiver Proxy MAY additionally generate a		towards the sender. The Receiver Proxy MAY additionally generate a
	Notify upon local failures which would not ordinarily cause		Notify upon local failures which would not ordinarily cause
	generation of a ResvErr message, such as described in Appendix B of		generation of a ResvErr message, such as described in Appendix B of
	[RFC2205].		[RFC2205].
	skipping to change at page 20, line 5		skipping to change at page 20, line 47
	risk of being tampered with; While the receivers are in locations		risk of being tampered with; While the receivers are in locations
	which are physically unsecured and therefore subject to a higher risk		which are physically unsecured and therefore subject to a higher risk
	of being tampered with. The use of an RSVP receiver proxy function		of being tampered with. The use of an RSVP receiver proxy function
	effectively increases the security of the operator's reservation and		effectively increases the security of the operator's reservation and
	admission control solution by completely excluding receivers from its		admission control solution by completely excluding receivers from its
	operation. Filters can be placed at the edge of the operator network		operation. Filters can be placed at the edge of the operator network
	discarding any RSVP message received from end-users. This provides a		discarding any RSVP message received from end-users. This provides a
	very simple and effective protection of the RSVP reservation and		very simple and effective protection of the RSVP reservation and
	admission control solution operating inside the operator's network.		admission control solution operating inside the operator's network.
			This document defines in Section 3.2 an optional method relying on
			the use of the Notify message specified in [RFC3473]. The Notify
			message can be sent in a non-hop-by-hop fashion that precludes RSVP's
			hop-by-hop integrity and authentication model. The approaches and
			considerations for addressing this issue presented in the Security
			Considerations section of [RFC3473] apply. In particular, where the
			Notify messages are transmitted non-hop-by-hop and the same level of
			security provided by [RFC2747] is desired, the standard IPsec based
			integrity and authentication can be used. Alternatively, the sending
			of non-hop-by-hop Notify messages can be disabled.
	5. IANA Considerations		5. IANA Considerations
	Since, as discussed in Section 3.1.2, this document allows two Error		Since, as discussed in Section 3.1.2, this document allows two Error
	Codes to be used in PathErr messages while [RFC2205] only specified		Codes to be used in PathErr messages while [RFC2205] only specified
	their use in ResvErr messages, this document requires that IANA		their use in ResvErr messages, this document requires that IANA
	updates the existing entries for these two Error Codes under the		updates the existing entries for these two Error Codes under the
	"Error Codes and Globally-Defined Error Value Sub-Codes" registry.		"Error Codes and Globally-Defined Error Value Sub-Codes" registry.
	Each entry should refer to this document, in addition to referring to		Each entry should refer to this document, in addition to referring to
	[RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2		[RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2
	should respectively read:		should respectively read:
	skipping to change at page 22, line 37		skipping to change at page 24, line 37
	[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic		(GMPLS) Signaling Resource ReserVation Protocol-Traffic
	Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.		Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, December 2005.		RFC 4303, December 2005.
	7.2. Informative References		7.2. Informative References
	[I-D.behringer-tsvwg-rsvp-security-groupkeying]		[I-D.behringer-tsvwg-rsvp-security-groupkeying]
	Behringer, M., Le Faucheur, F., and F. Baker, "A Framework		Behringer, M. and F. Le Faucheur, "A Framework for RSVP
	for RSVP Security Using Dynamic Group Keying", July 2007.		Security Using Dynamic Group Keying", July 2007.
	[I-D.ietf-tsvwg-rsvp-proxy-approaches]		[I-D.ietf-tsvwg-rsvp-proxy-approaches]
	Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,		Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,
	"RSVP Proxy Approaches", July 2007.		"RSVP Proxy Approaches", July 2007.
	Authors' Addresses		Authors' Addresses
	Francois Le Faucheur		Francois Le Faucheur
	Cisco Systems		Cisco Systems
	Greenside, 400 Avenue de Roumanille		Greenside, 400 Avenue de Roumanille
End of changes. 57 change blocks.
	113 lines changed or deleted		189 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/