draft-ietf-pcn-3-in-1-encoding-07.txt		draft-ietf-pcn-3-in-1-encoding-08.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 31, 2012 University of Tuebingen		Expires: February 19, 2012 University of Tuebingen
	July 30, 2011		August 18, 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-07		draft-ietf-pcn-3-in-1-encoding-08
	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
	flows during serious pre-congestion.		flows during serious pre-congestion.
	This document specifies how PCN-marks are to be encoded into the IP		This document specifies how PCN-marks are to be encoded into the IP
	header by re-using the Explicit Congestion Notification (ECN)		header by re-using the Explicit Congestion Notification (ECN)
	codepoints within a PCN-domain. This encoding provides for up to		codepoints within a PCN-domain. This encoding provides for up to
	three different PCN marking states using a single DSCP: not-marked		three different PCN marking states using a single DSCP: not-marked
	(NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence,		(NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence,
	it is called the 3-in-1 PCN encoding. This document obsoletes		it is called the 3-in-1 PCN encoding. This document obsoletes
	RFC5696.		RFC5696.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 31, 2012.		This Internet-Draft will expire on February 19, 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 27		skipping to change at page 3, line 27
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 11		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 . . . . . . . . . . . . . . . . . . . . . 12		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 . . . . . . . . . . . . . . . . . . . . . 12		PCN-marking . . . . . . . . . . . . . . . . . . . . . 12
	5.3. Behaviour of PCN-egress Nodes . . . . . . . . . . . . . . 13		5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 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 . . . . 14		6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		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 . . . . . . . . . . . . . . . . . . 16		12.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 17		Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 18
	Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 18		Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 19
	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 Discrepancy Between the Schemes		Appendix D. Rationale for Difference Between the Schemes
	using One PCN-Marking . . . . . . . . . . . . . . . . 22		using One PCN-Marking . . . . . . . . . . . . . . . . 22
	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 4, line 32		skipping to change at page 4, line 32
	marking marks all PCN packets once their traffic rate on a link		marking marks all PCN packets once their traffic rate on a link
	exceeds the configured reference rate (PCN-threshold-rate). Excess-		exceeds the configured reference rate (PCN-threshold-rate). Excess-
	traffic-marking marks only those PCN packets that exceed the		traffic-marking marks only those PCN packets that exceed the
	configured reference rate (PCN-excess-rate). The PCN-excess-rate is		configured reference rate (PCN-excess-rate). The PCN-excess-rate is
	typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes		typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes
	monitor the PCN-marks of received PCN-packets and pass information		monitor the PCN-marks of received PCN-packets and pass information
	about these PCN-marks to decision points which then decide whether to		about these PCN-marks to decision points which then decide whether to
	admit new flows or terminate existing flows		admit new flows or terminate existing flows
	[I-D.ietf-pcn-cl-edge-behaviour], [I-D.ietf-pcn-sm-edge-behaviour].		[I-D.ietf-pcn-cl-edge-behaviour], [I-D.ietf-pcn-sm-edge-behaviour].
	The baseline encoding defined in [RFC5696] described how two PCN		The encoding defined in [RFC5696] described how two PCN marking
	marking states (Not-marked and PCN-Marked) could be encoded into the		states (Not-marked and PCN-Marked) could be encoded into the IP
	IP header using a single Diffserv codepoint. It also provided an		header using a single Diffserv codepoint. It defined 01 as an
	experimental codepoint (EXP), along with guidelines for the use of		experimental codepoint (EXP), along with guidelines for its use. Two
	that codepoint. Two PCN marking states are sufficient for the Single		PCN marking states are sufficient for the Single Marking edge
	Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However,		behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However, PCN-domains
	PCN-domains utilising the controlled load edge behaviour		utilising the controlled load edge behaviour
	[I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states.		[I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states.
	This document extends the baseline encoding by redefining the EXP		This document extends the RFC5696 encoding by redefining the
	codepoint to provide a third PCN marking state in the IP header,		experimental codepoint as a third PCN marking state in the IP header,
	still using a single Diffserv codepoint. This encoding scheme is		still using a single Diffserv codepoint. This encoding scheme is
	therefore called the "3-in-1 PCN encoding". It obsoletes the		therefore called the "3-in-1 PCN encoding". It obsoletes the
	baseline encoding [RFC5696], which provides only a sub-set of the		[RFC5696] encoding, which provides only a sub-set of the same
	same capabilities.		capabilities.
	The full version of this encoding requires any tunnel endpoint within		The full version of this encoding requires any tunnel endpoint within
	the PCN-domain to support the normal tunnelling rules defined in		the PCN-domain to support the normal tunnelling rules defined in
	[RFC6040]. There is one limited exception to this constraint where		[RFC6040]. There is one limited exception to this constraint where
	the PCN-domain only uses the excess-traffic-marking behaviour and		the PCN-domain only uses the excess-traffic-marking behaviour and
	where the threshold-marking behaviour is deactivated. This is		where the threshold-marking behaviour is deactivated. This is
	discussed in Section 5.2.3.1.		discussed in Section 5.2.3.1.
	This document only concerns the PCN wire protocol encoding for IP		This document only concerns the PCN wire protocol encoding for IP
	headers, whether IPv4 or IPv6. It makes no changes or		headers, whether IPv4 or IPv6. It makes no changes or
	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-07 to -08: Editorial corrections
			and clarifications.
	From draft-ietf-pcn-3-in-1-encoding-06 to -07:		From draft-ietf-pcn-3-in-1-encoding-06 to -07:
	* Clarified that each operator not the IETF chooses which DSCP(s)		* Clarified that each operator not the IETF chooses which DSCP(s)
	are PCN-compatible, and made it unambiguous that only PCN-nodes		are PCN-compatible, and made it unambiguous that only PCN-nodes
	recognise that PCN-compatible DSCPs enable the 3-in-1 encoding.		recognise that PCN-compatible DSCPs enable the 3-in-1 encoding.
	* Removed statements about the PCN working group, given RFCs are		* Removed statements about the PCN working group, given RFCs are
	meant to survive beyond the life of a w-g.		meant to survive beyond the life of a w-g.
	* Corrected the final para of "Rationale for Different Behaviours		* Corrected the final para of "Rationale for Different Behaviours
	skipping to change at page 7, line 32		skipping to change at page 7, line 39
	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 carries PCN-markings rather than		packets for which the ECN field carries PCN-markings rather than
	[RFC3168] markings. Note that an operator configures PCN-nodes to		[RFC3168] markings. Note that an operator configures PCN-nodes to
	recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN-		recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN-
	specific meaning to a node outside the PCN domain.		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 a packet has
	have been marked at a PCN-interior-node as a result of an		been threshold-marked; that is a packet that has been marked at a
	indication from the threshold-metering function [RFC5670].		PCN-interior-node as a result of an indication from the threshold-
	Abbreviated to ThM.		metering function [RFC5670]. 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.
	Not-marked codepoint: a codepoint that indicates PCN-packets but		Not-marked codepoint: a codepoint that indicates PCN-packets that
	that are not PCN-marked. Abbreviated to NM.		are not PCN-marked. Abbreviated to NM.
	not-PCN codepoint: a codepoint that indicates packets that are not		not-PCN codepoint: a codepoint that indicates packets that are not
	PCN-packets.		PCN-packets.
	2.2. List of Abbreviations		2.2. List of Abbreviations
	The following abbreviations are used in this document:		The following abbreviations are used in this document:
	o AF = Assured Forwarding [RFC2597]		o AF = Assured Forwarding [RFC2597]
	skipping to change at page 8, line 49		skipping to change at page 9, line 4
	shown in Figure 1.		shown in Figure 1.
	+--------+----------------------------------------------------+		+--------+----------------------------------------------------+
	| | 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
	A PCN-node (i.e. a node within a PCN-domain) will be configured to		A PCN-node (i.e. a node within a PCN-domain) will be configured to
	recognise certain DSCPs as PCN-compatible. Appendix A discusses the		recognise certain DSCPs as PCN-compatible. Appendix A discusses the
	choice of suitable DSCPs. In Figure 1 'DSCP n' indicates such a PCN-		choice of suitable DSCPs. In Figure 1 'DSCP n' indicates such a PCN-
	compatible DSCP. Within the PCN-domain, any packet carrying a PCN-		compatible DSCP. Within the PCN-domain, any packet carrying a PCN-
	compatible DSCP is a PCN-packet as defined in [RFC5559].		compatible DSCP and with the ECN-field anything other than 00 (Not-
			PCN) is a PCN-packet as defined in [RFC5559].
	PCN-nodes MUST interpret the ECN field of a PCN-packet using the		PCN-nodes MUST interpret the ECN field of a PCN-packet using the
	3-in-1 PCN encoding, rather than [RFC3168]. This does not change the		3-in-1 PCN encoding, rather than [RFC3168]. This does not change the
	behaviour for any packet with a DSCP that is not PCN-compatible, or		behaviour for any packet with a DSCP that is not PCN-compatible, or
	for any node outside a PCN-domain. In all such cases the 3-in-1		for any node outside a PCN-domain. In all such cases the 3-in-1
	encoding is not applicable and so by default the node will interpret		encoding is not applicable and so by default the node will interpret
	the ECN field using [RFC3168].		the ECN field using [RFC3168].
	When using the 3-in-1 encoding, the codepoints of the ECN field have		When using the 3-in-1 encoding, the codepoints of the ECN field have
	the following meanings:		the following meanings:
	skipping to change at page 10, line 21		skipping to change at page 10, line 23
	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
	ECN markings within IP-in-IP tunnels. The publication of RFC6040		ECN markings within IP-in-IP tunnels. The publication of RFC6040
	removed the tunnelling constraints that existed when the baseline		removed the tunnelling constraints that existed when the encoding of
	encoding [RFC5696] was written (see section 3.3.2 of		[RFC5696] was written (see section 3.3.2 of
	[I-D.ietf-pcn-encoding-comparison]).		[I-D.ietf-pcn-encoding-comparison]).
	Nonetheless, there is still a problem if there are any legacy (pre-		Nonetheless, there is still a problem if there are any legacy (pre-
	RFC6040) decapsulating tunnel endpoints within a PCN domain. If a		RFC6040) decapsulating tunnel endpoints within a PCN domain. If a
	PCN node Threshold-marks the outer header of a tunnelled packet with		PCN node Threshold-marks the outer header of a tunnelled packet that
	a Not-marked codepoint on the inner header, the legacy decapsulator		has a Not-marked codepoint on the inner header, a legacy decapsulator
	will revert the Threshold-marking to Not-marked. The rules on		will forward the packet as Not-marked, losing the threshold marking.
	applicability in Section 4.3 below are designed to avoid this		The rules on applicability in Section 4.3 below are designed to avoid
	problem.		this problem.
	4.3. Applicability of 3-in-1 PCN Encoding		4.3. Applicability of 3-in-1 PCN Encoding
	The 3-in-1 encoding is applicable in situations where two marking		The 3-in-1 encoding is applicable in situations where two marking
	behaviours are being used in the PCN-domain. The 3-in-1 encoding can		behaviours are being used in the PCN-domain. The 3-in-1 encoding can
	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		With one exception (see next paragraph), any tunnel endpoints
	and IPsec) within the PCN-domain MUST comply with the ECN		(IP-in-IP 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).
	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 circumstances 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. PCN-interior
	PCN-interior nodes in this case is defined in Section 5.2.3.1, which		nodes in this case MUST solely use the Excess Traffic marking
	describes the rules for using only the Excess Traffic marking		function, as defined in Section 5.2.3.1. In all other situations
	function. In all other situations where legacy tunnel endpoints		where legacy tunnel endpoints might be present within the PCN domain,
	might be present within the PCN domain, the 3-in-1 encoding is not		the 3-in-1 encoding is not applicable.
	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		Any tunnel endpoint implementation on a PCN-node MUST comply with
	[RFC6040].		[RFC6040]. Since PCN is a new capability, this is considered a
			reasonable requirement.
	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
	already defined for use with admission-controlled traffic.		already defined for use with admission-controlled traffic.
	Appendix A gives guidance to implementors on suitable DSCPs.		Appendix A gives guidance to implementors on suitable DSCPs.
	Guidelines for mixing traffic types within a PCN-domain are given in		Guidelines for mixing traffic types within a PCN-domain are given in
	[RFC5670].		[RFC5670].
	If a packet arrives at the PCN-ingress-node that shares a PCN-		If a packet arrives at the PCN-ingress-node that shares a PCN-
	compatible DSCP and is not a PCN-packet, the PCN-ingress MUST mark it		compatible DSCP and is not a PCN-packet, the PCN-ingress-node MUST
	as not-PCN.		mark it as not-PCN.
	If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress MUST		If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress-node
	change the PCN codepoint to Not-marked.		MUST change the PCN codepoint to Not-marked.
	If a PCN-packet arrives at the PCN-ingress-node with its ECN field		If a PCN-packet arrives at the PCN-ingress-node with its ECN field
	already set to a value other than not-ECT, then appropriate action		already set to a value other than not-ECT, then appropriate action
	MUST be taken to meet the requirements of [RFC4774]. The simplest		MUST be taken to meet the requirements of [RFC4774]. The simplest
	appropriate action is to just drop such packets. However, this is a		appropriate action is to just drop such packets. However, this is a
	drastic action that an operator may feel is undesirable. Appendix B		drastic action that an operator may feel is undesirable. Appendix B
	provides more information and summarises other alternative actions		provides more information and summarises other alternative actions
	that might be taken.		that might be taken.
	5.2. PCN-interior Node Behaviour		5.2. PCN-interior Node Behaviour
	skipping to change at page 12, line 7		skipping to change at page 12, line 7
	Interior nodes MUST NOT change not-PCN to any other codepoint.		Interior nodes MUST NOT change not-PCN to any other codepoint.
	Interior nodes MUST NOT change NM to not-PCN.		Interior nodes MUST NOT change NM to not-PCN.
	Interior nodes MUST NOT change ThM to NM or not-PCN.		Interior nodes MUST NOT change ThM to NM or not-PCN.
	Interior nodes MUST NOT change ETM to any other codepoint.		Interior nodes MUST NOT change ETM to any other codepoint.
	5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings		5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings
	If the threshold-meter function indicates a need to mark the packet,		If the threshold-meter function indicates a need to mark a packet,
	the PCN-interior node MUST change NM to ThM.		the PCN-interior node MUST change NM to ThM.
	If the excess-traffic-meter function indicates a need to mark the		If the excess-traffic-meter function indicates a need to mark a
	packet:		packet:
	o the PCN-interior node MUST change NM to ETM;		o the PCN-interior node MUST change NM to ETM;
	o the PCN-interior node MUST change ThM to ETM.		o the PCN-interior node MUST change ThM to ETM.
	If both the threshold meter and the excess-traffic meter indicate the		If both the threshold meter and the excess-traffic meter indicate the
	need to mark a packet, the excess traffic marking rules MUST take		need to mark a packet, the Excess-traffic-marking rules MUST take
	priority.		precedence.
	5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking		5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking
	Some PCN edge behaviours require only one PCN-marking within the PCN-		Some PCN edge behaviours require only one PCN-marking within the PCN-
	domain. The Single Marking edge behaviour		domain. The Single Marking edge behaviour
	[I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark		[I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark
	packets using the excess-traffic-meter function [RFC5670]. It is		packets using the excess-traffic-meter function [RFC5670]. It is
	possible that future schemes may require only the threshold-meter		possible that future schemes may require only the threshold-meter
	function. Observant readers may spot an apparent inconsistency		function. Appendix D explains the rationale for the behaviours
	between the two following cases. Appendix D explains the rationale		defined in this section.
	behind this inconsistency.
	5.2.3.1. Marking using only the Excess-traffic-meter Function		5.2.3.1. Marking Using only the Excess-traffic-meter Function
	The threshold-traffic-meter function SHOULD be disabled and MUST NOT		The threshold-traffic-meter function SHOULD be disabled and MUST NOT
	trigger any packet marking.		trigger any packet marking.
	The PCN-interior node SHOULD raise a management alarm if it receives		The PCN-interior node SHOULD raise a management alarm if it receives
	a ThM packet, but the frequency of such alarms SHOULD be limited.		a ThM packet, but the frequency of such alarms SHOULD be limited.
	If the excess-traffic-meter function indicates a need to mark the		If the excess-traffic-meter function indicates a need to mark the
	packet:		packet:
	skipping to change at page 13, line 13		skipping to change at page 13, line 11
	trigger any packet marking.		trigger any packet marking.
	The PCN-interior node SHOULD raise a management alarm if it receives		The PCN-interior node SHOULD raise a management alarm if it receives
	an ETM packet, but the frequency of such alarms SHOULD be limited.		an ETM packet, but the frequency of such alarms SHOULD be limited.
	If the threshold-meter function indicates a need to mark the packet:		If the threshold-meter function indicates a need to mark the packet:
	o the PCN-interior node MUST change NM to ThM;		o the PCN-interior node MUST change NM to ThM;
	o the PCN-interior node MUST NOT change ETM to any other codepoint.		o the PCN-interior node MUST NOT change ETM to any other codepoint.
	It SHOULD raise an alarm as above.		It SHOULD raise an alarm as above if it encounters an ETM packet.
	5.3. Behaviour of PCN-egress Nodes		5.3. PCN-egress Node Behaviour
	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 only tentative ideas.		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
	BCP 124 [RFC4774] gives guidelines for specifying alternative		BCP 124 [RFC4774] gives guidelines for specifying alternative
	semantics for the ECN field. It sets out a number of factors to be		semantics for the ECN field. It sets out a number of factors to be
	taken into consideration. It also suggests various techniques to		taken into consideration. It also suggests various techniques to
	allow the co-existence of default ECN and alternative ECN semantics.		allow the co-existence of default ECN and alternative ECN semantics.
	The encoding specified in this document uses one of those techniques;		The encoding specified in this document uses one of those techniques;
	it defines PCN-compatible Diffserv codepoints as no longer supporting		it defines PCN-compatible Diffserv codepoints as no longer supporting
	the default ECN semantics. As such, this document is compatible with		the default ECN semantics within a PCN domain. As such, this
	BCP 124.		document is compatible with BCP 124.
	On its own, the 3-in-1 encoding cannot support both ECN marking end-		On its own, the 3-in-1 encoding cannot support both ECN marking end-
	to-end (e2e) and PCN-marking within a PCN-domain. Appendix B		to-end (e2e) and PCN-marking within a PCN-domain. Appendix B
	discusses possible ways to do this, e.g. by carrying e2e ECN across a		discusses possible ways to do this, e.g. by carrying e2e ECN across a
	PCN-domain within the inner header of an IP-in-IP tunnel. Although		PCN-domain within the inner header of an IP-in-IP tunnel. Although
	Appendix B recommends various approaches over others, it is merely		Appendix B recommends various approaches over others, it is merely
	informative and all such schemes are beyond the normative scope of		informative and all such schemes are beyond the normative scope of
	this document.		this document.
	In any PCN deployment, traffic can only enter the PCN-domain through		In any PCN deployment, traffic can only enter the PCN-domain through
	PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-		PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-
	nodes ensure that any packets entering the PCN-domain have the ECN		nodes ensure that any packets entering the PCN-domain have the ECN
	field in their outermost IP header set to the appropriate PCN		field in their outermost IP header set to the appropriate codepoint.
	codepoint. PCN-egress-nodes then guarantee that the ECN field of any		PCN-egress-nodes then guarantee that the ECN field of any packet
	packet leaving the PCN-domain has appropriate ECN semantics. This		leaving the PCN-domain has appropriate ECN semantics. This prevents
	prevents unintended leakage of ECN marks into or out of the PCN-		unintended leakage of ECN marks into or out of the PCN-domain, and
	domain, and thus reduces backward-compatibility issues.		thus reduces backward-compatibility issues.
	6.2. Backward Compatibility with the Baseline Encoding		6.2. Backward Compatibility with the RFC5696 Encoding
	A PCN node implemented to use the obsoleted baseline encoding could		A PCN node implemented to use the obsoleted RFC5696 encoding could
	conceivably have been configured so that the Threshold-meter function		conceivably have been configured so that the Threshold-meter function
	marked what is now defined as the ETM codepoint in the 3-in-1		marked what is now defined as the ETM codepoint in the 3-in-1
	encoding. However, thre is no known deployment of such an		encoding. However, there is no known deployment of such an
	implementation and no reason to believe that such an implementation		implementation and no reason to believe that such an implementation
	would ever have been built. Therefore, it seems safe to ignore this		would ever have been built. Therefore, it seems safe to ignore this
	issue.		issue.
	7. IANA Considerations		7. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	skipping to change at page 15, line 25		skipping to change at page 15, line 20
	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.
	In general, the use of this PCN encoding scheme presupposes that any		In general, the use of this PCN encoding scheme presupposes that any
	tunnel endpoints within the PCN-domain comply with [RFC6040].		tunnel endpoints within the PCN-domain comply with [RFC6040].
	10. Acknowledgements		10. Acknowledgements
	Many thanks to Phil Eardley for providing extensive feedback,		Many thanks to Phil Eardley for providing extensive feedback,
	critcism and advice. Thanks also to Teco Boot, Kwok Ho Chan,		criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan,
	Ruediger Geib, Georgios Karaginannis and everyone else who has		Ruediger Geib, Georgios Karaginannis and everyone else who has
	commented on the document.		commented on the 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
	12.1. Normative References		12.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use
	Requirement Levels", BCP 14, RFC 2119, March 1997.		in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119,
			March 1997.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker,
	"Definition of the Differentiated Services Field (DS		F., and D. Black, "Definition of
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		the Differentiated Services Field
	December 1998.		(DS Field) in the IPv4 and IPv6
			Headers", RFC 2474,
			December 1998.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and
	of Explicit Congestion Notification (ECN) to IP",		D. Black, "The Addition of
	RFC 3168, September 2001.		Explicit Congestion Notification
			(ECN) to IP", RFC 3168,
			September 2001.
	[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)		[RFC5559] Eardley, P., "Pre-Congestion
	Architecture", RFC 5559, June 2009.		Notification (PCN) Architecture",
			RFC 5559, June 2009.
	[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-		[RFC5670] Eardley, P., "Metering and
	Nodes", RFC 5670, November 2009.		Marking Behaviour of PCN-Nodes",
			RFC 5670, November 2009.
	[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion		[RFC6040] Briscoe, B., "Tunnelling of
	Notification", RFC 6040, November 2010.		Explicit Congestion
			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.,
	Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.		Karagiannis, G., Menth, M., and
	Taylor, "PCN Boundary Node Behaviour for the Controlled		T. Taylor, "PCN Boundary Node
	Load (CL) Mode of Operation",		Behaviour for the Controlled Load
	draft-ietf-pcn-cl-edge-behaviour-09 (work in progress),		(CL) Mode of Operation", draft-
	June 2011.		ietf-pcn-cl-edge-behaviour-09
			(work in progress), June 2011.
	[I-D.ietf-pcn-encoding-comparison]		[I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K.,
	Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,		Moncaster, T., Menth, M.,
	Eardley, P., and B. Briscoe, "Overview of Pre-Congestion		Eardley, P., and B. Briscoe,
	Notification Encoding",		"Overview of Pre-Congestion
	draft-ietf-pcn-encoding-comparison-06 (work in progress),		Notification Encoding", draft-
	June 2011.		ietf-pcn-encoding-comparison-06
			(work in progress), June 2011.
	[I-D.ietf-pcn-sm-edge-behaviour]		[I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G.,
	Charny, A., Karagiannis, G., Menth, M., and T. Taylor,		Menth, M., and T. Taylor, "PCN
	"PCN Boundary Node Behaviour for the Single Marking (SM)		Boundary Node Behaviour for the
	Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-06		Single Marking (SM) Mode of
	(work in progress), June 2011.		Operation", draft-ietf-pcn-sm-
			edge-behaviour-06 (work in
			progress), June 2011.
	[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,		[RFC2597] Heinanen, J., Baker, F., Weiss,
	"Assured Forwarding PHB Group", RFC 2597, June 1999.		W., and J. Wroclawski, "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., Courtney, W., Davari, S., Firoiu, V., and D.		J., Benson, K., Le Boudec, J.,
	Stiliadis, "An Expedited Forwarding PHB (Per-Hop		Courtney, W., Davari, S., Firoiu,
	Behavior)", RFC 3246, March 2002.		V., and D. Stiliadis, "An
			Expedited Forwarding PHB (Per-Hop
			Behavior)", RFC 3246, March 2002.
	[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit		[RFC3540] Spring, N., Wetherall, D., and D.
	Congestion Notification (ECN) Signaling with Nonces",		Ely, "Robust Explicit Congestion
	RFC 3540, June 2003.		Notification (ECN) Signaling with
			Nonces", RFC 3540, June 2003.
	[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration		[RFC4594] Babiarz, J., Chan, K., and F.
	Guidelines for DiffServ Service Classes", RFC 4594,		Baker, "Configuration Guidelines
	August 2006.		for DiffServ Service Classes",
			RFC 4594, August 2006.
	[RFC4774] Floyd, S., "Specifying Alternate Semantics for the		[RFC4774] Floyd, S., "Specifying Alternate
	Explicit Congestion Notification (ECN) Field", BCP 124,		Semantics for the Explicit
	RFC 4774, November 2006.		Congestion Notification (ECN)
			Field", BCP 124, RFC 4774,
			November 2006.
	[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of		[RFC5127] Chan, K., Babiarz, J., and F.
	DiffServ Service Classes", RFC 5127, February 2008.		Baker, "Aggregation of DiffServ
			Service Classes", RFC 5127,
			February 2008.
	[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion		[RFC5129] Davie, B., Briscoe, B., and J.
	Marking in MPLS", RFC 5129, January 2008.		Tay, "Explicit Congestion Marking
			in MPLS", RFC 5129, January 2008.
	[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching		[RFC5462] Andersson, L. and R. Asati,
	(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic		"Multiprotocol Label Switching
	Class" Field", RFC 5462, February 2009.		(MPLS) Label Stack Entry: "EXP"
			Field Renamed to "Traffic Class"
			Field", RFC 5462, February 2009.
	[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline		[RFC5696] Moncaster, T., Briscoe, B., and
	Encoding and Transport of Pre-Congestion Information",		M. Menth, "Baseline Encoding and
	RFC 5696, November 2009.		Transport of Pre-Congestion
			Information", RFC 5696,
			November 2009.
	[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated		[RFC5865] Baker, F., Polk, J., and M.
	Services Code Point (DSCP) for Capacity-Admitted Traffic",		Dolly, "A Differentiated Services
	RFC 5865, May 2010.		Code Point (DSCP) for Capacity-
			Admitted Traffic", 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.
	A single DSCP has not been defined for use with PCN for several		A single DSCP has not been defined for use with PCN for several
	reasons. Firstly, the PCN mechanism is applicable to a variety of		reasons. Firstly, the PCN mechanism is applicable to a variety of
	different traffic classes. Secondly, Standards Track DSCPs are in		different traffic classes. Secondly, Standards Track DSCPs are in
	increasingly short supply. Thirdly, PCN is not a scheduling		increasingly short supply. Thirdly, PCN is not a scheduling
	behaviour -- rather, it should be seen as being a marking behaviour		behaviour -- rather, it should be seen as being a marking behaviour
	skipping to change at page 18, line 46		skipping to change at page 19, line 21
	This appendix is informative, not normative.		This appendix is informative, not normative.
	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 re-marked 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, which associates a filterspec with a need for
	control (e.g. through RSVP or some equivalent message, e.g. from		admission control (e.g. through RSVP or some equivalent message,
	a SIP server to the ingress), and the PCN-ingress re-marks		e.g. from a SIP server to the ingress); the PCN-ingress-node re-
	traffic matching that filterspec to a PCN-compatible DSCP, as its		marks traffic matching that filterspec to a PCN-compatible DSCP.
	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 Real-Time Interactive,
	Broadcast TV when used for video on demand, and Multimedia		Broadcast Video when used for video on demand, and multimedia
	Conferencing [RFC4594][RFC5865] (see Appendix A).		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. The tunnelling action should be applied wholly outside		PCN domain. The tunnelling action should be applied wholly outside
	skipping to change at page 19, line 43		skipping to change at page 20, line 16
	. ,--------. ,--------. .		. ,--------. ,--------. .
	. _| 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 tunnelling and PCN actions
	There are three 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:
	a) Does not require admission control:		a) Traffic that does not require admission control:
			For example, traffic that does not match flow signaling being used
			for admission control. In this case the e2e ECN traffic is not
			treated as PCN-traffic. There are two possible scenarios:
	* Does not carry a PCN-compatible DSCP: No action required.		* Arriving traffic does not carry a PCN-compatible DSCP: no
			action required.
	* Arrives carrying a DSCP that uses the same codepoint as a PCN-		* Arriving traffic carries a DSCP that clashes with a PCN-
	compatible DSCP: There are two options:		compatible DSCP. There are two options:
	1. The ingress maps the DSCP to a local DSCP with the same		1. The ingress maps the DSCP to a local DSCP with the same
	scheduling PHB as the original DSCP, and the egress re-maps		scheduling PHB as the original DSCP, and the egress re-maps
	it to the original PCN-compatible DSCP.		it to the original PCN-compatible DSCP.
	2. The ingress tunnels the traffic, setting not-PCN in the		2. The ingress tunnels the traffic, setting not-PCN in the
	outer header; note that this turns off ECN for this traffic		outer header; note that this turns off ECN for this traffic
	within the PCN domain.		within the PCN domain.
	The first option is recommended unless the operator is short of		The first option is recommended unless the operator is short of
	local DSCPs.		local DSCPs.
	b) Requires Admission-control: There are two options.		b) Traffic that requires admission-control:
			In this case the e2e ECN traffic is treated as PCN-traffic across
			the PCN domain. There are two options.
	* The PCN-ingress places this traffic in a tunnel with a PCN-		* The PCN-ingress-node places this traffic in a tunnel with a
	compatible DSCP in the outer header. The PCN-egress zeroes the		PCN-compatible DSCP in the outer header. The PCN-egress zeroes
	ECN-field before decapsulation.		the ECN-field before decapsulation.
	* The PCN-ingress drops CE-marked packets and the PCN-egress		* The PCN-ingress-node drops CE-marked packets and otherwise sets
	zeros the ECN field of all PCN packets.		the ECN-field to NM and sets the DCSP to a PCN-compatible DSCP.
			The PCN-egress zeroes the ECN field of all PCN packets; note
			that this turns off e2e ECN.
	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.
	c) Requires Admission Control and asks to see PCN marks: NOTE this		c) Traffic that requires admission control where the endpoints ask to
	scheme is currently only a tentative idea.		see PCN marks:
			Note that this scheme is currently only a tentative idea.
	For real-time data generated by an adaptive codec, schemes have		For real-time data generated by an adaptive codec, schemes have
	been suggested where PCN marks may be leaked out of the PCN-domain		been suggested where PCN marks may be leaked out of the PCN-domain
	so that end hosts can drop to a lower data rate, thus deferring		so that end hosts can drop to a lower data rate, thus deferring
	the need for admission control. Currently such schemes require		the need for admission control. Currently such schemes require
	further study and the following is for guidance only.		further study and the following is for guidance only.
	The PCN-ingress needs to tunnel the traffic as in Figure 2, taking		The PCN-ingress-node needs to tunnel the traffic as in Figure 2,
	care to comply with [RFC6040]. In this case the PCN-egress should		taking care to comply with [RFC6040]. In this case the PCN-egress
	not zero the ECN field, and then the [RFC6040] tunnel egress will		does not zero the ECN field contrary to the recommendation in
	preserve any PCN-marking. Note that a PCN interior node may turn		Section 5.3, so that the [RFC6040] tunnel egress will preserve any
	ECT(0) into ECT(1), which would not be compatible with the		PCN-marking. Note that a PCN interior node may change the ECN-
	(currently experimental) ECN nonce [RFC3540].		field from 10 to 01 (NM to ThM), which would be interpreted by the
			e2e ECN as a change from ECT(0) into ECT(1). This would not be
			compatible with the (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 the 64 codepoints of the DS		freedom to define a site-local mapping of the 64 codepoints of the DS
	field onto 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. [RFC5129] was written while PCN
	PCN specifications were in early draft stages. The following		specifications were in early draft stages. The following provides a
	provides a clearer example of a mapping between PCN in IP and in MPLS		clearer example of a mapping between PCN in IP and in MPLS using the
	using the PCN terminology and concepts that have since been		PCN terminology and concepts that have since been specified.
	specified.
	To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n')		To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n')
	needs codepoints to be provided in the TC field for all the PCN-marks		needs codepoints to be provided in the TC field for all the PCN-marks
	used. That means, when for instance only excess-traffic-marking is		used. That means, when for instance only excess-traffic-marking is
	used for PCN purposes, the operator needs to define a site-local		used for PCN purposes, the operator needs to define a site-local
	mapping to two codepoints in the MPLS TC field for 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 NM
	o DSCP n and CE		o DSCP n and ETM
	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 NM
	o DSCP n and ECT(1)		o DSCP n and ThM
	o DSCP n and CE		o DSCP n and ETM
	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-PCN
	Clearly, given so few TC codepoints are available, it may be		The above sets of codepoints are required for every PCN-compatible
			DSCP. Clearly, given so few TC codepoints are available, it may be
	necessary to compromise by merging together some capabilities.		necessary to compromise by merging together some capabilities.
	Appendix D. Rationale for Discrepancy Between the Schemes using One		Appendix D. Rationale for Difference Between the Schemes using One PCN-
	PCN-Marking		Marking
	Readers may notice an apparent discrepancy between the two behaviours		Readers may notice a difference between the two behaviours in
	in Section 5.2.3.1 and Section 5.2.3.2. With only excess-traffic		Section 5.2.3.1 and Section 5.2.3.2. With only excess-traffic
	marking enabled, an unexpected ThM packet can be re-marked to ETM.		marking enabled, an unexpected ThM packet can be re-marked to ETM.
	However, with only threshold marking, an unexpected ETM packet cannot		However, with only Threshold-marking, an unexpected ETM packet cannot
	be re-marked to ThM.		be re-marked to ThM.
	This apparent inconsistency is deliberate, for two reasons:		This apparent inconsistency is deliberate. The behaviour with only
			threshold marking keeps to the rule of Section 5.2.1 that ETM is more
	o If only one type of marking function is meant to be used		severe and must never be changed to ThM even though ETM is not a
	throughout the PCN-domain but the other type unexpectedly appears		valid marking in this case. Otherwise implementations would have to
	on some packets, it is safest to assume that some link is trying		allow operators to configure an exception to this rule, which would
	to signal that it is pre-congested, but that it is somehow using		not be safe practice and would require different code in the data
	the wrong signal. This only needs to be corrected if the		plane compared to the common behaviour.
	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
	Phone: +44 1473 645196		Phone: +44 1473 645196
	Email: bob.briscoe@bt.com		EMail: bob.briscoe@bt.com
	URI: http://bobbriscoe.net/		URI: http://bobbriscoe.net/
	Toby Moncaster		Toby Moncaster
	Moncaster Internet Consulting		Moncaster Internet Consulting
	Dukes		Dukes
	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
	Tuebingen 72076		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. 89 change blocks.
	206 lines changed or deleted		238 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/