< draft-ietf-pcn-3-in-1-encoding-06.txt		draft-ietf-pcn-3-in-1-encoding-07a.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
	Obsoletes: 5696 (if approved) Moncaster Internet Consulting		Obsoletes: 5696 (if approved) Moncaster Internet Consulting
	Intended status: Standards Track M. Menth		Intended status: Standards Track M. Menth
	Expires: January 11, 2012 University of Tuebingen		Expires: January 18, 2012 University of Tuebingen
	July 10, 2011		July 17, 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-06		draft-ietf-pcn-3-in-1-encoding-07
	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.
	The overall rate of the PCN-traffic is metered on every link in the		The overall rate of the PCN-traffic is metered on every link in the
	PCN domain, and PCN-packets are appropriately marked when certain		PCN domain, and PCN-packets are appropriately marked when certain
	configured rates are exceeded. Egress nodes pass information about		configured rates are exceeded. Egress nodes pass information about
	these PCN-marks to decision points which then decide whether to admit		these PCN-marks to decision points which then decide whether to admit
	or block new flow requests or to terminate some already-admitted		or block new flow requests or to terminate some already-admitted
	skipping to change at page 1, line 48		skipping to change at page 1, line 48
	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 January 11, 2012.		This Internet-Draft will expire on January 18, 2012.
	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 3, line 12		skipping to change at page 3, line 12
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
	1.2. Changes in This Version (to be removed by RFC Editor) . . 5		1.2. Changes in This Version (to be removed by RFC Editor) . . 5
	2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7		2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 7		2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 8
	3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 8		3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 8
	4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 9		4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 9
	4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 9		4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 9		4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 10
	4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 10		4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 10
	5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN		5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN
	Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 10		5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 11
	5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11		5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11
	5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11		5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11
	5.2.2. Behaviour of PCN-interior Nodes Using Two		5.2.2. Behaviour of PCN-interior Nodes Using Two
	PCN-markings . . . . . . . . . . . . . . . . . . . . . 11		PCN-markings . . . . . . . . . . . . . . . . . . . . . 12
	5.2.3. Behaviour of PCN-interior Nodes Using One		5.2.3. Behaviour of PCN-interior Nodes Using One
	PCN-marking . . . . . . . . . . . . . . . . . . . . . 11		PCN-marking . . . . . . . . . . . . . . . . . . . . . 12
	5.3. Behaviour of PCN-egress Nodes . . . . . . . . . . . . . . 12		5.3. Behaviour of PCN-egress Nodes . . . . . . . . . . . . . . 13
	6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13		6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
	6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13		6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13
	6.2. Backward Compatibility with the Baseline Encoding . . . . 13		6.2. Backward Compatibility with the Baseline Encoding . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15		11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 15		12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	12.2. Informative References . . . . . . . . . . . . . . . . . . 15		12.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 16		Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 17
	Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 18		Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 18
	Appendix C. Example Mapping between Encoding of PCN-Marks in		Appendix C. Example Mapping between Encoding of PCN-Marks in
	IP and in MPLS Shim Headers . . . . . . . . . . . . . 20		IP and in MPLS Shim Headers . . . . . . . . . . . . . 21
	Appendix D. Rationale for different behaviours for single		Appendix D. Rationale for Discrepancy Between the Schemes
	marking schemes . . . . . . . . . . . . . . . . . . . 21		using One PCN-Marking . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	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 5, line 20		skipping to change at page 5, line 20
	mapping between IP and MPLS.		mapping between IP and MPLS.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2. Changes in This Version (to be removed by RFC Editor)		1.2. Changes in This Version (to be removed by RFC Editor)
			From draft-ietf-pcn-3-in-1-encoding-06 to -07:
			* Clarified that each operator not the IETF chooses which DSCP(s)
			are PCN-compatible, and made it unambiguous that only PCN-nodes
			recognise that PCN-compatible DSCPs enable the 3-in-1 encoding.
			* Removed statements about the PCN working group, given RFCs are
			meant to survive beyond the life of a w-g.
			* Corrected the final para of "Rational for Different Behaviours
			in Schemes with Only One Marking"
	From draft-ietf-pcn-3-in-1-encoding-05 to -06:		From draft-ietf-pcn-3-in-1-encoding-05 to -06:
	* Draft re-written to obsolete baseline encoding [RFC5696].		* Draft re-written to obsolete baseline encoding [RFC5696].
	* New section defining utilising this encoding for single		* New section defining utilising this encoding for only one PCN-
	marking. Added an appendix explaining an apparent		Marking. Added an appendix explaining an apparent
	inconsistency relating to single marking.		inconsistency within this section.
	* Moved (and updated) informative appendixes from [RFC5696] to		* Moved (and updated) informative appendixes from [RFC5696] to
	this document. Original Appendix C was omitted as it is now		this document. Original Appendix C was omitted as it is now
	redundant.		redundant.
	* Significant re-structuring of document.		* Significant re-structuring of document.
	From draft-ietf-pcn-3-in-1-encoding-04 to -05:		From draft-ietf-pcn-3-in-1-encoding-04 to -05:
	* Draft moved to standards track as per working group		* Draft moved to standards track as per working group
	skipping to change at page 7, line 18		skipping to change at page 7, line 27
	The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node,		The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node,
	PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN-		PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN-
	marking are used as defined in [RFC5559]. The following additional		marking are used as defined in [RFC5559]. The following additional
	terms are defined in this document:		terms are defined in this document:
	PCN encoding: mapping of PCN marking states to specific codepoints		PCN encoding: mapping of PCN marking states to specific codepoints
	in the packet header.		in the packet header.
	PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating		PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating
	packets for which the ECN field is used to carry PCN-markings		packets for which the ECN field carries PCN-markings rather than
	rather than [RFC3168] markings (see Appendix A).		[RFC3168] markings. Note that an operator configures PCN-nodes to
			recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN-
			specific meaning to a node outside the PCN domain.
	Threshold-marked codepoint: a codepoint that indicates packets that		Threshold-marked codepoint: a codepoint that indicates packets that
	have been marked at a PCN-interior-node as a result of an		have been marked at a PCN-interior-node as a result of an
	indication from the threshold-metering function [RFC5670].		indication from the threshold-metering function [RFC5670].
	Abbreviated to ThM.		Abbreviated to ThM.
	Excess-traffic-marked codepoint: a codepoint that indicates packets		Excess-traffic-marked codepoint: a codepoint that indicates packets
	that have been marked at a PCN-interior-node as a result of an		that have been marked at a PCN-interior-node as a result of an
	indication from the excess-traffic-metering function [RFC5670].		indication from the excess-traffic-metering function [RFC5670].
	Abbreviated to ETM.		Abbreviated to ETM.
	skipping to change at page 8, line 35		skipping to change at page 9, line 5
	| | Codepoint in ECN field of IP header |		| | Codepoint in ECN field of IP header |
	| DSCP | <RFC3168 codepoint name> |		| DSCP | <RFC3168 codepoint name> |
	| +--------------+-------------+-------------+---------+		| +--------------+-------------+-------------+---------+
	| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |		| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
	+--------+--------------+-------------+-------------+---------+		+--------+--------------+-------------+-------------+---------+
	| DSCP n | Not-PCN | NM | ThM | ETM |		| DSCP n | Not-PCN | NM | ThM | ETM |
	+--------+--------------+-------------+-------------+---------+		+--------+--------------+-------------+-------------+---------+
	Figure 1: 3-in-1 PCN Encoding		Figure 1: 3-in-1 PCN Encoding
	As mentioned above, the 3-in-1 PCN encoding is an extension of the		A PCN-node (i.e. a node within a PCN domain) will be configured to
	baseline encoding [RFC5696]. Like the baseline encoding it uses a		recognise certain DSCPs as PCN-compatible. Appendix A discusses the
	combination of a PCN-compatible DSCP (DSCP n in Figure 1) and the ECN		choice of suitable DSCPs. In Figure 1 'DSCP n' indicates such a PCN-
	field for the encoding of PCN-marks. Appendix A discusses the choice		compatible DSCP.
	of suitable DSCPs. The PCN-marks have the following meaning.
	Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not		A PCN-node MUST use the 3-in-1 PCN encoding, rather than [RFC3168],
	subject to PCN metering and marking.		to interpret the ECN field of any packet with a PCN-compatible DSCP.
			Conversely, for any packet with a DSCP that is not PCN-compatible, or
			for any non-PCN node (a node outside a PCN-domain), the node MUST
			interpret the ECN field using [RFC3168], rather than the 3-in-1
			encoding.
			When using the 3-in-1 encoding, the codepoints of the ECN field have
			the following meanings:
			Not-PCN: indicates a non-PCN-packet, i.e., a packet that uses a PCN-
			compatible DSCP but is not subject to PCN metering and marking.
	NM: Not-marked. Indicates a PCN-packet that has not yet been marked		NM: Not-marked. Indicates a PCN-packet that has not yet been marked
	by any PCN marker.		by any PCN marker.
	ThM: Threshold-marked. Indicates a PCN-packet that has been marked		ThM: Threshold-marked. Indicates a PCN-packet that has been marked
	by a threshold-marker [RFC5670].		by a threshold-marker [RFC5670].
	ETM: Excess-traffic-marked. Indicates a PCN-packet that has been		ETM: Excess-traffic-marked. Indicates a PCN-packet that has been
	marked by an excess-traffic-marker [RFC5670].		marked by an excess-traffic-marker [RFC5670].
	skipping to change at page 9, line 31		skipping to change at page 10, line 7
	[I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN		[I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN
	marking states are needed: not-marked (NM) to indicate not-marked		marking states are needed: not-marked (NM) to indicate not-marked
	packets, threshold-marked (ThM) to indicate packets marked by the		packets, threshold-marked (ThM) to indicate packets marked by the
	threshold-marker, and excess-traffic-marked (ETM) to indicate packets		threshold-marker, and excess-traffic-marked (ETM) to indicate packets
	marked by the excess-traffic-marker [RFC5670]. Threshold-marking and		marked by the excess-traffic-marker [RFC5670]. Threshold-marking and
	excess-traffic-marking are configured to start marking packets at		excess-traffic-marking are configured to start marking packets at
	different load conditions, so one marking behaviour indicates more		different load conditions, so one marking behaviour indicates more
	severe pre-congestion than the other. Therefore, a fourth PCN		severe pre-congestion than the other. Therefore, a fourth PCN
	marking state indicating that a packet is marked by both markers is		marking state indicating that a packet is marked by both markers is
	not needed. However a fourth codepoint is required to indicate		not needed. However a fourth codepoint is required to indicate
	packets that do not use PCN (the not-PCN codepoint).		packets that use a PCN-compatible DSCP but do not use PCN-marking
			(the not-PCN codepoint).
	In all current PCN edge behaviors that use two marking behaviours		In all current PCN edge behaviors that use two marking behaviours
	[RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking		[RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking
	is configured with a larger reference rate than threshold-marking.		is configured with a larger reference rate than threshold-marking.
	We take this as a rule and define excess-traffic-marked as a more		We take this as a rule and define excess-traffic-marked as a more
	severe PCN-mark than threshold-marked.		severe PCN-mark than threshold-marked.
	4.2. Requirements Imposed by Tunnelling		4.2. Requirements Imposed by Tunnelling
	[RFC6040] defines rules for the encapsulation and decapsulation of		[RFC6040] defines rules for the encapsulation and decapsulation of
	skipping to change at page 10, line 21		skipping to change at page 10, line 46
	also be used with only one marking behaviour, in which case one of		also be used with only one marking behaviour, in which case one of
	the codepoints MUST NOT be used throughout the PCN-domain (see		the codepoints MUST NOT be used throughout the PCN-domain (see
	Section 5.2.3).		Section 5.2.3).
	For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP		For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP
	and IPsec) within the PCN-domain MUST comply with the ECN		and IPsec) within the PCN-domain MUST comply with the ECN
	encapsulation and decapsulation rules set out in [RFC6040] (see		encapsulation and decapsulation rules set out in [RFC6040] (see
	Section 4.2). There is one exception to this rule outlined next.		Section 4.2). There is one exception to this rule outlined next.
	It may not be possible to upgrade every pre-RFC6040 tunnel endpoint		It may not be possible to upgrade every pre-RFC6040 tunnel endpoint
	within a PCN-domain. In such cirsumstances a limited version of the		within a PCN-domain. In such circumstances a limited version of the
	3-in-1 encoding can still be used but only under the following		3-in-1 encoding can still be used but only under the following
	stringent condition. If any pre-RFC6040 tunnel endpoint exists		stringent condition. If any pre-RFC6040 tunnel endpoint exists
	within a PCN-domain then every PCN-node in the PCN-domain MUST be		within a PCN-domain then every PCN-node in the PCN-domain MUST be
	configured so that it never sets the ThM codepoint. The behaviour of		configured so that it never sets the ThM codepoint. The behaviour of
	PCN-interior nodes in this case is defined in Section 5.2.3.1. In		PCN-interior nodes in this case is defined in Section 5.2.3.1, which
	all other situations where legacy tunnel endpoints might be present		describes the rules for using only the Excess Traffic marking
	within the PCN domain, the 3-in-1 encoding is not applicable.		function. In all other situations where legacy tunnel endpoints
			might be present within the PCN domain, the 3-in-1 encoding is not
			applicable.
	5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding		5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding
	As mentioned in Section 4.3 above, all PCN-nodes MUST comply with		As mentioned in Section 4.3 above, all PCN-nodes MUST comply with
	[RFC6040].		[RFC6040].
	5.1. PCN-ingress Node Behaviour		5.1. PCN-ingress Node Behaviour
	PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint.		PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint.
	To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are		To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are
	skipping to change at page 12, line 47		skipping to change at page 13, line 26
	A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all		A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all
	packets it forwards out of the PCN-domain.		packets it forwards out of the PCN-domain.
	The only exception to this is if the PCN-egress-node is certain that		The only exception to this is if the PCN-egress-node is certain that
	revealing other codepoints outside the PCN-domain won't contravene		revealing other codepoints outside the PCN-domain won't contravene
	the guidance given in [RFC4774]. For instance, if the PCN-ingress-		the guidance given in [RFC4774]. For instance, if the PCN-ingress-
	node has explicitly informed the PCN-egress-node that this flow is		node has explicitly informed the PCN-egress-node that this flow is
	ECN-capable, then it might be safe to expose other codepoints.		ECN-capable, then it might be safe to expose other codepoints.
	Appendix B gives details of how such schemes might work, but such		Appendix B gives details of how such schemes might work, but such
	schemes are currently experimental.		schemes are currently only tentative ideas.
	If the PCN-domain is configured to use only excess-traffic marking,		If the PCN-domain is configured to use only excess-traffic marking,
	the PCN-egress node MUST treat ThM as ETM and if only threshold-		the PCN-egress node MUST treat ThM as ETM and if only threshold-
	marking is used it should treat ETM as ThM. However it SHOULD raise		marking is used it should treat ETM as ThM. However it SHOULD raise
	a management alarm in either instance since this means there is some		a management alarm in either instance since this means there is some
	misconfiguration in the PCN-domain.		misconfiguration in the PCN-domain.
	6. Backward Compatibility		6. Backward Compatibility
	6.1. Backward Compatibility with ECN		6.1. Backward Compatibility with ECN
	skipping to change at page 16, line 11		skipping to change at page 16, line 40
	Notification Encoding",		Notification Encoding",
	draft-ietf-pcn-encoding-comparison-06 (work in progress),		draft-ietf-pcn-encoding-comparison-06 (work in progress),
	June 2011.		June 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-06		Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-06
	(work in progress), June 2011.		(work in progress), June 2011.
			[I-D.sarker-pcn-ecn-pcn-usecases]
			Sarker, Z. and I. Johansson, "Usecases and Benefits of end
			to end ECN support in PCN Domains",
			draft-sarker-pcn-ecn-pcn-usecases-01 (work in progress),
			May 2008.
	[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,		[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
	"Assured Forwarding PHB Group", RFC 2597, June 1999.		"Assured Forwarding PHB Group", RFC 2597, June 1999.
	[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,		[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
	J., Courtney, W., Davari, S., Firoiu, V., and D.		J., Courtney, W., Davari, S., Firoiu, V., and D.
	Stiliadis, "An Expedited Forwarding PHB (Per-Hop		Stiliadis, "An Expedited Forwarding PHB (Per-Hop
	Behavior)", RFC 3246, March 2002.		Behavior)", RFC 3246, March 2002.
	[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit		[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
	Congestion Notification (ECN) Signaling with Nonces",		Congestion Notification (ECN) Signaling with Nonces",
	skipping to change at page 17, line 5		skipping to change at page 17, line 39
	RFC 5696, November 2009.		RFC 5696, November 2009.
	[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated		[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
	Services Code Point (DSCP) for Capacity-Admitted Traffic",		Services Code Point (DSCP) for Capacity-Admitted Traffic",
	RFC 5865, May 2010.		RFC 5865, May 2010.
	Appendix A. Choice of Suitable DSCPs		Appendix A. Choice of Suitable DSCPs
	This appendix is informative, not normative.		This appendix is informative, not normative.
	The PCN working group chose not to define a single DSCP for use with		A single DSCP has not been defined for use with PCN for several
	PCN for several reasons. Firstly, the PCN mechanism is applicable to		reasons. Firstly, the PCN mechanism is applicable to a variety of
	a variety of different traffic classes. Secondly, Standards Track		different traffic classes. Secondly, Standards Track DSCPs are in
	DSCPs are in increasingly short supply. Thirdly, PCN is not a		increasingly short supply. Thirdly, PCN is not a scheduling
	scheduling behaviour -- rather, it should be seen as being a marking		behaviour -- rather, it should be seen as being a marking behaviour
	behaviour similar to ECN but intended for inelastic traffic. The		similar to ECN but intended for inelastic traffic. The choice of
	choice of which DSCP is most suitable for a given PCN-domain is		which DSCP is most suitable for a given PCN-domain is dependent on
	dependent on the nature of the traffic entering that domain and the		the nature of the traffic entering that domain and the link rates of
	link rates of all the links making up that domain. In PCN-domains		all the links making up that domain. In PCN-domains with sufficient
	with sufficient aggregation, the appropriate DSCPs would currently be		aggregation, the appropriate DSCPs would currently be those for the
	those for the Real-Time Treatment Aggregate [RFC5127]. The PCN		Real-Time Treatment Aggregate [RFC5127]. It is suggested that
	working group suggests using admission control for the following		admission control could be used for the following service classes
	service classes (defined in [RFC4594]):		(defined in [RFC4594] unless otherwise stated):
	o Telephony (EF)		o Telephony (EF)
	o Real-time interactive (CS4)		o Real-time interactive (CS4)
	o Broadcast Video (CS3)		o Broadcast Video (CS3)
	o Multimedia Conferencing (AF4)		o Multimedia Conferencing (AF4)
			o the VOICE-ADMIT codepoint defined in [RFC5865].
	CS5 is excluded from this list since PCN is not expected to be		CS5 is excluded from this list since PCN is not expected to be
	applied to signalling traffic. PCN can also be applied to the VOICE-		applied to signalling traffic.
	ADMIT codepoint defined in [RFC5865].
	PCN-marking is intended to provide a scalable admission-control		PCN-marking is intended to provide a scalable admission-control
	mechanism for traffic with a high degree of statistical multiplexing.		mechanism for traffic with a high degree of statistical multiplexing.
	PCN-marking would therefore be appropriate to apply to traffic in the		PCN-marking would therefore be appropriate to apply to traffic in the
	above classes, but only within a PCN-domain containing sufficiently		above classes, but only within a PCN-domain containing sufficiently
	aggregated traffic. In such cases, the above service classes may		aggregated traffic. In such cases, the above service classes may
	well all be subject to a single forwarding treatment (treatment		well all be subject to a single forwarding treatment (treatment
	aggregate [RFC5127]). However, this does not imply all such IP		aggregate [RFC5127]). However, this does not imply all such IP
	traffic would necessarily be identified by one DSCP -- each service		traffic would necessarily be identified by one DSCP -- each service
	class might keep a distinct DSCP within the highly aggregated region		class might keep a distinct DSCP within the highly aggregated region
	skipping to change at page 18, line 19		skipping to change at page 19, line 6
	The PCN encoding described in this document re-uses the bits of the		The PCN encoding described in this document re-uses the bits of the
	ECN field in the IP header. Consequently, this disables ECN within		ECN field in the IP header. Consequently, this disables ECN within
	the PCN domain. Appendix B of [RFC5696] (obsoleted) included advice		the PCN domain. Appendix B of [RFC5696] (obsoleted) included advice
	on handling ECN traffic within a PCN-domain. This appendix		on handling ECN traffic within a PCN-domain. This appendix
	reiterates and clarifies that advice.		reiterates and clarifies that advice.
	For the purposes of this appendix we define two forms of traffic that		For the purposes of this appendix we define two forms of traffic that
	might arrive at a PCN-ingress node. These are Admission-controlled		might arrive at a PCN-ingress node. These are Admission-controlled
	traffic and Non-admission-controlled traffic.		traffic and Non-admission-controlled traffic.
	Admission-controlled traffic will be remarked to a PCN-compatible		Admission-controlled traffic will be re-marked to a PCN-compatible
	DSCP by the PCN-ingress node. Two mechanisms can be used to identify		DSCP by the PCN-ingress node. Two mechanisms can be used to identify
	such traffic:		such traffic:
	a. flow signalling associates a filterspec with a need for admission		a. flow signalling associates a filterspec with a need for admission
	control (e.g. through RSVP or some equivalent message, e.g. from		control (e.g. through RSVP or some equivalent message, e.g. from
	a SIP server to the ingress), and the PCN-ingress remarks traffic		a SIP server to the ingress), and the PCN-ingress re-marks
	matching that filterspec to a PCN-compatible DSCP, as its chosen		traffic matching that filterspec to a PCN-compatible DSCP, as its
	admission control mechanism.		chosen admission control mechanism.
	b. Traffic arrives with a DSCP that implies it requires admission		b. Traffic arrives with a DSCP that implies it requires admission
	control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time,		control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time,
	Broadcast TV when used for video on demand, and Multimedia		Broadcast TV when used for video on demand, and Multimedia
	Conferencing [RFC4594][RFC5865].		Conferencing [RFC4594][RFC5865] (see Appendix A).
	All other traffic can be thought of as Non-admission-controlled (and		All other traffic can be thought of as Non-admission-controlled (and
	therefore outside the scope of PCN). However such traffic may still		therefore outside the scope of PCN). However such traffic may still
	need to share the same DSCP as the Admission-controlled traffic.		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		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.		traffic), or may be because there is a shortage of local DSCPs.
	ECN [RFC3168] is an end-to-end congestion notification mechanism. As		ECN [RFC3168] is an end-to-end congestion notification mechanism. As
	such it is possible that some traffic entering the PCN-domain may		such it is possible that some traffic entering the PCN-domain may
	also be ECN capable.		also be ECN capable.
	Unless specified otherwise, for any of the cases in the list below,		Unless specified otherwise, for any of the cases in the list below,
	an IP-in-IP tunnel can be used to preserve ECN markings across the		an IP-in-IP tunnel can be used to preserve ECN markings across the
	PCN domain. However the tunnelling action should be applied wholly		PCN domain. The tunnelling action should be applied wholly outside
	outside the PCN-domain as illustrated in the following figure:		the PCN-domain as illustrated in the following figure:
	, . . . . . PCN-domain . . . . . .		, . . . . . PCN-domain . . . . . .
	. ,--------. ,--------. .		. ,--------. ,--------. .
	. _| PCN- |___________________| PCN- |_ .		. _| PCN- |___________________| PCN- |_ .
	. / | ingress | | egress | \ .		. / | ingress | | egress | \ .
	.| '---------' '--------' |.		.| '---------' '--------' |.
	| . . . . . . . . . . . . . . .|		| . . . . . . . . . . . . . . .|
	,--------. ,--------.		,--------. ,--------.
	_____| Tunnel | | Tunnel |____		_____| Tunnel | | Tunnel |____
	| Ingress | - - ECN preserved inside tunnel - - | Egress |		| Ingress | - - ECN preserved inside tunnel - - | Egress |
	'---------' '--------'		'---------' '--------'
	Figure 2: Separation of tunneling and PCN actions		Figure 2: Separation of tunneling and PCN actions
	There are four cases for how e2e ECN traffic may wish to be treated		There are three cases for how e2e ECN traffic may wish to be treated
	while crossing a PCN domain:		while crossing a PCN domain:
	ECN capable traffic that does not require admission control and does		a) Does not require admission control:
	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		* Does not carry a PCN-compatible DSCP: No action required.
	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		* Arrives carrying a DSCP that uses the same codepoint as a PCN-
	scheduling PHB as the original DSCP, and the egress re-maps it		compatible DSCP: There are two options:
	to the original PCN-compatible DSCP.
	* The ingress tunnels the traffic, setting not-PCN in the outer		1. The ingress maps the DSCP to a local DSCP with the same
	header; note that this turns off ECN for this traffic within		scheduling PHB as the original DSCP, and the egress re-maps
	the PCN domain.		it to the original PCN-compatible DSCP.
	The first option is recommended unless the operator is short of		2. The ingress tunnels the traffic, setting not-PCN in the
	local DSCPs.		outer header; note that this turns off ECN for this traffic
			within the PCN domain.
	ECN-capable Admission-controlled traffic: There are two options.		The first option is recommended unless the operator is short of
			local DSCPs.
			b) Requires Admission-control: There are two options.
	* The PCN-ingress places this traffic in a tunnel with a PCN-		* The PCN-ingress places this traffic in a tunnel with a PCN-
	compatible DSCP in the outer header. The PCN-egress zeroes the		compatible DSCP in the outer header. The PCN-egress zeroes the
	ECN-field before decapsulation.		ECN-field before decapsulation.
	* The PCN-ingress drops CE-marked packets and the PCN-egress		* The PCN-ingress drops CE-marked packets and the PCN-egress
	zeros the ECN field of all PCN packets.		zeros the ECN field of all PCN packets.
	The second option is emphatically not recommended, unless perhaps		The second option is emphatically not recommended, unless perhaps
	as a last resort if tunnelling is not possible for some		as a last resort if tunnelling is not possible for some
	insurmountable reason.		insurmountable reason.
	ECN-capable Admission-controlled traffic where the e2e transport		c) Requires Admission Control and asks to see PCN marks: NOTE this
	somehow indicates that it wants to see PCN marks: NOTE this is		scheme is currently only a tentative idea.
	currently tentative only.
	Schemes have been suggested where PCN marks may be leaked out of		For real-time data generated by an adaptive codec, schemes have
	the PCN-domain and used by the end hosts to modify realtime data		been suggested [I-D.sarker-pcn-ecn-pcn-usecases] where PCN marks
	rates. Currently all such schemes require further study and the		may be leaked out of the PCN-domain so that end hosts can drop to
	following is for guidance only.		a lower data rate, thus deferring the need for admission control.
			Currently such schemes require further study and the following is
			for guidance only.
	The PCN-ingress needs to tunnel the traffic, taking care to comply		The PCN-ingress needs to tunnel the traffic as in Figure 2, taking
	with [RFC6040]. In this case the PCN-egress should not zero the		care to comply with [RFC6040]. In this case the PCN-egress should
	ECN field, and then the [RFC6040] tunnel egress will preserve any		not zero the ECN field, and then the [RFC6040] tunnel egress will
	PCN-marking. Note that a PCN interior node may turn ECT(0) into		preserve any PCN-marking. Note that a PCN interior node may turn
	ECT(1), which would not be compatible with the (currently		ECT(0) into ECT(1), which would not be compatible with the
	experimental) ECN nonce [RFC3540].		(currently experimental) ECN nonce [RFC3540].
	Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in		Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in
	MPLS Shim Headers		MPLS Shim Headers
	This appendix is informative not normative.		This appendix is informative not normative.
	The 6 bits of the DS field in the IP header provide for 64		The 6 bits of the DS field in the IP header provide for 64
	codepoints. When encapsulating IP traffic in MPLS, it is useful to		codepoints. When encapsulating IP traffic in MPLS, it is useful to
	make the DS field information accessible in the MPLS header.		make the DS field information accessible in the MPLS header.
	However, the MPLS shim header has only a 3-bit traffic class (TC)		However, the MPLS shim header has only a 3-bit traffic class (TC)
	field [RFC5462] providing for 8 codepoints. The operator has the		field [RFC5462] providing for 8 codepoints. The operator has the
	freedom to define a site-local mapping of a subset of the 64		freedom to define a site-local mapping of the 64 codepoints of the DS
	codepoints of the DS field to the 8 codepoints in the TC field.		field onto the 8 codepoints in the TC field.
	[RFC5129] describes how ECN markings in the IP header can also be		[RFC5129] describes how ECN markings in the IP header can also be
	mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129]		mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129]
	gives an informative description of how to support PCN in MPLS by		gives an informative description of how to support PCN in MPLS by
	extending the way MPLS supports ECN. But [RFC5129] was written while		extending the way MPLS supports ECN. But [RFC5129] was written while
	PCN specifications were in early draft stages. The following		PCN specifications were in early draft stages. The following
	provides a clearer example of a mapping between PCN in IP and in MPLS		provides a clearer example of a mapping between PCN in IP and in MPLS
	using the PCN terminology and concepts that have since been		using the PCN terminology and concepts that have since been
	specified.		specified.
	To support PCN in a MPLS domain, codepoints for all used PCN-marks		To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n')
	need to be provided in the TC field. That means, when e.g. only		needs codepoints to be provided in the TC field for all the PCN-marks
	excess-traffic-marking is used for PCN purposes, the operator needs		used. That means, when for instance only excess-traffic-marking is
	to define a site-local mapping to codepoints in the MPLS TC field for		used for PCN purposes, the operator needs to define a site-local
	IP headers with:		mapping to two codepoints in the MPLS TC field for IP headers with:
	o DSCP n and ECT(0)		o DSCP n and ECT(0)
	o DSCP n and CE		o DSCP n and CE
	If both excess-traffic-marking and threshold-marking are used, the		If both excess-traffic-marking and threshold-marking are used, the
	operator needs to define a site-local mapping to codepoints in the		operator needs to define a site-local mapping to codepoints in the
	MPLS TC field for IP headers with all three of the 3-in-1 codepoints:		MPLS TC field for IP headers with all three of the 3-in-1 codepoints:
	o DSCP n and ECT(0)		o DSCP n and ECT(0)
	skipping to change at page 21, line 26		skipping to change at page 22, line 7
	o DSCP n and CE		o DSCP n and CE
	In either case, if the operator wishes to support the same Diffserv		In either case, if the operator wishes to support the same Diffserv
	PHB but without PCN marking, it will also be necessary to define a		PHB but without PCN marking, it will also be necessary to define a
	site-local mapping to an MPLS TC codepoint for IP headers marked		site-local mapping to an MPLS TC codepoint for IP headers marked
	with:		with:
	o DSCP n and Not-ECT		o DSCP n and Not-ECT
	Appendix D. Rationale for different behaviours for single marking		Clearly, given so few TC codepoints are available, it may be
	schemes		necessary to compromise by merging together some capabilities.
	Readers may notice an apparent discrepancy between the two single		Appendix D. Rationale for Discrepancy Between the Schemes using One
	marking behaviours in Section 5.2.3.1 and Section 5.2.3.2. For the		PCN-Marking
	excess-traffic only marking an unexpected ThM marked packet is
	remarked as ETM. For the threshold only marking, an unexpected ETM
	marked packet is simply ignored (apart from an optional management
	alarm).
	There are two reasons for having these seemingly contradictory		Readers may notice an apparent discrepancy between the two behaviours
	requirements. Firstly these behaviours conform with the expected		in Section 5.2.3.1 and Section 5.2.3.2. With only excess-traffic
	behaviour where both metering functions are being used for marking--		marking enabled, an unexpected ThM packet can be re-marked to ETM.
	ETM is always a more severe marking than ThM and so should never be		However, with only threshold marking, an unexpected ETM packet cannot
	re-marked. Secondly the threshold-metering behaviour in [RFC5670]		be re-marked to ThM.
	uses the current marking state of the arriving packet to determine
	what action to take. Consequently, in the ETM only marking it would		This apparent inconsistency is deliberate, for two reasons:
	be potentially unsafe to allow ThM packets to propagate forward in
	the network as they may adversely affect the threshold-metering		o If only one type of marking function is meant to be used
	function.		throughout the PCN-domain but the other type unexpectedly appears
			on some packets, it is safest to assume that some link is trying
			to signal that it is pre-congested, but that it is somehow using
			the wrong signal. This only needs to be corrected if the
			behaviour of other nodes depends on the marking a packet arrives
			with. In [RFC5670], the excess-traffic-metering behaviour depends
			on the markings on arriving packets, whereas threshold-metering
			does not. Therefore, if ThM should not be present, it seems safe
			to allow it to be re-marked to ETM, but if ETM should not be
			present there is no need to re-mark it to ThM.
			o The behaviour with only threshold marking keeps to the rule that
			ETM is more severe and must never be changed to ThM even though
			ETM is not a valid marking in this case. Otherwise
			implementations would have to allow operators to configure an
			exception to this rule, which would not be safe practice.
	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
End of changes. 44 change blocks.
	115 lines changed or deleted		159 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/