draft-moncaster-pcn-baseline-encoding-00.txt		draft-moncaster-pcn-baseline-encoding-01.txt
	Congestion and Pre Congestion T. Moncaster		Congestion and Pre Congestion T. Moncaster
	Internet-Draft BT		Internet-Draft BT
	Intended status: Standards Track B. Briscoe		Intended status: Standards Track B. Briscoe
	Expires: November 16, 2008 BT & UCL		Expires: December 25, 2008 BT & UCL
	M. Menth		M. Menth
	University of Wuerzburg		University of Wuerzburg
	May 15, 2008		June 23, 2008
	Encoding and Transport of (Pre-)Congestion Information from within a		Baseline Encoding and Transport of Pre-Congestion Information
	DiffServ Domain to the Egress		draft-moncaster-pcn-baseline-encoding-01
	draft-moncaster-pcn-baseline-encoding-00
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
	skipping to change at page 1, line 38		skipping to change at page 1, line 37
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 16, 2008.		This Internet-Draft will expire on December 25, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	Pre-congestion notification (PCN) is a mechanism designed to protect		Pre-congestion notification (PCN) provides information to support
	the Quality of Service of inelastic flows. It does this by marking		admission control and flow termination in order to protect the
			Quality of Service of inelastic flows. It does this by marking
	packets when traffic load on a link is approaching or has exceeded a		packets when traffic load on a link is approaching or has exceeded a
	threshold below the physical link rate. This document specifies how		rate threshold below the physical link rate. This document specifies
	such marks are to be encoded into the IP header. The baseline		how such marks are to be encoded into the IP header. The baseline
	encoding described here provides for two PCN encoding states.		encoding described here provides for only two PCN encoding states.
			Another document describes an extended encoding scheme that allows
			for three encoding states.
	Status		Status
	This memo is posted as an Internet-Draft with an intent to eventually		This memo is posted as an Internet-Draft with an intent to eventually
	progress to standards track.		progress to standards track.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Encoding Two PCN States in IP . . . . . . . . . . . . . . . . 3		4. Encoding two PCN States in IP . . . . . . . . . . . . . . . . 4
	4.1. Rationale for Encoding . . . . . . . . . . . . . . . . . . 4		4.1. Rationale for Encoding . . . . . . . . . . . . . . . . . . 5
	4.2. PCN-Enabled DiffServ Codepoints . . . . . . . . . . . . . 5		4.2. PCN-Enabled DiffServ Codepoints . . . . . . . . . . . . . 5
	4.3. Valid and Invalid Encoding Transitions at a PCN Node . . . 5		4.2.1. Implications of re-using a DiffServ Codepoint . . . . 5
	5. Backwards Compatability . . . . . . . . . . . . . . . . . . . 5		4.3. Valid and Invalid Encoding Transitions at a PCN Node . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. Backwards Compatability . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 7		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 8
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 7		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	11.2. Informative References . . . . . . . . . . . . . . . . . . 7		11.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	Appendix A. Tunnelling Constraints . . . . . . . . . . . . . . . 8		11.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Appendix A. Tunnelling Constraints . . . . . . . . . . . . . . . 9
	Intellectual Property and Copyright Statements . . . . . . . . . . 10		Appendix B. Deployment Scenarios for PCN Using Baseline
			Encoding . . . . . . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
			Intellectual Property and Copyright Statements . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Pre-congestion notification is a mechanism designed to help protect		Pre-congestion notification (PCN) provides information to support
	the Quality of Service of inelastic flows. It does this by measuring		admission control and flow termination in order to protect the
	the pre-congestion level on the path used by that flow. The pre-		quality of service (QoS) of inelastic flows. This is achieved by
	congestion level at each node is indicated by marking packets when		marking packets according to the level of pre-congestion at nodes
	traffic load is approaching or has exceeded a threshold below the		within the PCN-domain. Two algorithms exist for that purpose.
	physical link rate. [PCN-arch] describes how PCN marking can be used		Excess traffic marking marks all PCN packets exceeding a certain
	to assure the quality of service of inelastic flows within a single		reference rate on a link while threshold marking marks all PCN
	DiffServ domain. This document specifies how those PCN marks are		packets on a link when the PCN traffic rate exceeds the reference
	encoded into the IP header. It also describes how packets are		rate. These markings are evaluated by the egress nodes of the PCN-
	identified as belonging to a PCN flow. The baseline encoding		domain. [PCN-arch] describes how PCN packet markings can be used to
	described here provides for two PCN encoding states.		assure the QoS of inelastic flows within a single DiffServ domain.
			This document specifies how these PCN marks are encoded into the IP
			header. It also describes how packets are identified as belonging to
			a PCN flow. Some deployment models require two PCN encoding states,
			others require three. The baseline encoding described here only
			provides for two PCN encoding states. An extended encoding described
			in [PCN-3-enc-state] provides for three PCN encoding states.
			Changes from previous drafts (to be removed by the RFC Editor)
			From -00 to -01:
			Change of title from "Encoding and Transport of (Pre-)Congestion
			Information from within a DiffServ Domain to the Egress"
			Extensive changes to Introduction and abstract.
			Added a section on the implications of re-using a DSCP.
			Added appendix listing possible operator scenarios for using this
			baseline encoding.
			Minor changes throughout.
	2. Requirements notation		2. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Terminology		3. Terminology
	The following terms are used in this document:		The following terms are used in this document:
	skipping to change at page 3, line 46		skipping to change at page 4, line 22
	o PCN-Capable codepoints - collective term for all the NM and PM		o PCN-Capable codepoints - collective term for all the NM and PM
	codepoints.		codepoints.
	o PCN enabled Diffserv codepoint - a Diffserv codepoint for which		o PCN enabled Diffserv codepoint - a Diffserv codepoint for which
	PCN has been enabled on a particular machine.		PCN has been enabled on a particular machine.
	In addition the document uses the terminology described in		In addition the document uses the terminology described in
	[PCN-arch].		[PCN-arch].
	4. Encoding Two PCN States in IP		4. Encoding two PCN States in IP
	The PCN encoding states are defined using a combination of the DSCP		The PCN encoding states are defined using a combination of the DSCP
	field and ECN field in the IP header. The baseline PCN encoding		field and ECN field in the IP header. The baseline PCN encoding
	closely follows the semantics of ECN [RFC3168]. It allows the		closely follows the semantics of ECN [RFC3168]. It allows the
	encoding of two PCN states: Not Marked and PCN-Marked. It also		encoding of two PCN states: Not Marked and PCN-Marked. It also
	allows for traffic that is not PCN capable to be marked as such (Not-		allows for traffic that is not PCN capable to be marked as such (not-
	PCN). The following table defines how to encode these states in IP:		PCN). The following table defines how to encode these states in IP:
	+--------+--------------+-------------+-------------+---------+		+--------+--------------+-------------+-------------+---------+
	| DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) |		| DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) |
	+--------+--------------+-------------+-------------+---------+		+--------+--------------+-------------+-------------+---------+
	| DSCP n | Not-PCN | NM | NM | PM |		| DSCP n | not-PCN | NM | NM | PM |
	+--------+--------------+-------------+-------------+---------+		+--------+--------------+-------------+-------------+---------+
	Where DSCP n is a PCN-enabled DiffServ codepoint (see Section 4.2)		Where DSCP n is a PCN-enabled DiffServ codepoint (see Section 4.2)
	Table 1: Encoding PCN in IP		Table 1: Encoding PCN in IP
	The following rules apply to all PCN traffic:		The following rules apply to all PCN traffic:
	o PCN traffic MUST be marked with a DiffServ codepoint that		o PCN traffic MUST be marked with a DiffServ codepoint that
	indicates PCN is enabled. To conserve DSCPs, DiffServ Codepoints		indicates PCN is enabled. To conserve DSCPs, DiffServ Codepoints
	SHOULD be chosen that are already defined for use with admission		SHOULD be chosen that are already defined for use with admission
	controlled traffic, such as the Voice-Admit codepoint defined in		controlled traffic, such as the Voice-Admit codepoint defined in
	[voice-admit].		[voice-admit].
	o Any packet that is not PCN capable (Not-PCN) but which shares the		o Any packet that is not PCN capable (not-PCN) but which shares the
	same DiffServ codepoint as PCN capable traffic MUST have the ECN		same DiffServ codepoint as PCN capable traffic MUST have the ECN
	field set to 00.		field set to 00.
	o Any packet that is PCN capable and Not Marked (NM) MUST have the		o Any packet that belongs to a PCN capable flow MUST have the ECN
	ECN field set to one of the two ECT codepoints 10 or 01.		field set to one of the two ECT codepoints 10 or 01 at the PCN-
			ingress-node.
	o Any packet that is PCN capable and has been PCN-marked by an		o Any packet that is PCN capable and has been PCN-marked by a PCN-
	interior node MUST have the ECN field set to 11.		interior-node MUST have the ECN field set to 11.
	4.1. Rationale for Encoding		4.1. Rationale for Encoding
	The exact choice of encoding was dictated by the constraints imposed		The exact choice of encoding was dictated by the constraints imposed
	by existing IETF RFCs. Full details are contained in		by existing IETF RFCs, in particular [RFC3168] and [RFC4774]. Full
	[pcn-enc-compare]. One of the tightest constraints was the need for		details are contained in [pcn-enc-compare]. One of the tightest
	any PCN encoding to survive being tunnelled through either an IP in		constraints was the need for any PCN encoding to survive being
	IP tunnel or an IPSec Tunnel. Appendix A explains this in more		tunnelled through either an IP in IP tunnel or an IPSec Tunnel.
	detail. The main effect of this constraint was that any PCN marking		Appendix A explains this in detail. The main effect of this
	has to use the ECN field set to 11 (CE codepoint). An additional		constraint was that any PCN marking has to use the ECN field set to
	constraint was the need to minimise the use of DiffServ codepoints as		11 (CE codepoint). If the packet is being tunneled then only the CE
	these are in increasingly short supply. Section 4.2 explains how we		codepoint gets copied into the inner header upon decapsulation. An
	have minimised this still further by reusing pre-existing Diffserv		additional constraint was the need to minimise the use of DiffServ
	codepoint(s) such that non-PCN traffic can still be distinguished		codepoints as these are in increasingly short supply. Section 4.2
	from PCN traffic.		explains how we have minimised this still further by reusing pre-
			existing Diffserv codepoint(s) such that non-PCN traffic can still be
			distinguished from PCN traffic.
	The encoding scheme that best addresses the above constraints ends up		The encoding scheme (Table 1) that best addresses the above
	looking very similar to ECN. This is perhaps not surprising given		constraints ends up looking very similar to ECN. This is perhaps not
	the similarity in architectural intent between PCN and ECN.		surprising given the similarity in architectural intent between PCN
			and ECN.
	4.2. PCN-Enabled DiffServ Codepoints		4.2. PCN-Enabled DiffServ Codepoints
	Equipment complying with the baseline PCN encoding MUST allow PCN to		Equipment complying with the baseline PCN encoding MUST allow PCN to
	be enabled for a certain Diffserv codepoint or codepoints. This		be enabled for a certain Diffserv codepoint or codepoints. This
	document defines the term 'PCN-Enabled Diffserv Codepoint' for such a		document defines the term 'PCN-Enabled Diffserv Codepoint' for such a
	DSCP. Enabling PCN for a DSCP switches on PCN marking behaviour for		DSCP. Enabling PCN for a DSCP switches on PCN marking behaviour for
	packets with that DSCP, but only if those packets also have their ECN		packets with that DSCP, but only if those packets also have their ECN
	field set to a codepoint other than Not-PCN.		field set to a codepoint other than not-PCN.
	Enabling PCN marking behaviour disables any other marking behaviour		Enabling PCN marking behaviour disables any other marking behaviour
	(e.g. enabling PCN also disables the default ECN marking behaviour		(e.g. enabling PCN also disables the default ECN marking behaviour
	introduced in [RFC3168]). The scheduling behaviour used for a packet		introduced in [RFC3168]). The scheduling behaviour used for a packet
	does not change whether PCN is enabled for a DSCP or not and whatever		does not change whether PCN is enabled for a DSCP or not and whatever
	the setting of the ECN field.		the setting of the ECN field.
			4.2.1. Implications of re-using a DiffServ Codepoint
			[RFC4774] requires that packets for which alternate ECN semantics
			(PCN semantics) are used are clearly distinguished from packets to
			which the semantics according to [RFC3168] apply. This is done by
			using a DSCP to indicate that the ECN field is to be interpreted in
			the PCN context instead of the ECN context by PCN-enabled nodes.
			Non-PCN-enabled forwarding nodes outside or inside the PCN domain
			treat packets with a PCN-enabled DSCP like ECN traffic if appropriate
			ECN codepoints are set in the IP header. This has several
			consequences.
			o Care must be taken that the PCN encoding of packets is not falsely
			interpreted by forwarding nodes as ECN encoding, and that no harm
			is done if this were to happen. To that end, appropriate marking
			and re-marking is performed at the ingress and the egress of a PCN
			domain.
			o The re-used DSCP should be able to serve its original purpose
			which was not PCN support. This is achieved by marking the
			packets of such flows with a not-PCN codepoint.
			o The scheduling behaviour is coupled with the DSCP only.
			Therefore, the same scheduling and buffer management rules are
			applied for non-PCN-capable and PCN-capable traffic using the same
			PCN-enabled DSCP.
			o Once the ECN field of a packet is used for PCN encoding, it has
			lost its previous information unless this information was
			tunnelled through the PCN domain. Therefore, the baseline PCN
			encoding disables ECN for PCN-enabled DSCPs. [PCN-3-enc-state]
			provides end-to-end ECN support where this is needed.
	4.3. Valid and Invalid Encoding Transitions at a PCN Node		4.3. Valid and Invalid Encoding Transitions at a PCN Node
	PCN edge node behaviour compliant with the PCN baseline encoding:		PCN edge node behaviour compliant with the PCN baseline encoding:
	o Any packets with the ECN field already marked as CE or ECT		o Any packets with the ECN field already marked as CE or ECT
	arriving at a PCN ingress node SHOULD be dropped or alternatively		arriving at a PCN ingress node SHOULD be dropped or alternatively
	MAY be tunnelled through the PCN region. They MUST NOT be		MAY be tunnelled through the PCN-domain. They MUST NOT be
	admitted to the PCN region directly.		admitted to the PCN-domain directly.
	o On leaving the PCN region the ECN bits MUST be set to 00 (Not		o On leaving the PCN-domain the ECN bits MUST be set to 00 (Not
	ECT).		ECT).
	PCN interior node behaviour compliant with the PCN baseline encoding:		PCN interior node behaviour compliant with the PCN baseline encoding:
	o PCN Interior nodes MUST NOT change Not-PCN to another codepoint		o PCN Interior nodes MUST NOT change not-PCN to another codepoint
	and they MUST NOT change a PCN-Capable codepoint to Not-PCN.		and they MUST NOT change a PCN-Capable codepoint to not-PCN.
	o PCN interior nodes that are in a pre-congestion state above the		o PCN interior nodes that are in a pre-congestion state above the
	configured level MUST set the PM codepoint by changing the ECN		configured level MUST set the PM codepoint by changing the ECN
	bits to 11.		bits of NM marked packets to 11.
	o PM MUST NOT be changed to NM.		o The PM codepoint MUST NOT be changed to NM.
	5. Backwards Compatability		5. Backwards Compatability
	BCP 124 [RFC4774] gives guidelines for specifying alternative		BCP 124 [RFC4774] gives guidelines for specifying alternative
	semantics for the ECN field. It sets out a number of factors that		semantics for the ECN field. It sets out a number of factors that
	must be taken into consideration. It also suggests various		must be taken into consideration. It also suggests various
	techniques to allow the co-existence of default ECN and alternative		techniques to allow the co-existence of default ECN and alternative
	ECN semantics. The alternative semantics specified here are		ECN semantics. The alternative semantics specified here are
	compliant with this BCP:		compliant with this BCP:
	skipping to change at page 6, line 30		skipping to change at page 7, line 39
	Voice-Admit [voice-admit] DSCP.		Voice-Admit [voice-admit] DSCP.
	7. Security Considerations		7. Security Considerations
	Packets claim entitlement to be PCN marked by carrying a PCN-enabled		Packets claim entitlement to be PCN marked by carrying a PCN-enabled
	DSCP and a PCN-Capable ECN codepoint. This encoding document is		DSCP and a PCN-Capable ECN codepoint. This encoding document is
	intended to stand independently of the architecture used to determine		intended to stand independently of the architecture used to determine
	whether specific packets are authorised to be PCN marked, which will		whether specific packets are authorised to be PCN marked, which will
	be described in a future separate document on PCN edge-node		be described in a future separate document on PCN edge-node
	behaviour. The PCN working group has initially been chartered to		behaviour. The PCN working group has initially been chartered to
	only consider a PCN region to be entirely under the control of one		only consider a PCN-domain to be entirely under the control of one
	operator, or a set of operators who trust each other [PCN-charter].		operator, or a set of operators who trust each other [PCN-charter].
	However there is a requirement to keep inter-domain scenarios in mind		However there is a requirement to keep inter-domain scenarios in mind
	when defining the PCN encoding. One way to extend to multiple		when defining the PCN encoding. One way to extend to multiple
	domains would be to concatenate PCN regions and use PCN edge-nodes		domains would be to concatenate PCN-domains and use PCN-boundary-
	back-to back at borders. Then any one domain's security against its		nodes back to back at borders. Then any one domain's security
	neighbours would be described as part of the edge-node behaviour		against its neighbours would be described as part of the edge-node
	document as above. There is only one proposal on the table to extend		behaviour document as above. One proposal on the table allows one to
	PCN across multiple domains without PCN edge nodes back-to-back at		extend PCN across multiple domains without PCN edge nodes back-to-
	borders [re-PCN]. it is believed that the encoding described here		back at borders [re-PCN]. It is believed that the encoding described
	would not be incompatible with the security framework described		here would not be incompatible with the security framework described
	there.		there.
	8. Conclusions		8. Conclusions
	This document defines the baseline PCN encoding utilising a		This document defines the baseline PCN encoding utilising a
	combination of a PCN-enabled DSCP and the ECN field in the IP header.		combination of a PCN-enabled DSCP and the ECN field in the IP header.
	This baseline encoding allows the existence of two PCN encoding		This baseline encoding allows the existence of two PCN encoding
	states, Not Marked and PCN-Marked. It also allows for the co-		states, Not Marked and PCN-Marked. It also allows for the co-
	existence of non-PCN traffic within the same DSCP. The encoding		existence of non-PCN traffic within the same DSCP. The encoding
	scheme is conformant with [RFC4774].		scheme is conformant with [RFC4774].
	9. Acknowledgements		9. Acknowledgements
	This document builds extensively on work done in the PCN working		This document builds extensively on work done in the PCN working
	group by Kwok Ho Chan, Georgios Karagiannis, Michael Menth, Philip		group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley and
	Eardley, Bob Briscoe and others. Full details of the alternative		others. Full details of the alternative schemes that were considered
	schemes that were considered for adoption can be found in the sister		for adoption can be found in the document [pcn-enc-compare]. Thanks
	document [pcn-enc-compare].		to Ruediger Geib for providing comments on this document.
	10. Comments Solicited		10. Comments Solicited
	Comments and questions are encouraged and very welcome. They can be		Comments and questions are encouraged and very welcome. They can be
	addressed to the IETF Transport Area working group mailing list		addressed to the IETF Transport Area working group mailing list
	<tsvwg@ietf.org>, and/or to the authors.		<tsvwg@ietf.org>, and/or to the authors.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[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.
	[RFC4774] Floyd, S., "Specifying Alternate Semantics for the		[RFC4774] Floyd, S., "Specifying Alternate Semantics for the
	Explicit Congestion Notification (ECN) Field", BCP 124,		Explicit Congestion Notification (ECN) Field", BCP 124,
	RFC 4774, November 2006.		RFC 4774, November 2006.
	11.2. Informative References		11.2. Informative References
			[PCN-3-enc-state]
			Moncaster, T., Briscoe, B., and M. Menth, "A three state
			extended PCN encoding scheme",
			draft-moncaster-pcn-3-state-encoding-00 (work in
			progress), June 2008.
	[PCN-arch]		[PCN-arch]
	Eardley, P., "Pre-Congestion Notification Architecture",		Eardley, P., "Pre-Congestion Notification Architecture",
	draft-ietf-pcn-architecture-03 (work in progress),		draft-ietf-pcn-architecture-03 (work in progress),
	February 2008.		February 2008.
	[PCN-charter]		[PCN-charter]
	"IETF Charter for Congestion and Pre-Congestion		"IETF Charter for Congestion and Pre-Congestion
	Notification Working Group".		Notification Working Group".
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	skipping to change at page 8, line 33		skipping to change at page 9, line 49
	The rules that govern the behaviour of the ECN field for IP-in-IP		The rules that govern the behaviour of the ECN field for IP-in-IP
	tunnels were defined in [RFC3168]. This allowed for two tunnel modes		tunnels were defined in [RFC3168]. This allowed for two tunnel modes
	to exist. The limited functionality mode sets the outer header to		to exist. The limited functionality mode sets the outer header to
	Not ECT, regardless of the value of the inner header. The full		Not ECT, regardless of the value of the inner header. The full
	functionality mode copies the inner ECN field into the outer header		functionality mode copies the inner ECN field into the outer header
	if the inner header is Not ECT or either of the 2 ECT codepoints. If		if the inner header is Not ECT or either of the 2 ECT codepoints. If
	the inner header is CE then the outer header is set to ECT(0). On		the inner header is CE then the outer header is set to ECT(0). On
	decapsulation, if the CE codepoint is set on the outer header then		decapsulation, if the CE codepoint is set on the outer header then
	this is copied into the inner header. Otherwise the inner header is		this is copied into the inner header. Otherwise the inner header is
	left unchanged. The reason for blocking CE from being copied to the		left unchanged. The apparent reason for blocking CE from being
	outer header was to prevent this from being used as a covert channel		copied to the outer header was to prevent this from being used as a
	through IPSec tunnels.		covert channel through IPSec tunnels.
	The IPSec protocol [RFC4301] changed the ECN tunnelling rule to allow		The IPSec protocol [RFC4301] changed the ECN tunnelling rule to allow
	IPSec tunnels to simply copy the inner header into the outer header.		IPSec tunnels to simply copy the inner header into the outer header.
	This was because the security community had decided the available		On decapsulation the outer header is discarded and the ECN field is
	bandwidth of the covert channel offered by ECN was too low to be a		only copied down if it is set to CE. Because of the possible
	significant threat. On decapsulation the outer header is discarded		existence of tunnels, only CE (11) can be used as a PCN marking as it
	and the ECN field is only copied down if it is set to CE. Because of		is the only mark that will survive decapsulation.
	the possible existence of tunnels, only CE (11) can be used as a PCN
	marking as it is the only mark that will survive decapsulation.
	There is a further issue involving tunnelling. In RFC3168, IP in IP		There is a further issue involving tunnelling. In RFC3168, IP in IP
	tunnels are expected to set the ECN field to ECT(0) if the inner ECN		tunnels are expected to set the ECN field to ECT(0) if the inner ECN
	field is set to CE. This leads to the possibility that some packets		field is set to CE. This leads to the possibility that some packets
	within the PCN field that have already been marked may have that mark		within the PCN field that have already been marked may have that mark
	concealed further into the region. This is undesirable for many PCN		concealed further into the domain. This is undesirable for many PCN
	schemes and thus standard IP in IP tunnels SHOULD NOT be used within		schemes and thus standard IP in IP tunnels SHOULD NOT be used within
	a PCN region.		a PCN-domain.
			Appendix B. Deployment Scenarios for PCN Using Baseline Encoding
			We illustrate the use of PCN baseline encoding for different PCN
			deployment scenarios and explain also a case for which baseline
			encoding is not applicable. {Note this appendix is provided for
			information only}
			1. An operator may wish to use PCN-based admission control only. To
			that end, threshold marking based on admissible rates may be used
			as the only PCN metering and marking algorithm. As a
			consequence, the packet marks M are interpreted as admission-stop
			(AS) marks. The admission-control algorithm is based on
			"admissible-rate overload".
			2. An operator may wish to use PCN-based flow termination only. To
			that end, excess rate marking based on supportable rates may be
			used as the only PCN metering and marking algorithm. As a
			consequence, the packet marks M are interpreted as excess-traffic
			(ET) marks. The flow termination algorithm is based on
			"supportable-rate overload".
			3. An operator may wish to use both PCN-based admission control and
			flow termination. To that end, excess rate marking based on
			admissible rates may be used as the only PCN metering and marking
			algorithm. As a consequence, the packet marks are interpreted as
			admission-stop (AS) marks. Both the admission control and the
			flow termination algorithm are based on "admissible-rate
			overload".
			4. An operator may wish to implement admission control based on
			threshold marking at admissible rates and flow termination based
			on excess rate marking at supportable rates because these methods
			are believed to work better with small ingress-egress aggregates.
			Then two different markings are needed that cannot be recorded by
			the PCN baseline encoding.
	Authors' Addresses		Authors' Addresses
	Toby Moncaster		Toby Moncaster
	BT		BT
	B54/70, Adastral Park		B54/70, Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich IP5 3RE		Ipswich IP5 3RE
	UK		UK
End of changes. 32 change blocks.
	90 lines changed or deleted		195 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/