draft-ietf-pcn-3-in-1-encoding-05.txt		draft-ietf-pcn-3-in-1-encoding-06.txt
	Congestion and Pre-Congestion B. Briscoe		Congestion and Pre-Congestion B. Briscoe
	Notification BT		Notification BT
	Internet-Draft T. Moncaster		Internet-Draft T. Moncaster
	Intended status: Standards Track Moncaster Internet Consulting		Obsoletes: 5696 (if approved) Moncaster Internet Consulting
	Expires: November 22, 2011 M. Menth		Intended status: Standards Track M. Menth
	University of Tuebingen		Expires: January 11, 2012 University of Tuebingen
	May 21, 2011		July 10, 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-05		draft-ietf-pcn-3-in-1-encoding-06
	Abstract		Abstract
	The objective of Pre-Congestion Notification (PCN) is to protect the		The objective of Pre-Congestion Notification (PCN) is to protect the
	quality of service (QoS) of inelastic flows within a Diffserv domain.		quality of service (QoS) of inelastic flows within a Diffserv domain.
	On every link in the PCN domain, the overall rate of the PCN-traffic		The overall rate of the PCN-traffic is metered on every link in the
	is metered, and PCN-packets are appropriately marked when certain		PCN domain, and PCN-packets are appropriately marked when certain
	configured rates are exceeded. Egress nodes provide decision points		configured rates are exceeded. Egress nodes pass information about
	with information about the PCN-marks of PCN-packets which allows them		these PCN-marks to decision points which then decide whether to admit
	to take decisions about whether to admit or block a new flow request,		or block new flow requests or to terminate some already-admitted
	and to terminate some already admitted flows during serious pre-		flows during serious pre-congestion.
	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 builds on the baseline		codepoints within a PCN-domain. This encoding provides for up to
	encoding of RFC5696 and provides for three different PCN marking		three different PCN marking states using a single DSCP: not-marked
	states using a single DSCP: not-marked (NM), threshold-marked (ThM)		(NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence,
	and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN		it is called the 3-in-1 PCN encoding. This document obsoletes
	encoding.		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 November 22, 2011.		This Internet-Draft will expire on January 11, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Changes in This Version (to be removed by RFC Editor) . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5		1.2. Changes in This Version (to be removed by RFC Editor) . . 5
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7
	3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5		2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 7
	3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6		3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 8
	3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7		4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 9
	4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7		4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 9
	5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN		4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 9
	Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 10
	6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8		5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN
	6.1. Backward Compatibility with Pre-existing PCN		Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Implementations . . . . . . . . . . . . . . . . . . . . . 9		5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 10
	6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9		5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11
	6.2.1. Use of Both Excess-Traffic-Marking and		5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11
	Threshold-Marking . . . . . . . . . . . . . . . . . . 10		5.2.2. Behaviour of PCN-interior Nodes Using Two
	6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 10		PCN-markings . . . . . . . . . . . . . . . . . . . . . 11
	6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10		5.2.3. Behaviour of PCN-interior Nodes Using One
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		PCN-marking . . . . . . . . . . . . . . . . . . . . . 11
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5.3. Behaviour of PCN-egress Nodes . . . . . . . . . . . . . . 12
	9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11		6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13
	11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11		6.2. Backward Compatibility with the Baseline Encoding . . . . 13
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 11		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	12.2. Informative References . . . . . . . . . . . . . . . . . . 12		9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Co-existence of ECN and PCN (informative) . . . . . . 13		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
			12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
			12.2. Informative References . . . . . . . . . . . . . . . . . . 15
			Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 16
			Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 18
			Appendix C. Example Mapping between Encoding of PCN-Marks in
			IP and in MPLS Shim Headers . . . . . . . . . . . . . 20
			Appendix D. Rationale for different behaviours for single
			marking schemes . . . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	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,
	and PCN-packets are appropriately marked when certain configured		and PCN-packets are appropriately marked when certain configured
	rates are exceeded. These configured rates are below the rate of the		rates are exceeded. These configured rates are below the rate of the
	link thus providing notification to boundary nodes about overloads		link thus providing notification to boundary nodes about overloads
	before any real congestion occurs (hence "pre-congestion		before any real congestion occurs (hence "pre-congestion
	notification").		notification").
	[RFC5670] provides for two metering and marking functions that are		[RFC5670] provides for two metering and marking functions that are
	configured with reference rates. Threshold-marking marks all PCN		generally configured with different reference rates. Threshold-
	packets once their traffic rate on a link exceeds the configured		marking marks all PCN packets once their traffic rate on a link
	reference rate (PCN-threshold-rate). Excess-traffic-marking marks		exceeds the configured reference rate (PCN-threshold-rate). Excess-
	only those PCN packets that exceed the configured reference rate		traffic-marking marks only those PCN packets that exceed the
	(PCN-excess-rate). The PCN-excess-rate is typically larger than the		configured reference rate (PCN-excess-rate). The PCN-excess-rate is
	PCN-threshold-rate [RFC5559]. Egress nodes monitor the PCN-marks of		typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes
	received PCN-packets and provide information about the PCN-marks to		monitor the PCN-marks of received PCN-packets and pass information
	decision points which take decisions about flow admission and		about these PCN-marks to decision points which then decide whether to
	termination on this basis [I-D.ietf-pcn-cl-edge-behaviour],		admit new flows or terminate existing flows
	[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] describes how two PCN		The baseline encoding defined in [RFC5696] described how two PCN
	marking states (Not-marked and PCN-Marked) can be encoded using a		marking states (Not-marked and PCN-Marked) could be encoded into the
	single Diffserv codepoint. It also provides an experimental		IP header using a single Diffserv codepoint. It also provided an
	codepoint (EXP), along with guidelines for use of that codepoint. To		experimental codepoint (EXP), along with guidelines for the use of
	support the application of two different marking algorithms in a PCN-		that codepoint. Two PCN marking states are sufficient for the Single
	domain, for example as required in [I-D.ietf-pcn-cl-edge-behaviour],		Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However,
	three PCN marking states are needed. This document describes an		PCN-domains utilising the controlled load edge behaviour
	extension to the baseline encoding that uses the EXP codepoint to		[I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states.
	provide a third PCN marking state in the IP header, still using a		This document extends the baseline encoding by redefining the EXP
	single Diffserv codepoint. This encoding scheme is called "3-in-1		codepoint to provide a third PCN marking state in the IP header,
	PCN encoding".		still using a single Diffserv codepoint. This encoding scheme is
			therefore called the "3-in-1 PCN encoding". It obsoletes the
			baseline encoding [RFC5696], which provides only a sub-set of the
			same capabilities.
	This document only concerns the PCN wire protocol encoding for all IP		The full version of this encoding requires any tunnel endpoint within
			the PCN-domain to support the normal tunnelling rules defined in
			[RFC6040]. There is one limited exception to this constraint where
			the PCN-domain only uses the excess-traffic-marking behaviour and
			where the threshold-marking behaviour is deactivated. This is
			discussed in Section 5.2.3.1.
			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
	recommendations concerning algorithms for congestion marking or		recommendations concerning algorithms for congestion marking or
	congestion response. Other documents define the PCN wire protocol		congestion response. Other documents will define the PCN wire
	for other header types. For example, the MPLS encoding is defined in		protocol for other header types. Appendix C discusses a possible
	[RFC5129] and Appendix A of that document provides an informative		mapping between IP and MPLS.
	example for a mapping between the encodings in IP and in MPLS.
	1.1. Changes in This Version (to be removed by RFC Editor)		1.1. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			1.2. Changes in This Version (to be removed by RFC Editor)
			From draft-ietf-pcn-3-in-1-encoding-05 to -06:
			* Draft re-written to obsolete baseline encoding [RFC5696].
			* New section defining utilising this encoding for single
			marking. Added an appendix explaining an apparent
			inconsistency relating to single marking.
			* Moved (and updated) informative appendixes from [RFC5696] to
			this document. Original Appendix C was omitted as it is now
			redundant.
			* 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
	discussions.		discussions.
	* Added Appendix A discussing ECN handling in the PCN-domain.		* Added Appendix B discussing ECN handling in the PCN-domain.
	* Clarified that this document modifies [RFC5696].		* Clarified that this document modifies [RFC5696].
	* .......
	From draft-ietf-pcn-3-in-1-encoding-03 to -04:		From draft-ietf-pcn-3-in-1-encoding-03 to -04:
	* Updated document to reflect RFC6040.		* Updated document to reflect RFC6040.
	* Re-wrote introduction.		* Re-wrote introduction.
	* Re-wrote section on applicability.		* Re-wrote section on applicability.
	* Re-wrote section on choosing encoding scheme.		* Re-wrote section on choosing encoding scheme.
	skipping to change at page 5, line 26		skipping to change at page 7, line 5
	* Introduction altered to include new template description of		* Introduction altered to include new template description of
	PCN.		PCN.
	* References updated.		* References updated.
	* Terminology brought into line with [RFC5670].		* Terminology brought into line with [RFC5670].
	* Minor corrections.		* Minor corrections.
	2. Requirements Language		2. Definitions and Abbreviations
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	2.1. Terminology		2.1. Terminology
	General PCN-related terminology is defined in the PCN architecture		The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node,
	[RFC5559], and terminology specific to packet encoding is defined in		PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN-
	the PCN baseline encoding [RFC5696]. Additional terminology is		marking are used as defined in [RFC5559]. The following additional
	defined below.		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.
	3. Requirements for and Applicability of 3-in-1 PCN Encoding		PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating
			packets for which the ECN field is used to carry PCN-markings
			rather than [RFC3168] markings (see Appendix A).
	3.1. PCN Requirements		Threshold-marked codepoint: a codepoint that indicates packets that
			have been marked at a PCN-interior-node as a result of an
			indication from the threshold-metering function [RFC5670].
			Abbreviated to ThM.
			Excess-traffic-marked codepoint: a codepoint that indicates packets
			that have been marked at a PCN-interior-node as a result of an
			indication from the excess-traffic-metering function [RFC5670].
			Abbreviated to ETM.
			Not-marked codepoint: a codepoint that indicates PCN-packets but
			that are not PCN-marked. Abbreviated to NM.
			not-PCN codepoint: a codepoint that indicates packets that are not
			PCN-packets.
			2.2. List of Abbreviations
			The following abbreviations are used in this document:
			o AF = Assured Forwarding [RFC2597]
			o CE = Congestion Experienced [RFC3168]
			o CS = Class Selector [RFC2474]
			o DSCP = Diffserv codepoint
			o ECN = Explicit Congestion Notification [RFC3168]
			o ECT = ECN Capable Transport [RFC3168]
			o EF = Expedited Forwarding [RFC3246]
			o ETM = Excess-traffic-marked
			o EXP = Experimental
			o IP = Internet protocol
			o NM = Not-marked
			o PCN = Pre-Congestion Notification
			o ThM = Threshold-marked
			3. Definition of 3-in-1 PCN Encoding
			The 3-in-1 PCN encoding scheme allows for two or three PCN-marking
			states to be encoded within the IP header. The full encoding is
			shown in Figure 1.
			+--------+----------------------------------------------------+
			| | Codepoint in ECN field of IP header |
			| DSCP | <RFC3168 codepoint name> |
			| +--------------+-------------+-------------+---------+
			| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
			+--------+--------------+-------------+-------------+---------+
			| DSCP n | Not-PCN | NM | ThM | ETM |
			+--------+--------------+-------------+-------------+---------+
			Figure 1: 3-in-1 PCN Encoding
			As mentioned above, the 3-in-1 PCN encoding is an extension of the
			baseline encoding [RFC5696]. Like the baseline encoding it uses a
			combination of a PCN-compatible DSCP (DSCP n in Figure 1) and the ECN
			field for the encoding of PCN-marks. Appendix A discusses the choice
			of suitable DSCPs. The PCN-marks have the following meaning.
			Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not
			subject to PCN metering and marking.
			NM: Not-marked. Indicates a PCN-packet that has not yet been marked
			by any PCN marker.
			ThM: Threshold-marked. Indicates a PCN-packet that has been marked
			by a threshold-marker [RFC5670].
			ETM: Excess-traffic-marked. Indicates a PCN-packet that has been
			marked by an excess-traffic-marker [RFC5670].
			4. Requirements for and Applicability of 3-in-1 PCN Encoding
			4.1. PCN Requirements
	In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes		In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes
	control packets entering a PCN-domain. Packets belonging to PCN-		control packets entering a PCN-domain. Packets belonging to PCN-
	controlled flows are subject to PCN-metering and -marking, and PCN-		controlled flows are subject to PCN-metering and -marking, and PCN-
	ingress-nodes mark them as Not-marked (PCN-colouring). Any node in		ingress-nodes mark them as Not-marked (PCN-colouring). Any node in
	the PCN-domain may perform PCN-metering and -marking and mark PCN-		the PCN-domain may perform PCN-metering and -marking and mark PCN-
	packets if needed. There are two different metering and marking		packets if needed. There are two different metering and marking
	schemes: threshold-marking and excess-traffic-marking [RFC5670].		behaviours: threshold-marking and excess-traffic-marking [RFC5670].
	Some edge behaviors require only a single marking scheme		Some edge behaviors require only a single marking behaviour
	[I-D.ietf-pcn-sm-edge-behaviour], others require both		[I-D.ietf-pcn-sm-edge-behaviour], others require both
	[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 scheme 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 are not PCN-capable (the not-PCN codepoint).		packets that do not use PCN (the not-PCN codepoint).
	In all current PCN edge behaviors that use two marking schemes		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.
	3.2. Requirements Imposed by Baseline Encoding		4.2. Requirements Imposed by Tunnelling
	The baseline encoding scheme [RFC5696] was defined so that it could		[RFC6040] defines rules for the encapsulation and decapsulation of
	be extended to accommodate an additional marking state. It provides		ECN markings within IP-in-IP tunnels. The publication of RFC6040
	rules to embed the encoding of two PCN states in the IP header.		removed the tunnelling constraints that existed when the baseline
	Figure 1 shows the structure of the former type-of-service field. It		encoding [RFC5696] was written (see section 3.3.2 of
	contains the 6-bit Differentiated Services (DS) field that holds the		[I-D.ietf-pcn-encoding-comparison]).
	DS codepoint (DSCP) [RFC2474] and the 2-bit ECN field [RFC3168].
	0 1 2 3 4 5 6 7		Nonetheless, there is still a problem if there are any legacy (pre-
	+-----+-----+-----+-----+-----+-----+-----+-----+		RFC6040) decapsulating tunnel endpoints within a PCN domain. If a
	| DS FIELD | ECN FIELD |		PCN node Threshold-marks the outer header of a tunnelled packet with
	+-----+-----+-----+-----+-----+-----+-----+-----+		a Not-marked codepoint on the inner header, the legacy decapsulator
			will revert the Threshold-marking to Not-marked. The rules on
			applicability in Section 4.3 below are designed to avoid this
			problem.
	Figure 1: Structure of the former type-of-service field in IP		4.3. Applicability of 3-in-1 PCN Encoding
	Baseline encoding defines that the DSCP must be set to a PCN-		The 3-in-1 encoding is applicable in situations where two marking
	compatible DSCP n and the ECN-field [RFC3168] indicates the specific		behaviours are being used in the PCN-domain. The 3-in-1 encoding can
	PCN-mark. Baseline encoding offers four possible encoding states		also be used with only one marking behaviour, in which case one of
	within a single DSCP with the following restrictions.		the codepoints MUST NOT be used throughout the PCN-domain (see
			Section 5.2.3).
	o Codepoint `00' (not-ECT) is used to indicate non-PCN traffic as		For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP
	"not-PCN". This allows both PCN and non-PCN traffic to use the		and IPsec) within the PCN-domain MUST comply with the ECN
	same DSCP.		encapsulation and decapsulation rules set out in [RFC6040] (see
			Section 4.2). There is one exception to this rule outlined next.
	o Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN		It may not be possible to upgrade every pre-RFC6040 tunnel endpoint
	traffic.		within a PCN-domain. In such cirsumstances a limited version of the
			3-in-1 encoding can still be used but only under the following
			stringent condition. If any pre-RFC6040 tunnel endpoint exists
			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
			PCN-interior nodes in this case is defined in Section 5.2.3.1. In
			all other situations where legacy tunnel endpoints might be present
			within the PCN domain, the 3-in-1 encoding is not applicable.
	o Codepoint `11' (CE) is used to indicate the most severe PCN-mark.		5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding
	o Codepoint `01' (ECT(1)) is available for experimental use and may		As mentioned in Section 4.3 above, all PCN-nodes MUST comply with
	be re-used by other PCN encodings such as the presently defined		[RFC6040].
	3-in-1 PCN encoding (subject to the rules defined in [RFC5696]).
	[RFC6040] defines rules for the encapsulation and decapsulation of		5.1. PCN-ingress Node Behaviour
	ECN markings within IP-in-IP tunnels. This RFC removes some of the
	constraints that existed when [RFC5696] was written. Happily the
	rules for use of the EXP codepoint are fully compatible with
	[RFC6040]. In particular, the relative severity of each marking is
	the same: CE (PM) is more severe than ECT(1) (EXP) is more severe
	than ECT(0) (NM). This is discussed in more detail in both the
	baseline encoding document [RFC5696] and in
	[I-D.ietf-pcn-encoding-comparison].
	3.3. Applicability of 3-in-1 PCN Encoding		PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint.
			To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are
			already defined for use with admission-controlled traffic.
			Appendix A gives guidance to implementors on suitable DSCPs.
			Guidelines for mixing traffic types within a PCN-domain are given in
			[RFC5670].
	The 3-in-1 encoding is applicable in situations where two marking		If a packet arrives at the PCN-ingress-node that shares a PCN-
	schemes are being used in the PCN-domain. In some circumstances it		compatible DSCP and is not a PCN-packet, the PCN-ingress MUST mark it
	can also be used in PCN-domains with only a single marking scheme in		as not-PCN.
	use. Further guidance on choosing an encoding scheme can be found in
	Section 6.2. All nodes within the PCN-domain MUST be fully compliant
	with the ECN encapsulation rules set out in [RFC6040]. As such the
	encoding is not applicable in situations where legacy tunnels might
	exist.
	4. Definition of 3-in-1 PCN Encoding		If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress MUST
			change the PCN codepoint to Not-marked.
	The 3-in-1 PCN encoding scheme is an extension of the baseline		If a PCN-packet arrives at the PCN-ingress-node with its ECN field
	encoding scheme defined in [RFC5696]. The PCN requirements and the		already set to a value other than not-ECT, then appropriate action
	extension rules for baseline encoding presented in the previous		MUST be taken to meet the requirements of [RFC4774]. The simplest
	section determine how PCN encoding states are carried in the IP		appropriate action is to just drop such packets. However, this is a
	headers. This is shown in Figure 2.		drastic action that an operator may feel is undesirable. Appendix B
			provides more information and summarises other alternative actions
			that might be taken.
	+--------+----------------------------------------------------+		5.2. PCN-interior Node Behaviour
	| | Codepoint in ECN field of IP header |
	| DSCP | <RFC3168 codepoint name> |
	| +--------------+-------------+-------------+---------+
	| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
	+--------+--------------+-------------+-------------+---------+
	| DSCP n | Not-PCN | NM | ThM | ETM |
	+--------+--------------+-------------+-------------+---------+
	Figure 2: 3-in-1 PCN Encoding
	Like baseline encoding, 3-in-1 PCN encoding also uses a PCN		5.2.1. Behaviour Common to all PCN-interior Nodes
	compatible DSCP n and the ECN field for the encoding of PCN-marks.
	The PCN-marks have the following meaning.
	Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not		Interior nodes MUST NOT change not-PCN to any other codepoint.
	subject to PCN metering and marking.
	NM: Not-marked. Indicates a PCN-packet that has not yet been marked		Interior nodes MUST NOT change NM to not-PCN.
	by any PCN marker.
	ThM: Threshold-marked. Indicates a PCN-packet that has been marked		Interior nodes MUST NOT change ThM to NM or not-PCN.
	by a threshold-marker [RFC5670].
	ETM: Excess-traffic-marked. Indicates a PCN-packet that has been		Interior nodes MUST NOT change ETM to any other codepoint.
	marked by an excess-traffic-marker [RFC5670].
	5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding		5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings
	To be compliant with the 3-in-1 PCN Encoding, an PCN interior node		If the threshold-meter function indicates a need to mark the packet,
	behaves as follows:		the PCN-interior node MUST change NM to ThM.
	o It MUST change NM to ThM if the threshold-meter function indicates		If the excess-traffic-meter function indicates a need to mark the
	a need to mark the packet;		packet:
	o It MUST change NM or ThM to ETM if the excess-traffic-meter		o the PCN-interior node MUST change NM to ETM;
	function indicates a need to mark the packet;
	o It MUST NOT change not-PCN to NM, ThM, or ETM;		o the PCN-interior node MUST change ThM to ETM.
	o It MUST NOT change a NM, ThM, or ETM to not-PCN;		If both the threshold meter and the excess-traffic meter indicate the
			need to mark a packet, the excess traffic marking rules MUST take
			priority.
	o It MUST NOT change ThM to NM;		5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking
	o It MUST NOT change ETM to ThM or to NM;		Some PCN edge behaviours require only one PCN-marking within the PCN-
			domain. The Single Marking edge behaviour
			[I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark
			packets using the excess-traffic-meter function [RFC5670]. It is
			possible that future schemes may require only the threshold-meter
			function. Observant readers may spot an apparent inconsistency
			between the two following cases. Appendix D explains the rationale
			behind this inconsistency.
	In other words, a PCN interior node MUST NOT mark PCN-packets into		5.2.3.1. Marking using only the Excess-traffic-meter Function
	non-PCN packets and vice-versa, and it may increase the severity of
	the PCN-mark of a PCN-packet, but it MUST NOT decrease it.
	6. Backward Compatibility		The threshold-traffic-meter function SHOULD be disabled and MUST NOT
			trigger any packet marking.
	Discussion of backward compatibility between PCN encoding schemes and		The PCN-interior node SHOULD raise a management alarm if it receives
	previous uses of the ECN field is given in Section 6 of [RFC5696].		a ThM packet, but the frequency of such alarms SHOULD be limited.
	6.1. Backward Compatibility with Pre-existing PCN Implementations		If the excess-traffic-meter function indicates a need to mark the
			packet:
	This encoding complies with the rules for extending the baseline PCN		o the PCN-interior node MUST change NM to ETM;
	encoding schemes in Section 5 of [RFC5696].
	The term "compatibility" is meant in the following sense. It is		o the PCN-interior node MUST change ThM to ETM. It SHOULD also
	possible to operate nodes with baseline encoding [RFC5696] and 3-in-1		raise an alarm as above.
	encoding in the same PCN domain. The nodes with baseline encoding
	MUST perform excess-traffic-marking because the 11 codepoint of
	3-in-1 encoding also means excess-traffic-marked. PCN-boundary-nodes
	of such domains are required to interpret the full 3-in-1 encoding
	and not just baseline encoding, otherwise they cannot interpret the
	01 codepoint.
	Using nodes that perform only excess-traffic-marking may make sense		5.2.3.2. Marking using only the Threshold-meter Function
	in networks using the CL edge behavior
	[I-D.ietf-pcn-cl-edge-behaviour]. Such nodes are able to notify the
	egress only about severe pre-congestion when traffic needs to be
	terminated. This seems reasonable for locations that are not
	expected to see any pre-congestion, but excess-traffic-marking gives
	them a means to terminate traffic if unexpected overload occurs.
	6.2. Recommendations for the Use of PCN Encoding Schemes		The excess-traffic-meter function SHOULD be disabled and MUST NOT
			trigger any packet marking.
	NOTE: This sub-section is informative not normative.		The PCN-interior node SHOULD raise a management alarm if it receives
			an ETM packet, but the frequency of such alarms SHOULD be limited.
	When deciding which PCN encoding is suitable an operator needs to		If the threshold-meter function indicates a need to mark the packet:
	take account of how many PCN states need to be encoded. The
	following table gives guidelines on which encoding to use with either
	threshold-marking, excess-traffic marking or both.
	+------------------------+--------------------------------+		o the PCN-interior node MUST change NM to ThM;
	| Marking schemes in use | Recommended encoding scheme |
	+------------------------+--------------------------------+
	| Only threshold-marking | Baseline encoding [RFC5696] |
	+------------------------+--------------------------------+
	| Only excess-traffic- | Baseline encoding [RFC5696] |
	| marking | or 3-in-1 PCN encoding |
	+------------------------+--------------------------------+
	| Threshold-marking and | 3-in-1 PCN encoding |
	| excess-traffic-marking | |
	+------------------------+--------------------------------+
	Figure 3: Guidelines for choosing PCN encoding schemes		o the PCN-interior node MUST NOT change ETM to any other codepoint.
			It SHOULD raise an alarm as above.
	6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Marking		5.3. Behaviour of PCN-egress Nodes
	If both excess-traffic-marking and threshold-marking are enabled in a		A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all
	PCN-domain, 3-in-1 encoding should be used as described in this		packets it forwards out of the PCN-domain.
	document.
	6.2.2. Unique Use of Excess-Traffic-Marking		The only exception to this is if the PCN-egress-node is certain that
			revealing other codepoints outside the PCN-domain won't contravene
			the guidance given in [RFC4774]. For instance, if the PCN-ingress-
			node has explicitly informed the PCN-egress-node that this flow is
			ECN-capable, then it might be safe to expose other codepoints.
			Appendix B gives details of how such schemes might work, but such
			schemes are currently experimental.
	If only excess-traffic-marking is enabled in a PCN-domain, baseline		If the PCN-domain is configured to use only excess-traffic marking,
	encoding or 3-in-1 encoding may be used. They lead to the same		the PCN-egress node MUST treat ThM as ETM and if only threshold-
	encoding because PCN-boundary nodes will interpret baseline "PCN-		marking is used it should treat ETM as ThM. However it SHOULD raise
	marked (PM)" as "excess-traffic-marked (ETM)".		a management alarm in either instance since this means there is some
			misconfiguration in the PCN-domain.
	6.2.3. Unique Use of Threshold-Marking		6. Backward Compatibility
	No scheme is currently proposed that solely uses threshold-marking.		6.1. Backward Compatibility with ECN
	If such a scheme is proposed, the choice of encoding scheme will
	depend on whether nodes are compliant with [RFC6040] or not. Where		BCP 124 [RFC4774] gives guidelines for specifying alternative
	it is certain that all nodes in the PCN-domain are compliant then		semantics for the ECN field. It sets out a number of factors to be
	either 3-in-1 encoding or baseline encoding are suitable. If legacy		taken into consideration. It also suggests various techniques to
	tunnel decapsulators exist within the PCN-domain then baseline		allow the co-existence of default ECN and alternative ECN semantics.
	encoding SHOULD be used.		The encoding specified in this document uses one of those techniques;
			it defines PCN-compatible Diffserv codepoints as no longer supporting
			the default ECN semantics. As such, this document is compatible with
			BCP 124.
			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
			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
			Appendix B recommends various approaches over others, it is merely
			informative and all such schemes are beyond the normative scope of
			this document.
			In any PCN deployment, traffic can only enter the PCN-domain through
			PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-
			nodes ensure that any packets entering the PCN-domain have the ECN
			field in their outermost IP header set to the appropriate PCN
			codepoint. PCN-egress-nodes then guarantee that the ECN field of any
			packet leaving the PCN-domain has appropriate ECN semantics. This
			prevents unintended leakage of ECN marks into or out of the PCN-
			domain, and thus reduces backward-compatibility issues.
			6.2. Backward Compatibility with the Baseline Encoding
			A PCN node implemented to use the obsoleted baseline encoding could
			conceivably have been configured so that the Threshold-meter function
			marked what is now defined as the ETM codepoint in the 3-in-1
			encoding. However, thre is no known deployment of such an
			implementation and no reason to believe that such an implementation
			would ever have been built. Therefore, it seems safe to ignore this
			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.
	8. Security Considerations		8. Security Considerations
	The security concerns relating to this extended PCN encoding are the		PCN-marking only carries a meaning within the confines of a PCN-
	same as those in [RFC5696]. In summary, PCN-boundary nodes are		domain. This encoding document is intended to stand independently of
	responsible for ensuring inappropriate PCN markings do not leak into		the architecture used to determine how specific packets are
	or out of a PCN domain, and the current phase of the PCN architecture		authorised to be PCN-marked, which will be described in separate
	assumes that all the nodes of a PCN-domain are entirely under the		documents on PCN-boundary-node behaviour.
	control of a single operator, or a set of operators who trust each
	other.
	Given the only difference between the baseline encoding and the		This document assumes the PCN-domain to be entirely under the control
	present 3-in-1 encoding is the use of the 01 codepoint, no new		of a single operator, or a set of operators who trust each other.
	security issues are raised, as this codepoint was already available		However, future extensions to PCN might include inter-domain versions
	for experimental use in the baseline encoding.		where trust cannot be assumed between domains. If such schemes are
			proposed, they must ensure that they can operate securely despite the
			lack of trust. However, such considerations are beyond the scope of
			this document.
			One potential security concern is the injection of spurious PCN-marks
			into the PCN-domain. However, these can only enter the domain if a
			PCN-ingress-node is misconfigured. The precise impact of any such
			misconfiguration will depend on which of the proposed PCN-boundary-
			node behaviours is used, but in general spurious marks will lead to
			admitting fewer flows into the domain or potentially terminating too
			many flows. In either case, good management should be able to
			quickly spot the problem since the overall utilisation of the domain
			will rapidly fall.
	9. Conclusions		9. Conclusions
	The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field		The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field
	to encode PCN-marks. One codepoint allows non-PCN traffic to be		to encode PCN-marks. One codepoint allows non-PCN traffic to be
	carried with the same PCN-compatible DSCP and three other codepoints		carried with the same PCN-compatible DSCP and three other codepoints
	support three PCN marking states with different levels of severity.		support three PCN marking states with different levels of severity.
	The use of this PCN encoding scheme presupposes that any tunnels in		In general, the use of this PCN encoding scheme presupposes that any
	the PCN region have been updated to comply with [RFC6040].		tunnel endpoints within the PCN-domain comply with [RFC6040].
	10. Acknowledgements		10. Acknowledgements
	Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Georgios		Many thanks to Phil Eardley for providing extensive feedback,
	Karaginannis for reviewing this document.		critcism and advice. Thanks also to Teco Boot, Kwok Ho Chan,
			Ruediger Geib, Georgios Karaginannis and everyone else who has
			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
	skipping to change at page 11, line 42		skipping to change at page 15, line 28
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	December 1998.		December 1998.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, September 2001.		RFC 3168, September 2001.
	[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
	Congestion Notification (ECN) Signaling with Nonces",
	RFC 3540, June 2003.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.
	[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
	Guidelines for DiffServ Service Classes", RFC 4594,
	August 2006.
	[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
	Marking in MPLS", RFC 5129, January 2008.
	[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)		[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
	Architecture", RFC 5559, June 2009.		Architecture", RFC 5559, June 2009.
	[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-		[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
	Nodes", RFC 5670, November 2009.		Nodes", RFC 5670, November 2009.
	[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
	Encoding and Transport of Pre-Congestion Information",
	RFC 5696, November 2009.
	[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
	Services Code Point (DSCP) for Capacity-Admitted Traffic",
	RFC 5865, May 2010.
	[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion		[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
	Notification", RFC 6040, November 2010.		Notification", RFC 6040, November 2010.
	12.2. Informative References		12.2. Informative References
	[I-D.ietf-pcn-cl-edge-behaviour]		[I-D.ietf-pcn-cl-edge-behaviour]
	Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.		Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
	Taylor, "PCN Boundary Node Behaviour for the Controlled		Taylor, "PCN Boundary Node Behaviour for the Controlled
	Load (CL) Mode of Operation",		Load (CL) Mode of Operation",
	draft-ietf-pcn-cl-edge-behaviour-08 (work in progress),		draft-ietf-pcn-cl-edge-behaviour-09 (work in progress),
	December 2010.		June 2011.
	[I-D.ietf-pcn-encoding-comparison]		[I-D.ietf-pcn-encoding-comparison]
	Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,		Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,
	Eardley, P., and B. Briscoe, "Overview of Pre-Congestion		Eardley, P., and B. Briscoe, "Overview of Pre-Congestion
	Notification Encoding",		Notification Encoding",
	draft-ietf-pcn-encoding-comparison-05 (work in progress),		draft-ietf-pcn-encoding-comparison-06 (work in progress),
	April 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-05		Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-06
	(work in progress), December 2010.		(work in progress), June 2011.
	Appendix A. Co-existence of ECN and PCN (informative)		[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
			"Assured Forwarding PHB Group", RFC 2597, June 1999.
			[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
			J., Courtney, W., Davari, S., Firoiu, 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
			Congestion Notification (ECN) Signaling with Nonces",
			RFC 3540, June 2003.
			[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
			Guidelines for DiffServ Service Classes", RFC 4594,
			August 2006.
			[RFC4774] Floyd, S., "Specifying Alternate Semantics for the
			Explicit Congestion Notification (ECN) Field", BCP 124,
			RFC 4774, November 2006.
			[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
			DiffServ Service Classes", RFC 5127, February 2008.
			[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
			Marking in MPLS", RFC 5129, January 2008.
			[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
			(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
			Class" Field", RFC 5462, February 2009.
			[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
			Encoding and Transport of Pre-Congestion Information",
			RFC 5696, November 2009.
			[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
			Services Code Point (DSCP) for Capacity-Admitted Traffic",
			RFC 5865, May 2010.
			Appendix A. Choice of Suitable DSCPs
			This appendix is informative, not normative.
			The PCN working group chose not to define a single DSCP for use with
			PCN for several reasons. Firstly, the PCN mechanism is applicable to
			a variety of different traffic classes. Secondly, Standards Track
			DSCPs are in increasingly short supply. Thirdly, PCN is not a
			scheduling behaviour -- rather, it should be seen as being a marking
			behaviour similar to ECN but intended for inelastic traffic. The
			choice of which DSCP is most suitable for a given PCN-domain is
			dependent on the nature of the traffic entering that domain and the
			link rates of all the links making up that domain. In PCN-domains
			with sufficient aggregation, the appropriate DSCPs would currently be
			those for the Real-Time Treatment Aggregate [RFC5127]. The PCN
			working group suggests using admission control for the following
			service classes (defined in [RFC4594]):
			o Telephony (EF)
			o Real-time interactive (CS4)
			o Broadcast Video (CS3)
			o Multimedia Conferencing (AF4)
			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-
			ADMIT codepoint defined in [RFC5865].
			PCN-marking is intended to provide a scalable admission-control
			mechanism for traffic with a high degree of statistical multiplexing.
			PCN-marking would therefore be appropriate to apply to traffic in the
			above classes, but only within a PCN-domain containing sufficiently
			aggregated traffic. In such cases, the above service classes may
			well all be subject to a single forwarding treatment (treatment
			aggregate [RFC5127]). However, this does not imply all such IP
			traffic would necessarily be identified by one DSCP -- each service
			class might keep a distinct DSCP within the highly aggregated region
			[RFC5127].
			Additional service classes may be defined for which admission control
			is appropriate, whether through some future standards action or
			through local use by certain operators, e.g., the Multimedia
			Streaming service class (AF3). This document does not preclude the
			use of PCN in more cases than those listed above.
			Note: The above discussion is informative not normative, as operators
			are ultimately free to decide whether to use admission control for
			certain service classes and whether to use PCN as their mechanism of
			choice.
			Appendix B. Co-existence of ECN and PCN
			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] included advice on handling		the PCN domain. Appendix B of [RFC5696] (obsoleted) included advice
	ECN traffic within a PCN-domain. This appendix clarifies that		on handling ECN traffic within a PCN-domain. This appendix
	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 the PCN-compatible		Admission-controlled traffic will be remarked 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 down from a		control (e.g. through RSVP or some equivalent message, e.g. from
	SIP server to the ingress), and the PCN-ingress remarks traffic		a SIP server to the ingress), and the PCN-ingress remarks traffic
	matching that filterspec to a PCN-compatible DSCP, as its chosen		matching that filterspec to a PCN-compatible DSCP, as its chosen
	admission control mechanism.		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].
	All other traffic can be thought of as Non-admission-controlled.		All other traffic can be thought of as Non-admission-controlled (and
	However such traffic may still need to share the same DSCP as the		therefore outside the scope of PCN). However such traffic may still
	Admission-controlled traffic. This may be due to policy (for		need to share the same DSCP as the Admission-controlled traffic.
	instance if it is high priority voice traffic), or may be because		This may be due to policy (for instance if it is high priority voice
	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 The following lists the four cases for how e2e		also be ECN capable.
	ECN traffic may wish to be treated while crossing a PCN domain:
			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
			PCN domain. However the tunnelling action should be applied wholly
			outside the PCN-domain as illustrated in the following figure:
			, . . . . . PCN-domain . . . . . .
			. ,--------. ,--------. .
			. _| PCN- |___________________| PCN- |_ .
			. / | ingress | | egress | \ .
			.| '---------' '--------' |.
			| . . . . . . . . . . . . . . .|
			,--------. ,--------.
			_____| Tunnel | | Tunnel |____
			| Ingress | - - ECN preserved inside tunnel - - | Egress |
			'---------' '--------'
			Figure 2: Separation of tunneling and PCN actions
			There are four cases for how e2e ECN traffic may wish to be treated
			while crossing a PCN domain:
	ECN capable traffic that does not require admission control and does		ECN capable traffic that does not require admission control and does
	not carry a DSCP that the PCN-ingress is using for PCN-capable		not carry a DSCP that the PCN-ingress is using for PCN-capable
	traffic. This requires no action.		traffic. This requires no action.
	ECN capable traffic that does not require admission control but		ECN capable traffic that does not require admission control but
	carries a DSCP that the PCN-ingress is using for PCN-capable		carries a DSCP that the PCN-ingress is using for PCN-capable
	traffic. There are two options.		traffic. There are two options.
	* The ingress maps the DSCP to a local DSCP with the same		* The ingress maps the DSCP to a local DSCP with the same
	scheduling PHB as the original DSCP, and the egress re-maps it		scheduling PHB as the original DSCP, and the egress re-maps it
	to the original PCN-compatible DSCP.		to the original PCN-compatible DSCP.
	* The ingress tunnels the traffic, setting not-PCN in the outer		* The ingress tunnels the traffic, setting not-PCN in the outer
	header; note that this turns off ECN for this traffic within		header; note that this turns off ECN for this traffic within
	the PCN domain.		the PCN domain.
	skipping to change at page 14, line 25		skipping to change at page 20, line 5
	ECN-capable Admission-controlled traffic: There are two options.		ECN-capable Admission-controlled traffic: 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 not recommended unless tunnelling is not		The second option is emphatically not recommended, unless perhaps
	possible for some reason..		as a last resort if tunnelling is not possible for some
			insurmountable reason.
	ECN-capable Admission-controlled where the e2e transport somehow		ECN-capable Admission-controlled traffic where the e2e transport
	indicates that it wants to see PCN marks: NOTE this is currently		somehow indicates that it wants to see PCN marks: NOTE this is
	experimental only.		currently tentative only.
	Schemes have been suggested where PCN marks may be leaked out of		Schemes have been suggested where PCN marks may be leaked out of
	the PCN-domain and used by the end hosts to modify realtime data		the PCN-domain and used by the end hosts to modify realtime data
	rates. Currently all such schemes are experimental and the		rates. Currently all such schemes require further study and the
	following is for guidance only.		following is for guidance only.
	The PCN-ingress needs to tunnel the traffic using [RFC6040]. The		The PCN-ingress needs to tunnel the traffic, taking care to comply
	PCN-egress should not zero the ECN field, and the tunnel egress		with [RFC6040]. In this case the PCN-egress should not zero the
	should use [RFC6040] normal mode (preserving any PCN-marking).		ECN field, and then the [RFC6040] tunnel egress will preserve any
	Note that this may turn ECT(0) into ECT(1) and so is not		PCN-marking. Note that a PCN interior node may turn ECT(0) into
	compatible with the experimental ECN nonce [RFC3540].		ECT(1), which would not be compatible with the (currently
			experimental) ECN nonce [RFC3540].
	In the list above any form of IP-in-IP tunnel can be used unless		Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in
	specified otherwise. NB, We assume a logical separation of tunneling		MPLS Shim Headers
	and PCN actions in both PCN-ingress and PCN-egress nodes. That is,
	any tunneling action happens wholly outside the PCN-domain as
	illustrated in the following figure:
	, . . . . . PCN-domain . . . . . .		This appendix is informative not normative.
	. ,--------. ,--------. .
	. _| PCN- |___________________| PCN- |_ .
	. / | ingress | | egress | \ .
	.| '---------' '--------' |.
	| . . . . . . . . . . . . . . .|
	,--------. ,--------.
	_____| Tunnel | | Tunnel |____
	| Ingress | - - ECN preserved inside tunnel - - | Egress |
	'---------' '--------'
	Figure 4: Separation of tunneling and PCN actions		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
			make the DS field information accessible in the MPLS header.
			However, the MPLS shim header has only a 3-bit traffic class (TC)
			field [RFC5462] providing for 8 codepoints. The operator has the
			freedom to define a site-local mapping of a subset of the 64
			codepoints of the DS field to the 8 codepoints in the TC field.
			[RFC5129] describes how ECN markings in the IP header can also be
			mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129]
			gives an informative description of how to support PCN in MPLS by
			extending the way MPLS supports ECN. But [RFC5129] was written while
			PCN specifications were in early draft stages. The following
			provides a clearer example of a mapping between PCN in IP and in MPLS
			using the PCN terminology and concepts that have since been
			specified.
			To support PCN in a MPLS domain, codepoints for all used PCN-marks
			need to be provided in the TC field. That means, when e.g. only
			excess-traffic-marking is used for PCN purposes, the operator needs
			to define a site-local mapping to codepoints in the MPLS TC field for
			IP headers with:
			o DSCP n and ECT(0)
			o DSCP n and CE
			If both excess-traffic-marking and threshold-marking are used, 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:
			o DSCP n and ECT(0)
			o DSCP n and ECT(1)
			o DSCP n and CE
			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
			site-local mapping to an MPLS TC codepoint for IP headers marked
			with:
			o DSCP n and Not-ECT
			Appendix D. Rationale for different behaviours for single marking
			schemes
			Readers may notice an apparent discrepancy between the two single
			marking behaviours in Section 5.2.3.1 and Section 5.2.3.2. For the
			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
			requirements. Firstly these behaviours conform with the expected
			behaviour where both metering functions are being used for marking--
			ETM is always a more severe marking than ThM and so should never be
			re-marked. Secondly the threshold-metering behaviour in [RFC5670]
			uses the current marking state of the arriving packet to determine
			what action to take. Consequently, in the ETM only marking it would
			be potentially unsafe to allow ThM packets to propagate forward in
			the network as they may adversely affect the threshold-metering
			function.
	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. 90 change blocks.
	317 lines changed or deleted		601 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/