draft-ietf-tsvwg-rsvp-proxy-approaches-05.txt		draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt
	skipping to change at page 1, line 14		skipping to change at page 1, line 14
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Informational J. Manner		Intended status: Informational J. Manner
	Expires: May 4, 2009 University of Helsinki		Expires: May 4, 2009 University of Helsinki
	D. Wing		D. Wing
	Cisco		Cisco
	A. Guillou		A. Guillou
	Neuf		Neuf
	October 31, 2008		October 31, 2008
	RSVP Proxy Approaches		RSVP Proxy Approaches
	draft-ietf-tsvwg-rsvp-proxy-approaches-05.txt		draft-ietf-tsvwg-rsvp-proxy-approaches-06.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 3, line 28		skipping to change at page 3, line 28
	Since the data sender or receiver may be unaware of RSVP, there are		Since the data sender or receiver may be unaware of RSVP, there are
	two types of RSVP Proxies. When the sender is not using RSVP, an		two types of RSVP Proxies. When the sender is not using RSVP, an
	entity in the network must operate on behalf of the data sender, and		entity in the network must operate on behalf of the data sender, and
	in particular, generate RSVP Path messages, and eventually receive,		in particular, generate RSVP Path messages, and eventually receive,
	process and sink Resv messages. We refer to this entity as the RSVP		process and sink Resv messages. We refer to this entity as the RSVP
	Sender Proxy. When the receiver is not using RSVP, an entity in the		Sender Proxy. When the receiver is not using RSVP, an entity in the
	network must receive Path messages sent by a data sender (or by an		network must receive Path messages sent by a data sender (or by an
	RSVP Sender Proxy), sink those, and return Resv messages on behalf of		RSVP Sender Proxy), sink those, and return Resv messages on behalf of
	the data receiver(s). We refer to this entity as the RSVP Receiver		the data receiver(s). We refer to this entity as the RSVP Receiver
	Proxy.		Proxy. The RSVP Proxies need to be on the data path in order to
			establish the RSVP reservation; Note, however, that some of the
			approaches described in this document allow the RSVP Proxies to be
			controlled/triggered by an off-path entity.
	The flow sender and receiver generally have at least some (if not		The flow sender and receiver generally have at least some (if not
	full) awareness of the application producing or consuming that flow.		full) awareness of the application producing or consuming that flow.
	Hence, the sender and receiver are in a natural position to		Hence, the sender and receiver are in a natural position to
	synchronize the establishment, maintenance and tear down of the RSVP		synchronize the establishment, maintenance and tear down of the RSVP
	reservation with the application requirements. Similarly they are in		reservation with the application requirements. Similarly they are in
	a natural position to determine the characteristics of the		a natural position to determine the characteristics of the
	reservation (bandwidth, QoS service,...) which best match the		reservation (bandwidth, QoS service,...) which best match the
	application requirements. For example, before completing the		application requirements. For example, before completing the
	establishment of a multimedia session, the endpoints may decide to		establishment of a multimedia session, the endpoints may decide to
	skipping to change at page 29, line 20		skipping to change at page 29, line 20
	towards the triggering node. The node then replies back with a Resv.		towards the triggering node. The node then replies back with a Resv.
	More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig].		More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig].
	Such an RSVP-Signaling-Triggered Proxy approach would require RSVP		Such an RSVP-Signaling-Triggered Proxy approach would require RSVP
	signaling extensions (that are outside the scope of the present		signaling extensions (that are outside the scope of the present
	document). However it could provide more flexibility in the control		document). However it could provide more flexibility in the control
	of the Proxy behavior (e.g. control of reverse reservation		of the Proxy behavior (e.g. control of reverse reservation
	parameters) than provided by the Path-Triggered approaches defined in		parameters) than provided by the Path-Triggered approaches defined in
	Section 4.1 and Section 4.2.		Section 4.1 and Section 4.2.
			Through potential corresponding protocol extensions, an RSVP-
			Signaling-Triggered Proxy approach could facilitate operation (e.g.
			reduce or avoid the need for associated configuration) in hybrid
			environments involving both reservations established end-to-end and
			reservations established via RSVP Proxies. For
			example,[I-D.manner-tsvwg-rsvp-proxy-sig] proposed a mechanism
			allowing an end-system to control whether a reservation can be
			handled by an RSVP Proxy on the path or is to be established end-to-
			end.
	4.8. Reachability Considerations		4.8. Reachability Considerations
	There may be situations where the RSVP Receiver Proxy is reachable by		There may be situations where the RSVP Receiver Proxy is reachable by
	the sender, while the receiver itself is not. In such situations, it		the sender, while the receiver itself is not. In such situations, it
	is possible that the RSVP Receiver Proxy is not always aware that the		is possible that the RSVP Receiver Proxy is not always aware that the
	receiver is unreachable, and consequently may accept to establish an		receiver is unreachable, and consequently may accept to establish an
	RSVP reservation on behalf of that receiver. This would result in		RSVP reservation on behalf of that receiver. This would result in
	unnecessary reservation establishment and unnecessary network		unnecessary reservation establishment and unnecessary network
	resource consumption.		resource consumption.
	skipping to change at page 30, line 14		skipping to change at page 30, line 24
	RSVP Proxys.		RSVP Proxys.
	The mirror considerations apply for situations involving an RSVP		The mirror considerations apply for situations involving an RSVP
	Sender Proxy and where the sender cannot reach the destination while		Sender Proxy and where the sender cannot reach the destination while
	the RSVP Sender Proxy can.		the RSVP Sender Proxy can.
	5. Security Considerations		5. Security Considerations
	In the environments of concern for this document, RSVP messages are		In the environments of concern for this document, RSVP messages are
	used to control resource reservations on a segment of the end-to-end		used to control resource reservations on a segment of the end-to-end
	path of flows. To ensure the integrity of the associated reservation		path of flows. The general security considerations associated with
	and admission control mechanisms, the cryptographic authentication		[RFC2205] apply. To ensure the integrity of the associated
	mechanisms defined in [RFC2747]] and [RFC3097] can be used. Those		reservation and admission control mechanisms, the cryptographic
	protect RSVP messages integrity hop-by-hop and provide node		authentication mechanisms defined in [RFC2747]] and [RFC3097] can be
	authentication, thereby protecting against corruption, spoofing of		used. Those protect RSVP messages integrity hop-by-hop and provide
	RSVP messages and replay. [I-D.ietf-tsvwg-rsvp-security-groupkeying]		node authentication, thereby protecting against corruption, spoofing
	discusses key types and key provisioning methods as well as their		of RSVP messages and replay.
	respective applicability to RSVP authentication mechanisms and to		[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types and
	IPsec protection (e.g. [RFC4303]) of RSVP.		key provisioning methods as well as their respective applicability to
			RSVP authentication and RSVP encryption (e.g. [RFC4303]).
	A number of additional security considerations apply to the use of		A number of additional security considerations apply to the use of
	RSVP proxies and are discussed below.		RSVP proxies and are discussed below.
	With some RSVP Proxy approaches, the RSVP proxy operates autonomously		With some RSVP Proxy approaches, the RSVP proxy operates autonomously
	inside an RSVP router. This is the case for the Path-Triggered Proxy		inside an RSVP router. This is the case for the Path-Triggered Proxy
	approaches defined in Section 4.1 and in Section 4.2, for the		approaches defined in Section 4.1 and in Section 4.2, for the
	Inspection-Triggered Proxy approach defined in Section 4.3, for the		Inspection-Triggered Proxy approach defined in Section 4.3, for the
	STUN-Triggered Proxy approach defined in Section 4.4 and for the		STUN-Triggered Proxy approach defined in Section 4.4 and for the
	RSVP-Signaling-Triggered approach defined in Section 4.7. Proper		RSVP-Signaling-Triggered approach defined in Section 4.7. Proper
End of changes. 4 change blocks.
	11 lines changed or deleted		25 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/