draft-ietf-tsvwg-rsvp-pcn-10.txt		draft-ietf-tsvwg-rsvp-pcn-11.txt
	Internet Engineering Task Force Georgios Karagiannis		Internet Engineering Task Force Georgios Karagiannis
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Intended status: Experimental Anurag Bhargava		Intended status: Experimental Anurag Bhargava
	Expires: March 14, 2015 Cisco Systems, Inc.		Expires: April 6, 2015 Cisco Systems, Inc.
	September 14, 2014		October 6, 2014
	Generic Aggregation of Resource ReSerVation Protocol (RSVP)		Generic Aggregation of Resource ReSerVation Protocol (RSVP)
	for IPv4 And IPv6 Reservations over PCN domains		for IPv4 And IPv6 Reservations over PCN domains
	draft-ietf-tsvwg-rsvp-pcn-10		draft-ietf-tsvwg-rsvp-pcn-11
	Abstract		Abstract
	This document specifies extensions to Generic Aggregated RSVP		This document specifies extensions to Generic Aggregated RSVP
	RFC 4860 for support of the PCN Controlled Load (CL) and Single		RFC 4860 for support of the PCN Controlled Load (CL) and Single
	Marking (SM) edge behaviors over a Diffserv cloud using Pre-		Marking (SM) edge behaviors over a Diffserv cloud using Pre-
	Congestion Notification.		Congestion Notification.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on March 14, 2015.		This Internet-Draft will expire on April 6, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 46		skipping to change at page 2, line 46
	2.3. Traffic Classification Within The Aggregation Region . . . . . . 13		2.3. Traffic Classification Within The Aggregation Region . . . . . . 13
	2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13		2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13
	2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 13		2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 13
	2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 14		2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 14
	2.7. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 14		2.7. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 14
	2.8. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . .14		2.8. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . .14
	2.9. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . . 15		2.9. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . . 15
	2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 15		2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 15
	2.11. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 15		2.11. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 15
	2.12. Reliability Issues . . . . . . . . . . . . . . . . . . . . . . 15		2.12. Reliability Issues . . . . . . . . . . . . . . . . . . . . . . 15
	2.13. Message Integrity and Node Authentication . . . . . . . . . . 15
	3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 15		3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 15
	3.1. Receipt of E2E Path Message by PCN-ingress-node		3.1. Receipt of E2E Path Message by PCN-ingress-node
	(aggregating router) . . . . . . . . . . . . . . . . . . . . . . 15		(aggregating router) . . . . . . . . . . . . . . . . . . . . . . 15
	3.2. Handling Of E2E Path Message by Interior Routers . . . . . . . 16		3.2. Handling Of E2E Path Message by Interior Routers . . . . . . . 16
	3.3. Receipt of E2E Path Message by PCN-egress-node		3.3. Receipt of E2E Path Message by PCN-egress-node
	(deaggregating router) . . . . . . . . . . . . . . . . . . . . . 16		(deaggregating router) . . . . . . . . . . . . . . . . . . . . . 16
	3.4. Initiation of new Aggregate Path Message By PCN-ingress-node		3.4. Initiation of new Aggregate Path Message By PCN-ingress-node
	(Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 16		(Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 16
	3.5. Handling Of new Aggregate Path Message by Interior Routers . . 16		3.5. Handling Of new Aggregate Path Message by Interior Routers . . 16
	3.6 Handling Of Aggregate Path Message by Deaggregating Router . . 16		3.6 Handling Of Aggregate Path Message by Deaggregating Router . . 16
	skipping to change at page 5, line 6		skipping to change at page 5, line 6
	This draft is intended to be published as Experimental in order to:		This draft is intended to be published as Experimental in order to:
	o) validate industry interest by allowing implementation and		o) validate industry interest by allowing implementation and
	deployment		deployment
	o) gather operational experience, in particular around dynamic		o) gather operational experience, in particular around dynamic
	interactions of RSVP signaling and PCN notification and		interactions of RSVP signaling and PCN notification and
	corresponding levels of performance.		corresponding levels of performance.
			Support for the techniques specified in this document involves RSVP
			functionality in boundary nodes of a PCN domain whose interior nodes
			forward RSVP traffic without performing RSVP functionality.
	1.2 Overview and Motivation		1.2 Overview and Motivation
	Two main Quality of Service (QoS) architectures have been specified		Two main Quality of Service (QoS) architectures have been specified
	by the IETF. These are the Integrated Services (Intserv) [RFC1633]		by the IETF. These are the Integrated Services (Intserv) [RFC1633]
	architecture and the Differentiated Services (DiffServ) architecture		architecture and the Differentiated Services (DiffServ) architecture
	([RFC2475]).		([RFC2475]).
	Intserv provides methods for the delivery of end-to-end Quality of		Intserv provides methods for the delivery of end-to-end Quality of
	Service (QoS) to applications over heterogeneous networks. One of the		Service (QoS) to applications over heterogeneous networks. One of the
	QoS signaling protocols used by the Intserv architecture is the		QoS signaling protocols used by the Intserv architecture is the
	skipping to change at page 11, line 46		skipping to change at page 11, line 49
	The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for		The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for
	generic aggregated reservations {RFC4860], which are depending on		generic aggregated reservations {RFC4860], which are depending on
	ingress-egress-aggregates. In particular, one RSVP generic aggregated		ingress-egress-aggregates. In particular, one RSVP generic aggregated
	reservation matches to only one ingress-egress-aggregate.		reservation matches to only one ingress-egress-aggregate.
	However, one ingress-egress-aggregate matches to either		However, one ingress-egress-aggregate matches to either
	one, or more than one, RSVP generic aggregated reservations.		one, or more than one, RSVP generic aggregated reservations.
	In addition, to comply with this specification, the PCN-boundary		In addition, to comply with this specification, the PCN-boundary
	nodes need to distinguish and process (1) RSVP SESSIONS for generic		nodes need to distinguish and process (1) RSVP SESSIONS for generic
	aggregated sessions and their messages according to [RFC4860], (2)		aggregated sessions and their messages according to [RFC4860], (2)
	E2E RSVP sessions and messages according to [RFC2205]. Furthermore,		E2E RSVP sessions and messages according to [RFC2205].
	it is considered that by configuration the PCN-interior-nodes do not
	intercept (nor process) RSVP messages associated with generic		This document locates all RSVP processing for a PCN domain at PCN-
	aggregated reservation [RFC4860], or with end to end RSVP		Boundary nodes. PCN-interior-nodes do not perform any RSVP
	reservations [RFC2205]. Moreover, each Aggregator and Deaggregator		functionality or maintain RSVP-related state information. Rather,
	(i.e., PCN-boundary-nodes) need to support policies to initiate and		PCN-interior nodes forward all RSVP messages (for both generic
	maintain for each pair of PCN-boundary-nodes of the same PCN-domain		aggregated reservations[RFC4860] and end to end reservations
	one ingress-egress-aggregate.		[RFC2205]) as if they were ordinary network traffic.
			Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes)
			need to support policies to initiate and maintain for each pair of
			PCN-boundary-nodes of the same PCN-domain one ingress-egress-
			aggregate.
	--------------------------		--------------------------
	/ PCN-domain \		/ PCN-domain \
	|----| | | |----|		|----| | | |----|
	H--| R |\ |-----| |------| /| R |-->H		H--| R |\ |-----| |------| /| R |-->H
	H--| |\\| | |---| |---| | |//| |-->H		H--| |\\| | |---| |---| | |//| |-->H
	|----| \| | | I | | I | | |/ |----|		|----| \| | | I | | I | | |/ |----|
	| Agg |======================>| Deag |		| Agg |======================>| Deag |
	/| | | | | | | |\		/| | | | | | | |\
	H--------//| | |---| |---| | |\\-------->H		H--------//| | |---| |---| | |\\-------->H
	skipping to change at page 15, line 31		skipping to change at page 15, line 36
	aggregation procedures. However, the Aggregator and Deaggregator		aggregation procedures. However, the Aggregator and Deaggregator
	SHOULD support the multi-level aggregation procedures specified in		SHOULD support the multi-level aggregation procedures specified in
	[RFC4860] and in Section 1.4.9 of [RFC3175].		[RFC4860] and in Section 1.4.9 of [RFC3175].
	2.12. Reliability Issues		2.12. Reliability Issues
	To comply with this specification, for solving possible reliability		To comply with this specification, for solving possible reliability
	issues, the same methods MUST used as the ones described in Section 4		issues, the same methods MUST used as the ones described in Section 4
	of [RFC4860].		of [RFC4860].
	2.13. Message Integrity and Node Authentication
	To comply with this specification, for message integrity and node
	authentication, the same methods MUST be used as the ones described
	in Section 4 of [RFC4860] and [RFC5559].
	3. Elements of Procedure		3. Elements of Procedure
	This section describes the procedures used to implement the		This section describes the procedures used to implement the
	aggregated RSVP procedure over PCN. It is considered that the		aggregated RSVP procedure over PCN. It is considered that the
	procedures for aggregation of E2E reservations over generic aggregate		procedures for aggregation of E2E reservations over generic aggregate
	RSVP reservations are same as the procedures specified in Section		RSVP reservations are same as the procedures specified in Section
	4 of [RFC4860] except where a departure from these procedures is		4 of [RFC4860] except where a departure from these procedures is
	explicitly described in the present section. Please refer to		explicitly described in the present section. Please refer to
	[RFC4860] for all the below error		[RFC4860] for all the below error
	cases:		cases:
	skipping to change at page 23, line 37		skipping to change at page 23, line 37
	o PCN-sent-rate: the PCN-sent-rate for the given		o PCN-sent-rate: the PCN-sent-rate for the given
	ingress-egress-aggregate. It is expressed in octets/second; its		ingress-egress-aggregate. It is expressed in octets/second; its
	format is a 32-bit IEEE floating point number; The PCN-sent-rate		format is a 32-bit IEEE floating point number; The PCN-sent-rate
	is specified in [RFC6661] and [RFC6662] and it represents the		is specified in [RFC6661] and [RFC6662] and it represents the
	estimate of the rate at which the PCN-ingress-node (Aggregator)		estimate of the rate at which the PCN-ingress-node (Aggregator)
	is receiving PCN-traffic that is destined for the given		is receiving PCN-traffic that is destined for the given
	ingress-egress-aggregate.		ingress-egress-aggregate.
	5. Security Considerations		5. Security Considerations
	The same security considerations specified in [RFC2205], [RFC4230],		The security considerations specified in [RFC2205], [RFC4860] and
	[RFC4860], [RFC5559] and [RFC6411].		[RFC5559] apply to this document. In addition, [RFC4230] and
	In particular, the security considerations within the PCN domain come		[RFC6411] provide useful guidance on RSVP security mechanisms.
	from the Trust Assumption Section 6.3.1, of [RFC5559] i.e., that all
	PCN-nodes are PCN-enabled and are trusted for truthful PCN-metering		Security within a PCN domain is fundamentally based on the controlled
	and PCN-marking.		environment trust assumption stated in Section 6.3.1 of [RFC5559], in
			particular that all PCN-nodes are PCN-enabled and are trusted
			to perform accurate PCN-metering and PCN-marking.
	In the PCN domain environments addressed by this document, Generic		In the PCN domain environments addressed by this document, Generic
	Aggregate Resource ReSerVation Protocol (RSVP)messages specified in		Aggregate Resource ReSerVation Protocol (RSVP) messages specified in
	[RFC4860] are used for support of the PCN Controlled Load (CL) and		[RFC4860] are used for support of the PCN Controlled Load (CL) and
	Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-		Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-
	Congestion Notification. Similar, to [RFC4860], [RFC2747] and		Congestion Notification. Hence the security mechanisms discussed
	[RFC3097] may be used to protect RSVP message integrity hop-		in [RFC4860] are applicable. Specifically, the INTEGRITY object
	by hop and provide node authentication as well as replay protection,		[RFC2747][RFC3097] can be used to provide hop-by-hop RSVP message
	thereby protecting against corruption and spoofing of RSVP messages		integrity, node authentication and replay protection, thereby
	and PCN feedback.		protecting against corruption and spoofing of RSVP messages and
			PCN feedback conveyed by RSVP messages.
	Based on these assumptions, it is considered that this document is		For these reasons, this document does not introduce significant
	NOT introducing any additional security concerns/issues compared to		additional security considerations beyond those discussed in
	[RFC5559] and/or [RFC4860].
			[RFC5559] and [RFC4860].
	6. IANA Considerations		6. IANA Considerations
	IANA has modified the RSVP parameters registry, 'Class Names,		IANA has modified the RSVP parameters registry, 'Class Names,
	Class Numbers, and Class Types' subregistry, to add a new		Class Numbers, and Class Types' subregistry, to add a new
	Class Number and assign 4 new C-Types under this new Class		Class Number and assign 4 new C-Types under this new Class
	Number, as described below, see Section 4.1:		Number, as described below, see Section 4.1:
	Class		Class
	Number Class Name Reference		Number Class Name Reference
	skipping to change at page 25, line 27		skipping to change at page 25, line 30
	Protocol (RSVP) Extension for the Reduction of		Protocol (RSVP) Extension for the Reduction of
	Bandwidth of a Reservation Flow", RFC 4495, May 2006.		Bandwidth of a Reservation Flow", RFC 4495, May 2006.
	[RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M.		[RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M.
	Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP)		Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP)
	Reservations", RFC4860, May 2007.		Reservations", RFC4860, May 2007.
	[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes",		[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes",
	RFC 5670, November 2009.		RFC 5670, November 2009.
	[RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline		[RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
	Encoding and Transport of Pre-Congestion Information", RFC 6660,		Encoding and Transport of Pre-Congestion Information", RFC 6660,
	July 2012.		July 2012.
	9. Informative References		9. Informative References
	[draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A.,		[draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A.,
	Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions		Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions
	for Admission Control over Diffserv using Pre-congestion		for Admission Control over Diffserv using Pre-congestion
	Notification (PCN) (Work in progress)", June 2006.		Notification (PCN) (Work in progress)", June 2006.
End of changes. 12 change blocks.
	35 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/