draft-ietf-pcn-3-in-1-encoding-02.txt		draft-ietf-pcn-3-in-1-encoding-03.txt
	Congestion and Pre-Congestion B. Briscoe		Congestion and Pre-Congestion B. Briscoe
	Notification T. Moncaster		Notification BT
	Internet-Draft BT		Internet-Draft T. Moncaster
	Intended status: Experimental March 08, 2010		Intended status: Experimental Independent
	Expires: September 9, 2010		Expires: January 13, 2011 M. Menth
			University of Wuerzburg
			July 12, 2010
	PCN 3-State Encoding Extension in a single DSCP		Encoding 3 PCN-States in the IP header using a single DSCP
	draft-ietf-pcn-3-in-1-encoding-02		draft-ietf-pcn-3-in-1-encoding-03
	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		On every link in the PCN domain, the overall rate of the PCN-traffic
	PCN-domain, and PCN-packets are appropriately marked when certain		is metered, and PCN-packets are appropriately marked when certain
	configured rates are exceeded. The level of marking allows the		configured rates are exceeded. Egress nodes provide decision points
	boundary nodes to make decisions about whether to admit or block a		with information about the PCN-marks of PCN-packets which allows them
	new flow request, and (in abnormal circumstances) whether to		to take decisions about whether to admit or block a new flow request,
	terminate some of the existing flows, thereby protecting the QoS of		and to terminate some already admitted flows during serious pre-
	previously admitted flows. This document specifies how such marks		congestion.
	are to be encoded into the IP header by re-using the Explicit
	Congestion Notification (ECN) codepoints within this controlled		This document specifies how PCN-marks are to be encoded into the IP
	domain. This encoding builds on the baseline encoding and provides		header by re-using the Explicit Congestion Notification (ECN)
	for three PCN encoding states: Not-marked, Threshold-marked and		codepoints within a PCN-domain. This encoding builds on the baseline
	Excess-traffic-marked.		encoding of RFC5696 and provides for three different PCN marking
			states using a single DSCP: not-marked (NM), threshold-marked (ThM)
			and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN
			encoding.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on January 13, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 BSD License.		described in the Simplified BSD License.
			Table of Contents
			1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
			1.1. Changes in This Version (to be removed by RFC Editor) . . 4
			2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
			2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
			3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5
			3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5
			3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6
			3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 6
			4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7
			5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN
			Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
			6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
			6.1. Backward Compatibility with Pre-existing PCN
			Implementations . . . . . . . . . . . . . . . . . . . . . 8
			6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9
			6.2.1. Use of Both Excess-Traffic-Marking and
			Threshold-Marking . . . . . . . . . . . . . . . . . . 9
			6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 9
			6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 9
			7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
			8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
			9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
			10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
			11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 10
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
			12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
			12.2. Informative References . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	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 (in abnormal circumstances) flow		block a new flow request, and flow termination to decide whether to
	termination to decide whether to terminate some of the existing		terminate some already admitted flows during serious pre-congestion.
	flows. To achieve this, the overall rate of PCN-traffic is metered		To achieve this, the overall rate of PCN-traffic is metered on every
	on every link in the domain, and PCN-packets are appropriately marked		link in the domain, and PCN-packets are appropriately marked when
	when certain configured rates are exceeded. These configured rates		certain configured rates are exceeded. These configured rates are
	are below the rate of the link thus providing notification to		below the rate of the link thus providing notification to boundary
	boundary nodes about overloads before any congestion occurs (hence		nodes about overloads before any congestion occurs (hence "pre-
	"pre-congestion notification").		congestion notification").
	The level of marking allows boundary nodes to make decisions about		Two metering and marking functions are proposed in [RFC5670] that are
	whether to admit or terminate. This is achieved by marking packets		configured with reference rates. Threshold- marking marks all PCN
	on interior nodes according to some metering function implemented at		packets once their traffic rate on a link exceeds the configured
	each node. Threshold-traffic-marking marks all PCN packets once they		reference rate (PCN-threshold-rate). Excess-traffic-marking marks
	exceed the threshold-traffic-rate on a link while Excess-traffic-		only those PCN packets that exceed the configured reference rate
	marking marks only those PCN packets that exceed the excess-traffic-		(PCN-excess-rate). The PCN-excess-rate is typically larger than the
	rate, which is higher than the threshold-traffic-rate [RFC5670].		PCN-threshold-rate [RFC5559]. Egress nodes monitor the PCN-marks of
	These marks are monitored by the egress nodes of the PCN domain.		received PCN-packets and provide information about the PCN-marks to
			decision points which take decisions about flow admission and
			termination on this basis [I-D.ietf-pcn-cl-edge-behaviour],
			[I-D.ietf-pcn-sm-edge-behaviour].
	To fully support these two types of marking, three encoding states		The baseline encoding defined in [RFC5696] describes how two PCN
	are needed. The baseline encoding described in [RFC5696] provides		marking states can be encoded using a single Diffserv codepoint.
	for deployment scenarios that only require two PCN encoding states		However, to support the application of two different marking
	using a single Diffserv codepoint. This document describes an		algorithms in a PCN-domain, for example as required in
	experimental extension to the baseline-encoding that adds a third PCN		[I-D.ietf-pcn-cl-edge-behaviour], three PCN marking states are
	encoding state in the IP header, still using a single Diffserv		needed. This document describes an extension to the baseline
	codepoint. For brevity it will be called the 3-in-1 PCN Encoding.		encoding that adds a third PCN marking state in the IP header, still
			using a single Diffserv codepoint. This encoding scheme is called
			ao˛3-in-1 PCN encodingaoˇ.
	General PCN-related terminology is defined in the PCN architecture		All PCN encoding schemes require an additional marking state to
	[RFC5559], and terminology specific to packet encoding is defined in		indicate non-PCN traffic. Therefore, four codepoints are required to
	the PCN baseline encoding [RFC5696]. Note that [RFC5696] requires		encode three PCN marking states.
	the PCN Working Group to maintain a list of all DSCPs used for PCN
	experiments.		This document only concerns the PCN wire protocol encoding for all IP
			headers, whether IPv4 or IPv6. It makes no changes or
			recommendations concerning algorithms for congestion marking or
			congestion response. Other documents define the PCN wire protocol
			for other header types. For example, the MPLS encoding is defined in
			[RFC5129]. Appendix A provides an informative example for a mapping
			between the encodings in IP and in MPLS.
	1.1. Changes in This Version (to be removed by RFC Editor)		1.1. Changes in This Version (to be removed by RFC Editor)
			From draft-ietf-pcn-3-in-1-encoding-02 to -03:
			* Corrected mistakes in introduction and improved overall
			readability.
			* Added new terminology.
			* Rewrote a good part of Section 4 and 5 to achieve more clarity.
			* Added appendix explaining when to use which encoding scheme and
			how to encode them in MPLS shim headers.
			* Added new co-author.
	From draft-ietf-pcn-3-in-1-encoding-01 to -02:		From draft-ietf-pcn-3-in-1-encoding-01 to -02:
	* Corrected mistake in introduction, which wrongly stated that		* Corrected mistake in introduction, which wrongly stated that
	the threshold-traffic rate is higher than the excess-traffic		the threshold-traffic rate is higher than the excess-traffic
	rate. Other minor corrections.		rate. Other minor corrections.
	* Updated acks & refs.		* Updated acks & refs.
	From draft-ietf-pcn-3-in-1-encoding-00 to -01:		From draft-ietf-pcn-3-in-1-encoding-00 to -01:
	skipping to change at page 3, line 47		skipping to change at page 5, line 9
	* References updated.		* References updated.
	* Terminology brought into line with [RFC5670].		* Terminology brought into line with [RFC5670].
	* Minor corrections.		* Minor corrections.
	2. Requirements Language		2. 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 RFC 2119 [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. The Requirement for Three PCN Encoding States		2.1. Terminology
	The PCN architecture [RFC5559] describes proposed PCN schemes that		General PCN-related terminology is defined in the PCN architecture
	expect traffic to be metered and marked using both Threshold and		[RFC5559], and terminology specific to packet encoding is defined in
	Excess Traffic schemes. In order to achieve this it is necessary to		the PCN baseline encoding [RFC5696]. Additional terminology is
	allow for three PCN encoding states: one as a Not Marked (NM) state		defined below.
	and the other two to distinguish these two levels of marking severity
	[RFC5670]. The way tunnels processed the ECN field before
	[I-D.ietf-tsvwg-ecn-tunnel] severely limited how to encode these
	states.
	The two bit ECN field seems to offer four possible encoding states,		PCN encoding: mapping of PCN marking states to specific codepoints
	but one (00) is set aside for traffic controlled by transports that		in the packet header.
	do not understand PCN marking [RFC5696], so it would be irregular and
	risky to use it as a PCN encoding state. Of the three remaining ECN
	codepoints, only one (11) can be introduced by a congested node
	within a tunnel and still survive the decapsulation behaviour of a
	tunnel egress not updated to comply with [I-D.ietf-tsvwg-ecn-tunnel].
	The two remaining codepoints are (10) and (01). But if a node within
	the tunnel used either of these two remaining codepoints to try to
	mark packets with a second severity level, a tunnel not updated to
	comply with [I-D.ietf-tsvwg-ecn-tunnel] would remove this marking on
	decapsulation. The ECN field was constrained to two marking states
	in this way irrespective of which earlier ECN tunnelling
	specification the tunnel complied with, whether regular IP in IP
	tunnelling [RFC3168] or IPsec tunnelling [RFC4301].
	One way to provide another encoding state that survives tunnelling is		3. Requirements for and Applicability of 3-in-1 PCN Encoding
	to use a second Diffserv codepoint [I-D.ietf-pcn-3-state-encoding].
	Instead, to avoid wasting scarce Diffserv codepoints, a network
	operator can require tunnels in a PCN region to comply with
	[I-D.ietf-tsvwg-ecn-tunnel], thus removing the constraints imposed by
	earlier tunnelling specifications.
	Therefore this document presupposes tunnels in the PCN region comply		3.1. PCN Requirements
	with the newly proposed decapsulation rules defined in
	[I-D.ietf-tsvwg-ecn-tunnel]. Then the constraints of standard
	tunnels no longer apply so this document can define a 3-state
	encoding for PCN within one Diffserv codepoint.
	4. The 3-in-1 PCN Encoding		The PCN architecture [RFC5559] defines that PCN-ingress-nodes of a
			PCN-domain control incoming packets. Packets belonging to PCN-
			controlled flows are subject to PCN metering and marking, they are
			termed PCN-packets, and PCN-ingress-nodes mark them as not-marked
			(PCN-colouring). Any node in the PCN-domain may perform PCN metering
			and marking and mark PCN-packets if needed. There are two different
			metering and marking schemes: threshold-marking and excess-traffic-
			marking [RFC5670]. Some edge behaviors require only a single marking
			scheme [I-D.ietf-pcn-sm-edge-behaviour], others require both
			[I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN
			marking states are needed: not-marked (NM) to indicate not-marked
			packets, threshold-marked (ThM) to indicate packets marked by the
			threshold-marker, and excess-traffic-marked (ETM) to indicate packets
			marked by the excess-traffic-marker [RFC5670]. As threshold-marking
			and excess-traffic-marking start marking packets at different load
			conditions, one marking scheme indicates more severe pre-congestion
			than the other in terms of higher load. If a packet has been marked
			by both a threshold-marker and an excess-traffic-marker, it is marked
			with the more severe state. Therefore, a fourth PCN marking state
			indicating that a packet is marked by both markers is not needed.
	The 3-in-1 PCN Encoding scheme is based closely on the baseline		Nonetheless, in addition to codepoints for the three PCN marking
	encoding defined in [RFC5696] so that there will be no compatibility		states a fourth codepoint is required to indicate packets that are
	issues if a PCN-domain evolves from using the baseline encoding		not PCN-capable (termed the not-PCN codepoint).
	scheme to the experimental scheme described here. The exact manner
	in which the PCN encoding states are carried in the IP header is		In all current PCN edge behaviors that use two marking schemes
	shown in Figure 1.		[RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-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
			severe PCN-mark than threshold-marked.
			3.2. Requirements Imposed by Baseline Encoding
			The baseline encoding scheme [RFC5696] was defined so that it could
			be extended to accommodate an additional marking state. It provides
			rules to embed the encoding of two PCN states in the IP header.
			Figure 1 shows the structure of the former type-of-service field. It
			contains the 6-bit Differentiated Services (DS) field that holds the
			DS codepoint (DSCP) [RFC2474] and the 2-bit ECN field [RFC3168].
			0 1 2 3 4 5 6 7
			+-----+-----+-----+-----+-----+-----+-----+-----+
			| DS FIELD | ECN FIELD |
			+-----+-----+-----+-----+-----+-----+-----+-----+
			Figure 1: Structure of the former type-of-service field in IP
			Baseline encoding defines that the DSCP must be set to a PCN-
			compatible DSCP n and the ECN-field [RFC3168] indicates the specific
			PCN-mark. Baseline encoding offers four possible encoding states
			within a single DSCP with the following restrictions.
			o Codepoint `00' (not-ECT) is used to indicate non-PCN traffic as
			"not-PCN". This allows the use of a DSCP for both PCN and non-PCN
			traffic.
			o Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN
			traffic.
			o Codepoint `11' (CE) is used to indicate the most severe PCN-mark.
			o Codepoint `01' (ECT(1)) is available for experimental use and may
			be re-used by other PCN encodings such as the presently defined
			3-in-1 PCN encoding.
			3.3. Applicability of 3-in-1 PCN Encoding
			When PCN traffic is tunneled IP-in-IP within a PCN-domain, PCN-marks
			must be preserved in all outer IP headers after encapsulation and
			decapsulation. This property is violated by legacy encapsulation and
			decapsulation rules [RFC3168], [RFC4301] due to the way they treat
			the ECN field. This led to strong limitations regarding how PCN-
			marks can be encoded using the ECN field of the IP header
			[I-D.ietf-pcn-encoding-comparison]. Therefore, baseline encoding
			[RFC5696] was defined which works well with legacy tunnels but
			supports only two PCN marking states.
			Since then, new rules have been defined for IP-in-IP tunneling
			[I-D.ietf-tsvwg-ecn-tunnel] so that the present 3-in-1 PCN encoding
			has more freedom to accommodate PCN-marks using the ECN field. From
			this follows that 3-in-1 PCN encoding may be applied only in PCN-
			domains that comply with [I-D.ietf-tsvwg-ecn-tunnel] or do not use
			tunneling.
			4. Definition of 3-in-1 PCN Encoding
			The 3-in-1 PCN encoding scheme is an extension of the baseline
			encoding scheme defined in [RFC5696]. The PCN requirements and the
			extension rules for baseline encoding presented in the previous
			section determine how PCN encoding states are carried in the IP
			headers. This is shown in Figure 2.
	+--------+----------------------------------------------------+		+--------+----------------------------------------------------+
	| | 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 2: 3-in-1 PCN Encoding
	In Figure 1 the 3 PCN states are encoded in the ECN field [RFC3168]
	of an IP packet with its Diffserv field [RFC2474] set to DSCP n,
	which is any PCN-Compatible DiffServ codepoint as defined in Section
	4.2 of the PCN baseline encoding [RFC5696]). The PCN codepoint of a
	packet defines its marking state as follows:
	Not-PCN: The packet is controlled by a transport that does not		Like baseline encoding, 3-in-1 PCN encoding also uses a PCN
	understand PCN marking, therefore the only valid action to notify		compatible DSCP n and the ECN field for the encoding of PCN-marks.
	congestion is to drop the packet;		The PCN-marks have the following meaning.
	NM: Not marked. A packet in the NM state has not (yet) had its		Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not
	marking state changed to the ThM or ETM states, but it may be		subject to PCN metering and marking.
	changed to one of these states by a node experiencing congestion
	or pre-congestion;
	ThM: Threshold-marked. Such a packet has had its marking state		NM: Not-marked. Indicates a PCN-packet that has not yet been marked
	changed by the threshold-meter function [RFC5670];		by any PCN marker.
	ETM: Excess-traffic-marked. Such a packet has had its marking state		ThM: Threshold-marked. Indicates a PCN-packet that has been marked
	changed by the excess-traffic-meter function [RFC5670].		by a threshold-marker [RFC5670].
	Packets marked NM, ThM or ETM are termed PCN-packets. Their entry		ETM: Excess-traffic-marked. Indicates a PCN-packet that has been
	into the pcn-domain is controlled by edge nodes that understand how		marked by an excess-traffic-marker [RFC5670].
	to process PCN markings [RFC5559].
	5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding		5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding
	To be compliant with the 3-in-1 PCN Encoding, an PCN interior node		To be compliant with the 3-in-1 PCN Encoding, an PCN interior node
	behaves as follows:		behaves as follows:
	o Except where explicitly stated otherwise, it MUST comply with the
	baseline encoding specified in [RFC5696]
	o It MUST change NM to ThM if the threshold-meter function indicates		o It MUST change NM to ThM if the threshold-meter function indicates
	to mark the packet.		to mark the packet.
	o It MUST change NM or ThM to ETM if the excess-traffic-meter		o It MUST change NM or ThM to ETM if the excess-traffic-meter
	function indicates to mark the packet.		function indicates to mark the packet.
	o It MUST NOT change Not-PCN to a PCN-Enabled codepoint and MUST NOT		o It MUST NOT change not-PCN to NM, ThM, or ETM, and MUST NOT change
	change a PCN-Enabled codepoint to Not-PCN;		a NM, ThM, or ETM to not-PCN;
	o It MUST NOT change ThM to NM;		o It MUST NOT change ThM to NM;
	o It MUST NOT change ETM to ThM or to NM;		o It MUST NOT change ETM to ThM or to NM;
	In other words, a PCN interior node may increase the severity of		In other words, a PCN interior node MUST NOT mark PCN-packets into
	packet marking but it MUST NOT decrease it, where the order of		non-PCN packets and vice-versa, and it may increase the severity of
	severity increases from NM through ThM to ETM.		the PCN-mark of a PCN-packet, but it MUST NOT decrease it.
	6. IANA Considerations		6. Backward Compatibility
			Discussion of backward compatibility between PCN encoding schemes and
			previous uses of the ECN field is given in Section 6 of [RFC5696].
			6.1. Backward Compatibility with Pre-existing PCN Implementations
			This encoding complies with the rules for extending the baseline PCN
			encoding schemes in Section 5 of [RFC5696].
			The term "compatibility" is meant in the following sense. It is
			possible to operate nodes with baseline encoding [RFC5696] and 3-in-1
			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
			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 still
			occurs.
			6.2. Recommendations for the Use of PCN Encoding Schemes
			This sub-section is informative not normative.
			+------------------------+------------------------------------+
			| Used marking schemes | Recommended PCN 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: Use of PCN encoding schemes
			Figure 3 gives guidelines under which conditions baseline encoding
			and 3-in-1 PCN encoding would typically be used.
			6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Marking
			If both excess-traffic-marking and threshold-marking are enabled in a
			PCN-domain, 3-in-1 encoding should be used as described in this
			document.
			6.2.2. Unique Use of Excess-Traffic-Marking
			If only excess-traffic-marking is enabled in a PCN-domain, baseline
			encoding or 3-in-1 encoding may be used. They lead to the same
			encoding because PCN-boundary nodes will interpret baseline "PCN-
			marked (PM)" as "excess-traffic-marked (ETM)".
			6.2.3. Unique Use of Threshold-Marking
			No scheme is currently proposed to solely use threshold-marking.
			However, if only threshold-marking is enabled in a PCN-domain,
			baseline encoding SHOULD be used. This is because threshold marking
			will work in combination with legacy tunnel decapsulators within the
			PCN-domain, while using threshold marking with the 3-in-1 encoding
			requires that tunnel decapsulators within a PCN-domain comply with
			[I-D.ietf-tsvwg-ecn-tunnel].
			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.
	7. Security Considerations		8. Security Considerations
	The security concerns relating to this extended PCN encoding are the		The security concerns relating to this extended PCN encoding are the
	same as those in [RFC5696].		same as those in [RFC5696]. In summary, PCN-boundary nodes are
			responsible for ensuring inappropriate PCN markings do not leak into
			or out of a PCN domain, and the current phase of the PCN architecture
			assumes that all the nodes of a PCN-domain are entirely under the
			control of a single operator, or a set of operators who trust each
			other.
	8. Conclusions		Given the only difference between the baseline encoding and the
			present 3-in-1 encoding is the use of the 01 codepoint, no new
			security issues are raised, as this codepoint was already available
			for experimental use in the baseline encoding.
	The 3-in-1 PCN Encoding provides three states to encode PCN markings		9. Conclusions
	in the ECN field of an IP packet using just one Diffserv codepoint.
	One state is for not marked packets while the two others are for PCN
	nodes to mark packets with increasing levels of severity. Use of
	this encoding presupposes that any tunnels in the PCN region have
	been updated to comply with [I-D.ietf-tsvwg-ecn-tunnel].
	9. Acknowledgements		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
			carried with the same PCN-compatible DSCP and three other codepoints
			support three PCN marking states with different levels of severity.
			The use of this PCN encoding scheme presupposes that any tunnels in
			the PCN region have been updated to comply with
			[I-D.ietf-tsvwg-ecn-tunnel].
	Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Michael Menth for		10. Acknowledgements
	reviewing this.
	10. Comments Solicited		Thanks to Phil Eardley, Teco Boot, and Kwok Ho Chan for reviewing
			this document.
			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.
	11. References		12. References
			12.1. Normative References
	11.1. Normative References
	[I-D.ietf-tsvwg-ecn-tunnel]
	Briscoe, B., "Tunnelling of Explicit Congestion
	Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in
	progress), March 2010.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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.
			[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
			Internet Protocol", RFC 4301, December 2005.
			[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		[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
	Encoding and Transport of Pre-Congestion Information",		Encoding and Transport of Pre-Congestion Information",
	RFC 5696, November 2009.		RFC 5696, November 2009.
	11.2. Informative References		12.2. Informative References
	[I-D.ietf-pcn-3-state-encoding]		[I-D.ietf-pcn-cl-edge-behaviour]
	Briscoe, B., Moncaster, T., and M. Menth, "A PCN encoding		Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
	using 2 DSCPs to provide 3 or more states",		Taylor, "PCN Boundary Node Behaviour for the Controlled
	draft-ietf-pcn-3-state-encoding-01 (work in progress),		Load (CL) Mode of Operation",
	February 2010.		draft-ietf-pcn-cl-edge-behaviour-06 (work in progress),
			June 2010.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[I-D.ietf-pcn-encoding-comparison]
	Internet Protocol", RFC 4301, December 2005.		Chan, K., Karagiannis, G., Moncaster, T., Menth, M.,
			Eardley, P., and B. Briscoe, "Pre-Congestion Notification
			Encoding Comparison",
			draft-ietf-pcn-encoding-comparison-02 (work in progress),
			March 2010.
			[I-D.ietf-pcn-sm-edge-behaviour]
			Charny, A., Karagiannis, G., Menth, M., and T. Taylor,
			"PCN Boundary Node Behaviour for the Single Marking (SM)
			Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-03
			(work in progress), June 2010.
			[I-D.ietf-tsvwg-ecn-tunnel]
			Briscoe, B., "Tunnelling of Explicit Congestion
			Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in
			progress), March 2010.
	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
	BT		Independent
	c/o B54/70, Adastral Park
	Martlesham Heath
	Ipswich IP5 3RE
	UK
	Phone: +44 1206 332805		Email: toby@moncaster.com
	Email: toby.moncaster@bt.com
			Michael Menth
			University of Wuerzburg
			room B206, Institute of Computer Science
			Am Hubland
			Wuerzburg 97074
			Germany
			Phone: +49 931 31 86644
			Email: menth@informatik.uni-wuerzburg.de
End of changes. 44 change blocks.
	165 lines changed or deleted		358 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/