draft-ietf-pcn-3-in-1-encoding-04.txt		draft-ietf-pcn-3-in-1-encoding-05.txt
	Congestion and Pre-Congestion B. Briscoe		Congestion and Pre-Congestion B. Briscoe
	Notification BT		Notification BT
	Internet-Draft T. Moncaster		Internet-Draft T. Moncaster
	Intended status: Experimental Moncaster Internet Consulting		Intended status: Standards Track Moncaster Internet Consulting
	Expires: July 15, 2011 M. Menth		Expires: November 22, 2011 M. Menth
	University of Tuebingen		University of Tuebingen
	January 11, 2011		May 21, 2011
	Encoding 3 PCN-States in the IP header using a single DSCP		Encoding 3 PCN-States in the IP header using a single DSCP
	draft-ietf-pcn-3-in-1-encoding-04		draft-ietf-pcn-3-in-1-encoding-05
	Abstract		Abstract
	The objective of Pre-Congestion Notification (PCN) is to protect the		The objective of Pre-Congestion Notification (PCN) is to protect the
	quality of service (QoS) of inelastic flows within a Diffserv domain.		quality of service (QoS) of inelastic flows within a Diffserv domain.
	On every link in the PCN domain, the overall rate of the PCN-traffic		On every link in the PCN domain, the overall rate of the PCN-traffic
	is metered, and PCN-packets are appropriately marked when certain		is metered, and PCN-packets are appropriately marked when certain
	configured rates are exceeded. Egress nodes provide decision points		configured rates are exceeded. Egress nodes provide decision points
	with information about the PCN-marks of PCN-packets which allows them		with information about the PCN-marks of PCN-packets which allows them
	to take decisions about whether to admit or block a new flow request,		to take decisions about whether to admit or block a new flow request,
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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 July 15, 2011.		This Internet-Draft will expire on November 22, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 35		skipping to change at page 2, line 35
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5		3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5
	3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5		3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6		3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6
	3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7		3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7
	4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7		4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7
	5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN		5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN
	Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8		6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
	6.1. Backward Compatibility with Pre-existing PCN		6.1. Backward Compatibility with Pre-existing PCN
	Implementations . . . . . . . . . . . . . . . . . . . . . 8		Implementations . . . . . . . . . . . . . . . . . . . . . 9
	6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9		6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9
	6.2.1. Use of Both Excess-Traffic-Marking and		6.2.1. Use of Both Excess-Traffic-Marking and
	Threshold-Marking . . . . . . . . . . . . . . . . . . 9		Threshold-Marking . . . . . . . . . . . . . . . . . . 10
	6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 9		6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 10
	6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10		6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11		11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 11		12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	12.2. Informative References . . . . . . . . . . . . . . . . . . 12		12.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Appendix A. Co-existence of ECN and PCN (informative) . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The objective of Pre-Congestion Notification (PCN) [RFC5559] is to		The objective of Pre-Congestion Notification (PCN) [RFC5559] is to
	protect the quality of service (QoS) of inelastic flows within a		protect the quality of service (QoS) of inelastic flows within a
	Diffserv domain, in a simple, scalable, and robust fashion. Two		Diffserv domain, in a simple, scalable, and robust fashion. Two
	mechanisms are used: admission control, to decide whether to admit or		mechanisms are used: admission control, to decide whether to admit or
	block a new flow request, and flow termination to terminate some		block a new flow request, and flow termination to terminate some
	existing flows during serious pre-congestion. To achieve this, the		existing flows during serious pre-congestion. To achieve this, the
	overall rate of PCN-traffic is metered on every link in the domain,		overall rate of PCN-traffic is metered on every link in the domain,
	skipping to change at page 3, line 49		skipping to change at page 3, line 49
	extension to the baseline encoding that uses the EXP codepoint to		extension to the baseline encoding that uses the EXP codepoint to
	provide a third PCN marking state in the IP header, still using a		provide a third PCN marking state in the IP header, still using a
	single Diffserv codepoint. This encoding scheme is called "3-in-1		single Diffserv codepoint. This encoding scheme is called "3-in-1
	PCN encoding".		PCN encoding".
	This document only concerns the PCN wire protocol encoding for all IP		This document only concerns the PCN wire protocol encoding for all IP
	headers, whether IPv4 or IPv6. It makes no changes or		headers, whether IPv4 or IPv6. It makes no changes or
	recommendations concerning algorithms for congestion marking or		recommendations concerning algorithms for congestion marking or
	congestion response. Other documents define the PCN wire protocol		congestion response. Other documents define the PCN wire protocol
	for other header types. For example, the MPLS encoding is defined in		for other header types. For example, the MPLS encoding is defined in
	[RFC5129]. Appendix A provides an informative example for a mapping		[RFC5129] and Appendix A of that document provides an informative
	between the encodings in IP and in MPLS.		example for a mapping between the encodings in IP and in MPLS.
	1.1. Changes in This Version (to be removed by RFC Editor)		1.1. Changes in This Version (to be removed by RFC Editor)
			From draft-ietf-pcn-3-in-1-encoding-04 to -05:
			* Draft moved to standards track as per working group
			discussions.
			* Added Appendix A discussing ECN handling in the PCN-domain.
			* Clarified that this document modifies [RFC5696].
			* .......
	From draft-ietf-pcn-3-in-1-encoding-03 to -04:		From draft-ietf-pcn-3-in-1-encoding-03 to -04:
	* Updated document to reflect RFC6040.		* Updated document to reflect RFC6040.
	* Re-wrote introduction.		* Re-wrote introduction.
	* Re-wrote section on applicability.		* Re-wrote section on applicability.
	* Re-wrote section on choosing encoding scheme.		* Re-wrote section on choosing encoding scheme.
	skipping to change at page 9, line 24		skipping to change at page 9, line 37
	6.2. Recommendations for the Use of PCN Encoding Schemes		6.2. Recommendations for the Use of PCN Encoding Schemes
	NOTE: This sub-section is informative not normative.		NOTE: This sub-section is informative not normative.
	When deciding which PCN encoding is suitable an operator needs to		When deciding which PCN encoding is suitable an operator needs to
	take account of how many PCN states need to be encoded. The		take account of how many PCN states need to be encoded. The
	following table gives guidelines on which encoding to use with either		following table gives guidelines on which encoding to use with either
	threshold-marking, excess-traffic marking or both.		threshold-marking, excess-traffic marking or both.
	+------------------------+--------------------------------+		+------------------------+--------------------------------+
	| Used marking schemes | Recommended encoding scheme |		| Marking schemes in use | Recommended encoding scheme |
	+------------------------+--------------------------------+		+------------------------+--------------------------------+
	| Only threshold-marking | Baseline encoding [RFC5696] |		| Only threshold-marking | Baseline encoding [RFC5696] |
	+------------------------+--------------------------------+		+------------------------+--------------------------------+
	| Only excess-traffic- | Baseline encoding [RFC5696] |		| Only excess-traffic- | Baseline encoding [RFC5696] |
	| marking | or 3-in-1 PCN encoding |		| marking | or 3-in-1 PCN encoding |
	+------------------------+--------------------------------+		+------------------------+--------------------------------+
	| Threshold-marking and | 3-in-1 PCN encoding |		| Threshold-marking and | 3-in-1 PCN encoding |
	| excess-traffic-marking | |		| excess-traffic-marking | |
	+------------------------+--------------------------------+		+------------------------+--------------------------------+
	skipping to change at page 10, line 48		skipping to change at page 11, line 16
	The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field		The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field
	to encode PCN-marks. One codepoint allows non-PCN traffic to be		to encode PCN-marks. One codepoint allows non-PCN traffic to be
	carried with the same PCN-compatible DSCP and three other codepoints		carried with the same PCN-compatible DSCP and three other codepoints
	support three PCN marking states with different levels of severity.		support three PCN marking states with different levels of severity.
	The use of this PCN encoding scheme presupposes that any tunnels in		The use of this PCN encoding scheme presupposes that any tunnels in
	the PCN region have been updated to comply with [RFC6040].		the PCN region have been updated to comply with [RFC6040].
	10. Acknowledgements		10. Acknowledgements
	Thanks to Phil Eardley, Teco Boot, and Kwok Ho Chan for reviewing		Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Georgios
	this document.		Karaginannis for reviewing this document.
	11. Comments Solicited		11. Comments Solicited
	To be removed by RFC Editor: Comments and questions are encouraged		To be removed by RFC Editor: Comments and questions are encouraged
	and very welcome. They can be addressed to the IETF Congestion and		and very welcome. They can be addressed to the IETF Congestion and
	Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to		Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to
	the authors.		the authors.
	12. References		12. References
	skipping to change at page 11, line 29		skipping to change at page 11, line 42
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	December 1998.		December 1998.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, September 2001.		RFC 3168, September 2001.
			[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
			Congestion Notification (ECN) Signaling with Nonces",
			RFC 3540, June 2003.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
			[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
			Guidelines for DiffServ Service Classes", RFC 4594,
			August 2006.
	[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion		[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
	Marking in MPLS", RFC 5129, January 2008.		Marking in MPLS", RFC 5129, January 2008.
	[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)		[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
	Architecture", RFC 5559, June 2009.		Architecture", RFC 5559, June 2009.
	[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-		[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
	Nodes", RFC 5670, November 2009.		Nodes", RFC 5670, November 2009.
	[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline		[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
	Encoding and Transport of Pre-Congestion Information",		Encoding and Transport of Pre-Congestion Information",
	RFC 5696, November 2009.		RFC 5696, November 2009.
			[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
			Services Code Point (DSCP) for Capacity-Admitted Traffic",
			RFC 5865, May 2010.
	[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion		[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
	Notification", RFC 6040, November 2010.		Notification", RFC 6040, November 2010.
	12.2. Informative References		12.2. Informative References
	[I-D.ietf-pcn-cl-edge-behaviour]		[I-D.ietf-pcn-cl-edge-behaviour]
	Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.		Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
	Taylor, "PCN Boundary Node Behaviour for the Controlled		Taylor, "PCN Boundary Node Behaviour for the Controlled
	Load (CL) Mode of Operation",		Load (CL) Mode of Operation",
	draft-ietf-pcn-cl-edge-behaviour-08 (work in progress),		draft-ietf-pcn-cl-edge-behaviour-08 (work in progress),
	December 2010.		December 2010.
	[I-D.ietf-pcn-encoding-comparison]		[I-D.ietf-pcn-encoding-comparison]
	Chan, K., Karagiannis, G., Moncaster, T., Menth, M.,		Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,
	Eardley, P., and B. Briscoe, "Pre-Congestion Notification		Eardley, P., and B. Briscoe, "Overview of Pre-Congestion
	Encoding Comparison",		Notification Encoding",
	draft-ietf-pcn-encoding-comparison-03 (work in progress),		draft-ietf-pcn-encoding-comparison-05 (work in progress),
	October 2010.		April 2011.
	[I-D.ietf-pcn-sm-edge-behaviour]		[I-D.ietf-pcn-sm-edge-behaviour]
	Charny, A., Karagiannis, G., Menth, M., and T. Taylor,		Charny, A., Karagiannis, G., Menth, M., and T. Taylor,
	"PCN Boundary Node Behaviour for the Single Marking (SM)		"PCN Boundary Node Behaviour for the Single Marking (SM)
	Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05		Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05
	(work in progress), December 2010.		(work in progress), December 2010.
			Appendix A. Co-existence of ECN and PCN (informative)
			The PCN encoding described in this document re-uses the bits of the
			ECN field in the IP header. Consequently, this disables ECN within
			the PCN domain. Appendix B of [RFC5696] included advice on handling
			ECN traffic within a PCN-domain. This appendix clarifies that
			advice.
			For the purposes of this appendix we define two forms of traffic that
			might arrive at a PCN-ingress node. These are Admission-controlled
			traffic and Non-admission-controlled traffic.
			Admission-controlled traffic will be remarked to the PCN-compatible
			DSCP by the PCN-ingress node. Two mechanisms can be used to identify
			such traffic:
			a. flow signalling associates a filterspec with a need for admission
			control (e.g. through RSVP or some equivalent message down from a
			SIP server to the ingress), and the PCN-ingress remarks traffic
			matching that filterspec to a PCN-compatible DSCP, as its chosen
			admission control mechanism.
			b. Traffic arrives with a DSCP that implies it requires admission
			control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time,
			Broadcast TV when used for video on demand, and Multimedia
			Conferencing [RFC4594][RFC5865].
			All other traffic can be thought of as Non-admission-controlled.
			However such traffic may still need to share the same DSCP as the
			Admission-controlled traffic. This may be due to policy (for
			instance if it is high priority voice traffic), or may be because
			there is a shortage of local DSCPs.
			ECN [RFC3168] is an end-to-end congestion notification mechanism. As
			such it is possible that some traffic entering the PCN-domain may
			also be ECN capable The following lists the four cases for how e2e
			ECN traffic may wish to be treated while crossing a PCN domain:
			ECN capable traffic that does not require admission control and does
			not carry a DSCP that the PCN-ingress is using for PCN-capable
			traffic. This requires no action.
			ECN capable traffic that does not require admission control but
			carries a DSCP that the PCN-ingress is using for PCN-capable
			traffic. There are two options.
			* The ingress maps the DSCP to a local DSCP with the same
			scheduling PHB as the original DSCP, and the egress re-maps it
			to the original PCN-compatible DSCP.
			* The ingress tunnels the traffic, setting not-PCN in the outer
			header; note that this turns off ECN for this traffic within
			the PCN domain.
			The first option is recommended unless the operator is short of
			local DSCPs.
			ECN-capable Admission-controlled traffic: There are two options.
			* The PCN-ingress places this traffic in a tunnel with a PCN-
			compatible DSCP in the outer header. The PCN-egress zeroes the
			ECN-field before decapsulation.
			* The PCN-ingress drops CE-marked packets and the PCN-egress
			zeros the ECN field of all PCN packets.
			The second option is not recommended unless tunnelling is not
			possible for some reason..
			ECN-capable Admission-controlled where the e2e transport somehow
			indicates that it wants to see PCN marks: NOTE this is currently
			experimental only.
			Schemes have been suggested where PCN marks may be leaked out of
			the PCN-domain and used by the end hosts to modify realtime data
			rates. Currently all such schemes are experimental and the
			following is for guidance only.
			The PCN-ingress needs to tunnel the traffic using [RFC6040]. The
			PCN-egress should not zero the ECN field, and the tunnel egress
			should use [RFC6040] normal mode (preserving any PCN-marking).
			Note that this may turn ECT(0) into ECT(1) and so is not
			compatible with the experimental ECN nonce [RFC3540].
			In the list above any form of IP-in-IP tunnel can be used unless
			specified otherwise. NB, We assume a logical separation of tunneling
			and PCN actions in both PCN-ingress and PCN-egress nodes. That is,
			any tunneling action happens wholly outside the PCN-domain as
			illustrated in the following figure:
			, . . . . . PCN-domain . . . . . .
			. ,--------. ,--------. .
			. _| PCN- |___________________| PCN- |_ .
			. / | ingress | | egress | \ .
			.| '---------' '--------' |.
			| . . . . . . . . . . . . . . .|
			,--------. ,--------.
			_____| Tunnel | | Tunnel |____
			| Ingress | - - ECN preserved inside tunnel - - | Egress |
			'---------' '--------'
			Figure 4: Separation of tunneling and PCN actions
	Authors' Addresses		Authors' Addresses
	Bob Briscoe		Bob Briscoe
	BT		BT
	B54/77, Adastral Park		B54/77, Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich IP5 3RE		Ipswich IP5 3RE
	UK		UK
	Phone: +44 1473 645196		Phone: +44 1473 645196
	skipping to change at page 13, line 7		skipping to change at page 16, line 7
	Layer Marney		Layer Marney
	Colchester CO5 9UZ		Colchester CO5 9UZ
	UK		UK
	Phone: +44 7764 185416		Phone: +44 7764 185416
	Email: toby@moncaster.com		Email: toby@moncaster.com
	URI: http://www.moncaster.com/		URI: http://www.moncaster.com/
	Michael Menth		Michael Menth
	University of Tuebingen		University of Tuebingen
	Sand 13		Sand 13
	72076 Tuebingen		Tuebingen 72076
	Germany		Germany
	Phone: +49 7071 2970505		Phone: +49 7071 2970505
	Email: menth@informatik.uni-tuebingen.de		Email: menth@informatik.uni-tuebingen.de
End of changes. 18 change blocks.
	22 lines changed or deleted		149 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/