draft-eardley-pcn-marking-behaviour-00.txt		draft-eardley-pcn-marking-behaviour-01.txt
	PCN Working Group (Editor)		PCN Working Group P. Eardley (Editor)
	Internet-Draft BT		Internet-Draft BT
	Intended status: Standards Track April 29, 2008		Intended status: Standards Track June 25, 2008
	Expires: October 31, 2008		Expires: December 27, 2008
	Marking behaviour of PCN-nodes		Marking behaviour of PCN-nodes
	draft-eardley-pcn-marking-behaviour-00		draft-eardley-pcn-marking-behaviour-01
	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 34		skipping to change at page 1, line 34
	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 October 31, 2008.		This Internet-Draft will expire on December 27, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document standardises the two marking behaviours of PCN-nodes:		This document standardises the two marking behaviours of PCN-nodes:
	threshold marking and excess traffic marking. Threshold marking		threshold marking and excess traffic marking. Threshold marking
	marks all PCN-packets if the PCN traffic rate is greater than a first		marks all PCN-packets if the PCN traffic rate is greater than a first
	skipping to change at page 2, line 14		skipping to change at page 2, line 14
	Requirements Language		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 RFC 2119 [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Specified PCN-marking behaviour . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Specified PCN-marking behaviour . . . . . . . . . . . . . . . 6
	2.2. Classify and condition function . . . . . . . . . . . . . 5		2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.3. Threshold meter function . . . . . . . . . . . . . . . . . 6		2.2. Classify function . . . . . . . . . . . . . . . . . . . . 7
	2.4. Excess traffic meter function . . . . . . . . . . . . . . 6		2.3. Traffic conditioning function . . . . . . . . . . . . . . 7
	2.5. Marking function . . . . . . . . . . . . . . . . . . . . . 7		2.4. Threshold meter function . . . . . . . . . . . . . . . . . 8
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		2.5. Excess traffic meter function . . . . . . . . . . . . . . 8
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		2.6. Marking function . . . . . . . . . . . . . . . . . . . . . 9
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 8		6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.2. Informative References . . . . . . . . . . . . . . . . . . 8		6.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 11
	Appendix A. Example algorithms . . . . . . . . . . . . . . . . . 9		7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	A.1. Threshold metering and marking . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	A.2. Excess traffic metering and marking . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	Appendix B. Implementation notes . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . . 12
	B.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. Example algorithms . . . . . . . . . . . . . . . . . 12
	B.2. Classify and condition . . . . . . . . . . . . . . . . . . 11		A.1. Threshold metering and marking . . . . . . . . . . . . . . 13
	B.3. Threshold metering . . . . . . . . . . . . . . . . . . . . 12		A.2. Excess traffic metering and marking . . . . . . . . . . . 13
	B.4. Excess traffic metering . . . . . . . . . . . . . . . . . 13		Appendix B. Implementation notes . . . . . . . . . . . . . . . . 14
	B.5. Marking . . . . . . . . . . . . . . . . . . . . . . . . . 14		B.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14		B.2. Classify . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 15		B.3. Traffic conditioning . . . . . . . . . . . . . . . . . . . 15
			B.4. Threshold metering . . . . . . . . . . . . . . . . . . . . 16
			B.5. Excess traffic metering . . . . . . . . . . . . . . . . . 17
			B.6. Marking . . . . . . . . . . . . . . . . . . . . . . . . . 18
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
			Intellectual Property and Copyright Statements . . . . . . . . . . 20
	1. Introduction		1. Introduction
	[draft-pcn-architecture] describes a general architecture for flow		[I-D.ietf-pcn-architecture] describes a general architecture for flow
	admission and termination based on pre-congestion information in		admission and termination based on pre-congestion information in
	order to protect the quality of service of established inelastic		order to protect the quality of service of established inelastic
	flows within a single DiffServ domain. The pre-congestion		flows within a single DiffServ domain. The pre-congestion
	information consists of specific markings of PCN-packets. The edge		information consists of specific markings of PCN-packets. The edge
	nodes of the DiffServ domain read these markings and convert them		nodes of the DiffServ domain read these markings and convert them
	into flow admission and termination decisions. Overall the aim is to		into flow admission and termination decisions. Overall the aim is to
	enable PCN-nodes to give an "early warning" of potential congestion		enable PCN-nodes to give an "early warning" of potential congestion
	before there is any significant build-up of PCN-packets in their		before there is any significant build-up of PCN-packets in their
	queues.		queues.
	skipping to change at page 3, line 31		skipping to change at page 3, line 31
	o threshold marking: its objective is to mark all PCN-packets (with		o threshold marking: its objective is to mark all PCN-packets (with
	a "threshold-mark") whenever the rate of PCN-packets is greater		a "threshold-mark") whenever the rate of PCN-packets is greater
	than some configured rate ("PCN-threshold-rate");		than some configured rate ("PCN-threshold-rate");
	o excess traffic marking: whenever the rate of PCN-packets is		o excess traffic marking: whenever the rate of PCN-packets is
	greater than some configured rate ("PCN-excess-rate"), its		greater than some configured rate ("PCN-excess-rate"), its
	objective is to mark PCN-packets (with an "excess-traffic-mark")		objective is to mark PCN-packets (with an "excess-traffic-mark")
	at a rate equal to the difference between the bit rate of PCN-		at a rate equal to the difference between the bit rate of PCN-
	packets and the PCN-excess-rate.		packets and the PCN-excess-rate.
	[draft-pcn-architecture] describes how the admission control		[I-D.ietf-pcn-architecture] describes how the admission control
	mechanism limits the PCN-traffic on each link to *roughly* its PCN-		mechanism limits the PCN-traffic on each link to *roughly* its PCN-
	threshold-rate and how the flow termination mechanism limits the PCN-		threshold-rate and how the flow termination mechanism limits the PCN-
	traffic on each link to *roughly* its PCN-excess-rate.		traffic on each link to *roughly* its PCN-excess-rate.
	Section 2 specifies the functions involved, which in outline are:		Section 2 specifies the functions involved, which in outline (see
			Figure 1) are:
	o Packet classify and condition - decide whether an incoming packet		o Packet classify and condition - decide whether an incoming packet
	belongs to a PCN-flow or not; drop (or downgrade) packets if the		belongs to a PCN-flow or not;
	link is overloaded;
			o Condition: drop or downgrade packets if the link is overloaded;
	o Threshold meter - determine whether the rate of PCN-packets is		o Threshold meter - determine whether the rate of PCN-packets is
	greater than the configured PCN-threshold-rate;		greater than the configured PCN-threshold-rate;
	o Excess traffic meter - measure by how much the rate of PCN-packets		o Excess traffic meter - measure by how much the rate of PCN-packets
	is greater than the configured PCN-excess-rate;		is greater than the configured PCN-excess-rate;
	o Mark - actually mark the PCN-packets, if the meter functions		o Mark - actually mark the PCN-packets, if the meter functions
	indicate to do so;		indicate to do so;
			PCN encoding uses a combination of the DSCP field and ECN field in
	[pcn-encoding] specifies the actual encoding, which uses the DSCP and		the IP header to indicate that a packet is a PCN-packet and whether
	ECN fields. In a particular deployment the operator may have three		it is PCN-marked. [I-D.moncaster-pcn-baseline-encoding] defines two
	encoding states available (so allowing both threshold marking and		encoding states (PCN-marked and not PCN-marked), whilst
	excess traffic marking) or may have only two encoding state, which it		[I-D.draft-moncaster-pcn-3-state-encoding] defines an extended scheme
	may use for either threshold marking or excess traffic marking. This		with three encoding states. So in a particular deployment the
	leads to the following four use cases:		operator may have three encoding states available (so allowing both
			threshold marking and excess traffic marking) or may have only two
			encoding states (so allowing either threshold marking and excess
			traffic marking). As described in [I-D.ietf-pcn-architecture], flow
			termination is based on excess traffic marked packets, whilst
			admission control can be based on either threshold marked or excess
			traffic marked packets (the former is more accurate,
			[I-D.draft-charny-pcn-comparison]). This leads to the following four
			use cases:
	1. an operator requires both admission control and flow termination,		1. an operator requires both admission control and flow termination,
	and has three encoding states available. Then admission control		and has three encoding states available. Then admission control
	is triggered from PCN-packets that are threshold-marked, and flow		is triggered from PCN-packets that are threshold-marked, and flow
	termination from PCN-packets that are excess-traffic-marked		termination from PCN-packets that are excess-traffic-marked.
	[ref].
	2. an operator requires both admission control and flow termination,		2. an operator requires both admission control and flow termination,
	and has only two encoding states available. Then both admission		and has only two encoding states available. Then both admission
	control and flow termination are triggered from PCN-packets that		control and flow termination are triggered from PCN-packets that
	are excess-traffic-marked [ref].		are excess-traffic-marked.
	3. an operator requires only admission control. Then admission		3. an operator requires only admission control. Then admission
	control is triggered from PCN-packets that are threshold-marked		control is triggered from PCN-packets that are threshold-marked
	and only two encoding states are needed.		and only two encoding states are needed. (Flow termination may
			be provided by a non PCN mechanism; this is out of scope.)
	4. an operator requires only flow termination. Then flow		4. an operator requires only flow termination. Then flow
	termination is triggered from PCN-packets that are excess-		termination is triggered from PCN-packets that are excess-
	traffic-marked and only one encoding states are needed.		traffic-marked and only two encoding states are needed.
			(Admission control may be provided by a non PCN mechanism; this
			is out of scope.)
	+---------+ Result		+---------+ Result
	+->|Threshold|-------+		+->|Threshold|-------+
	| | Meter | |		| | Meter | |
	| +---------+ V		| +---------+ V
	+---------+ | +--------+		+---------+ +---------+ | +------+
	|Classify | | | | Marked		| | | | | | | Marked
	Packet ===>| & |==?================>| Marker |===> Packet		Packet =>|Classify |==>|Condition|==?================>|Marker|==> Packet
	Stream |Condition| | | | Stream		Stream | | | | | | | Stream
	+---------+ | +--------+		+---------+ +---------+ | +------+
	| +---------+ ^		| +---------+ ^
	| | Excess | |		| | Excess | |
	+->| Traffic |-------+		+->| Traffic |-------+
	| Meter | Result		| Meter | Result
	+---------+		+---------+
	Figure 1: Schematic of functions for PCN-marking		Figure 1: Schematic of functions for PCN-marking
			1.1. Terminology
			In addition to the terminology defined in [I-D.ietf-pcn-architecture]
			and RFC 2474 [RFC2474], the following terms are defined:
			o PCN-traffic: (defined in [draft-pcn-architecture] but need to
			clarify that PCN-BA is idenitfied by combination of DSCP & ECN
			fields)
			o Other-traffic: traffic that uses the same DS codepoint as PCN-
			traffic, but a different value in the ECN field; has the same
			priority as PCN-traffic (in terms of scheduling at PCN-nodes); but
			is not subject to PCN-marking, nor PCN's admissin control and flow
			termination mechanisms. Thus PCN-traffic and other-traffic have
			different per-domain behaviours RFC 3086 [RFC3086]. Note: there
			may be no other-traffic in a PCN-domain. Note: the term PCN-BA
			does not include other-traffic (this is a clarification, as the
			definition of behaviour aggregate in RFC 2474 [RFC2474], RFC 2475
			[RFC2475] is somewhat ambiguous in the context of PCN.
			o Priority-traffic: traffic that is more important than PCN that
			shares the same capacity as PCN and is priority scheduled over PCN
			(perhaps an operator's control messages). Note: there may be no
			priority-traffic in a PCN-domain.
			o Metered-traffic: the collective term for PCN-traffic and (if any)
			priority-traffic and other-traffic.
			o Downgrade: Re-marking a packet, ie changing its DS codepoint, into
			a lower priority behaviour aggregate, such as best effort or
			assured forwarding; as a consequence perhaps dropping lower
			priority packets.
			o <these new terms are not great, but I couldn't find a way of
			writing the doc without them. I don't think they should be used
			outside this doc (so would be inclined to keep the terms here &
			not in [draft-pcn-architecture]).
	2. Specified PCN-marking behaviour		2. Specified PCN-marking behaviour
			This section specifies the PCN-marking behaviour. The descriptions
			are functional and are not intended to restrict the implementation..
			The Informative Appendixes supplement it.
	2.1. Scope		2.1. Scope
	The functions defined in the following sub-sections SHOULD be		The functions defined in the following sub-sections SHOULD be
	implemented on all links in the PCN-domain.		implemented on all links in the PCN-domain.
	There are three possibilities regarding encoding states:		There are three possibilities regarding encoding states:
	o three encoding states are available,		o three encoding states are available,
	* one for threshold marks,		* one for threshold marks,
	skipping to change at page 5, line 32		skipping to change at page 6, line 44
	* one for threshold marks		* one for threshold marks
	* one for "not PCN-marked";		* one for "not PCN-marked";
	o two encoding states are available,		o two encoding states are available,
	* one for excess rate marks		* one for excess rate marks
	* one for "not PCN-marked".		* one for "not PCN-marked".
	The same choice MUST be used throughout a PCN-domain.		The same choice of encoding states MUST be used throughout a PCN-
			domain.
	The descriptions in the following sub-sections are functional and are		All metered-traffic MUST be metered by the metering functions
	not intended to restrict the implementation.		specified in Sections 2.3, 2.4 and 2.5 (with the minor exception
			noted below in Section 2.5). Priority-traffic and other-traffic MUST
			NOT be PCN-marked (ie only PCN-packets can be PCN-marked).
	2.2. Classify and condition function		2.2. Classify function
	A packet MUST be classified as a PCN-packet if the value of its DSCP		A packet MUST be classified as a PCN-packet if the value of its DSCP
	and ECN fields are as described in [draft-pcn-encoding].		and ECN fields are as standardised in
			[I-D.moncaster-pcn-baseline-encoding] or
			[I-D.draft-moncaster-pcn-3-state-encoding], as applicable to the PCN-
			domain. Otherwise the packet MUST NOT be classified as a PCN-packet.
	There may be traffic that is more important than PCN that shares the		A packet MUST be classified as an other-traffic packet if it uses the
	same capacity as PCN and is priority scheduled over PCN (perhaps an		same DSCP as PCN-traffic, but a different value in the ECN field.
	operator's control messages). Such traffic MUST be metered as though
	it were PCN-traffic, but MUST NOT be PCN-marked. Such packets,
	together with PCN-packets, are called "metered packets".
	Otherwise the packet MUST NOT be classified as a PCN-packet.		A packet MUST be classified as a priority-traffic packet if it shares
			the same capacity as PCN-traffic and other-traffic and is priority
			scheduled over them.
	If the level of traffic is sufficiently high to overload the PCN		2.3. Traffic conditioning function
	behaviour aggregate(s), then traffic MUST be conditioned. The three
	possibilities are:
	o drop PCN-packets;		On all links in the PCN-domain, traffic conditioning MUST be done by:
	o downgrade PCN-packets to a lower priority behaviour aggregate,		o metering all metered-traffic to determine if the level of metered-
	such as best effort or assured forwarding, and perhaps drop lower		traffic is sufficiently high to overload the PCN behaviour
	priority packets;		aggregate(s). (According to RFC 2475 [RFC2475] metering is "the
			process of measuring the temporal properties (eg rate) of a
			traffic stream".
	o drop or downgrade other "metered packets".		o if the level of metered-traffic is sufficiently high, then do one
			or more of the following:
			* drop PCN-packets;
			* downgrade PCN-packets;
			* drop other-packets;
			* downgrade other-packets.
			* <you might argue that other-packets should get harsher
			treatment since they're not subject to PCN's adm & termination
			control, only subject to the weaker DiffServ style static TCAs
			at the PCN-ingress-node>
	If PCN-packets are dropped (or downgraded) then:		If PCN-packets are dropped (or downgraded) then:
	o excess-traffic-marked PCN-packets SHOULD be preferentially dropped		o excess-traffic-marked PCN-packets SHOULD be preferentially dropped
	(downgraded);		(downgraded);
	o PCN-packets that are dropped (downgraded) SHOULD NOT be metered by		o PCN-packets that are dropped (downgraded) SHOULD NOT be metered by
	the Excess traffic Meter.		the Excess traffic Meter.
	2.3. Threshold meter function		In addition, PCN-ingress-nodes MUST police PCN-traffic by:
			o metering PCN-packets that are part of a previously admitted PCN-
			flow, to check that it keeps to the agreed rate or flowspec (eg
			RFC 1633 [RFC1633] for a microflow, and its NSIS equivalent).
			o checking that any packets received that demand PCN treatment do
			indeed belong to a previously admitted flow.
			o dropping or downgrading packets that fail the above checks.
			In addition, PCN-ingress-nodes MUST police other-traffic by:
			o metering other-traffic to check that it meeds its traffic
			conditioning agreement, which is the parameters of the traffic
			that will be accepted from a customer. Typically it is statically
			defined as part of the subscription-time service level agreement,
			as in the DiffServ architecture RFC 2475 [RFC2475]
			o dropping or downgrading packets that fail the above check.
			In addition, an operator MAY measure the amount of traffic entering
			(or leaving) its network for accounting reasons. Consideration is
			out of scope of this document.
			2.4. Threshold meter function
	The Threshold Meter MUST have behaviour that is functionally		The Threshold Meter MUST have behaviour that is functionally
	equivalent to the following.		equivalent to the following.
	The meter is a token bucket, which is sized in bits and has a		The meter acts like a token bucket, which is sized in bits and has a
	configured bit rate, termed PCN-threshold-rate. The amount of tokens		configured bit rate, termed PCN-threshold-rate. The amount of tokens
	in the token bucket is termed TB1.fill. Tokens are added at the PCN-		in the token bucket is termed TB1.fill. Tokens are added at the PCN-
	threshold-rate, to a maximum value TB1.max. Tokens are removed equal		threshold-rate, to a maximum value TB1.max. Tokens are removed equal
	to the size in bits of the metered-packet, to a minimum TB1.fill=0.		to the size in bits of the metered-packet, to a minimum TB1.fill=0.
	The token bucket has a configured token bucket depth (between 0 and		The token bucket has a configured token bucket depth (between 0 and
	TB1.max), termed TB1.threshold. If TB1.fill < TB1.threshold, then		TB1.max), termed TB1.threshold. If TB1.fill < TB1.threshold, then
	the meter indicates to the Marking function that the packet is to be		the meter indicates to the Marking function that the packet is to be
	threshold-marked; otherwise it does not.		threshold-marked; otherwise it does not.
	2.4. Excess traffic meter function		2.5. Excess traffic meter function
	A packet SHOULD NOT be metered (by this excess traffic meter		A packet SHOULD NOT be metered (by this excess traffic meter
	function) in the following two cases:		function) in the following two cases:
	o If the packet is already excess-traffic-marked;		o If the packet is already excess-traffic-marked;
	o If this PCN-node drops (downgrades) the packet because the link is		o If this PCN-node drops (downgrades) the packet because the link is
	overloaded.		overloaded.
	Otherwise it is metered by the Excess traffic Meter.		Otherwise it is metered by the Excess traffic Meter.
	The Excess traffic Meter MUST have behaviour that is functionally		The Excess traffic Meter MUST have behaviour that is functionally
	equivalent to the following.		equivalent to the following.
	The meter is a token bucket, which is sized in bits and has a		The meter acts like a token bucket, which is sized in bits and has a
	configured bit rate, termed PCN-excess-rate. The amount of tokens in		configured bit rate, termed PCN-excess-rate. The amount of tokens in
	the token bucket is termed TB2.fill. Tokens are added at the PCN-		the token bucket is termed TB2.fill. Tokens are added at the PCN-
	excess-rate, to a maximum value TB2.max. Tokens are removed equal to		excess-rate, to a maximum value TB2.max. Tokens are removed equal to
	the size in bits of the metered-packet, to a minimum value of 0. The		the size in bits of the metered-packet, to a minimum TB2-fill=0. The
	PCN-excess-rate is greater than (or equal to) the PCN-threshold-rate.		PCN-excess-rate is greater than (or equal to) the PCN-threshold-rate.
	If the token bucket is empty (TB2.fill = 0), then the meter indicates		If the token bucket is empty (TB2.fill = 0), then the meter indicates
	to the Marking function that the packet is to be excess-traffic-		to the Marking function that the packet is to be excess-traffic-
	marked. If the token bucket is within an MTU of being empty, then		marked. If the token bucket is within an MTU of being empty, then
	the meter SHOULD indicate to the Marking function that the packet is		the meter SHOULD indicate to the Marking function that the packet is
	to be excess-traffic-marked; MTU means the maximum size of PCN-		to be excess-traffic-marked; MTU means the maximum size of PCN-
	packets on the link. Otherwise the meter does not indicate marking.		packets on the link. Otherwise the meter does not indicate marking.
	2.5. Marking function		2.6. Marking function
	If the packet is not a PCN-packet, then it MUST NOT be marked. A		If the packet is not a PCN-packet, then it MUST NOT be marked. A
	PCN-packet MUST be marked to reflect the metering results by setting		PCN-packet MUST be marked to reflect the metering results by setting
	its encoding state appropriately, as specified below. The encoding		its encoding state appropriately, as specified below. The encoding
	states are defined values of the DSCP and ECN fields, as specified in		states are defined values of the DSCP and ECN fields, as specified in
	[pcn-encoding].		the appropriate encoding document,
			[I-D.moncaster-pcn-baseline-encoding] or
			[I-D.draft-moncaster-pcn-3-state-encoding].
	There are three possibilities, depending on how many encoding states		There are three possibilities, depending on how many encoding states
	are available:		are available:
	o if three encoding states are available (one for threshold-marked,		o if three encoding states are available (one for threshold-marked,
	one for excess-traffic-marked and one for "not PCN-marked") then:		one for excess-traffic-marked and one for "not PCN-marked") then:
	* the encoding state of a packet that has already been excess-		* the encoding state of a packet that has already been excess-
	traffic-marked is not altered, whatever the meters indicate;		traffic-marked is not altered, whatever the meters indicate;
	* Otherwise:		* Otherwise:
	+ if both meters indicate marking, then the packet is excess-		+ if both meters indicate marking, then the packet is excess-
	traffic-marked;		traffic-marked;
			+ if the threshold meter indicates marking and the excess
			traffic meter doesn't, then threshold-marking is applied;
	+ if one meter indicates marking and the other doesn't, then		+ if the excess traffic meter indicates marking and the
	that marking is applied;		threshold traffic meter doesn't, then excess-traffic-marking
			is applied;
	+ if neither meter indicates marking, then the packet's		+ if neither meter indicates marking, then the packet's
	encoding state is not altered.		encoding state is not altered.
	o if two encoding states are available (one for threshold-marked and		o if two encoding states are available (one for threshold-marked and
	one for "not PCN-marked") then:		one for "not PCN-marked") then:
	* if the Threshold Meter indicates marking, then the packet is		* if the Threshold Meter indicates marking, then the packet is
	threshold-marked;		threshold-marked;
	* otherwise the packet's encoding state is not altered.		* otherwise the packet's encoding state is not altered.
	o if two encoding states are available (one for excess-traffic-		o if two encoding states are available (one for excess-traffic-
	marked and one for "not PCN-marked") then:		marked and one for "not PCN-marked") then:
	* if the Excess traffic Meter indicates marking, then the packet		* if the Excess traffic Meter indicates marking, then the packet
	is excess-traffic-marked;		is excess-traffic-marked;
	* otherwise the packet's encoding state is not altered.		* otherwise the packet's encoding state is not altered.
	skipping to change at page 8, line 23		skipping to change at page 10, line 39
	3. IANA Considerations		3. IANA Considerations
	This document makes no request of IANA.		This document makes no request of 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.
	4. Security Considerations		4. Security Considerations
	See [draft-pcn-architecture]		See [I-D.ietf-pcn-architecture]
	5. Acknowledgements		5. Acknowledgements
	Michael Menth, Joe Babiarz, Anna Charny reviewed this draft.		Michael Menth, Joe Babiarz, Anna Charny reviewed a preliminary
			version of the -00 draft.
			Thanks to those who've made comments on this draft: Michael Menth,
			Joe Babiarz, Anna Charny, Ruediger Geib, Wei Gengyu, Fortune Huang.
	All the work by many people in the PCN WG.		All the work by many people in the PCN WG.
	6. Authors		6. Changes
			6.1. Changes from -00 to -01
			o Traffic conditioning extensively re-written.
			o New terms defined
			o Changes resulting from split of encoding into two drafts, baseline
			[I-D.moncaster-pcn-baseline-encoding] and extension
			[I-D.draft-moncaster-pcn-3-state-encoding].
			o Minor changes to improve clarity.
			7. Authors
	Many people need to be added.		Many people need to be added.
	7. References		8. References
	7.1. Normative References		8.1. Normative References
			[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
			Services in the Internet Architecture: an Overview",
			RFC 1633, June 1994.
	[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.
	7.2. Informative References		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
			"Definition of the Differentiated Services Field (DS
			Field) in the IPv4 and IPv6 Headers", RFC 2474,
			December 1998.
	[t] "", 2004.		[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
			and W. Weiss, "An Architecture for Differentiated
			Services", RFC 2475, December 1998.
			[RFC3086] Nichols, K. and B. Carpenter, "Definition of
			Differentiated Services Per Domain Behaviors and Rules for
			their Specification", RFC 3086, April 2001.
			8.2. Informative References
			[I-D.draft-briscoe-tsvwg-byte-pkt-mark]
			"Baseline Encoding and Transport of Pre-Congestion
			Information", February 2008, <http://www.ietf.org/
			internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt>.
			[I-D.draft-charny-pcn-comparison]
			"Pre-Congestion Notification Using Single Marking for
			Admission and Termination", November 2007, <http://
			www.watersprings.org/pub/id/
			draft-charny-pcn-comparison-00.txt>.
			[I-D.draft-moncaster-pcn-3-state-encoding]
			"Baseline Encoding and Transport of Pre-Congestion
			Information", June 2008, <http://www.ietf.org/
			internet-drafts/
			draft-moncaster-pcn-3-state-encoding-00.txt>.
			[I-D.ietf-pcn-architecture]
			"Pre-Congestion Notification Architecture", February 2008,
			<http://www.ietf.org/internet-drafts/
			draft-ietf-pcn-architecture-03.txt>.
			[I-D.moncaster-pcn-baseline-encoding]
			"Baseline Encoding and Transport of Pre-Congestion
			Information", June 2008, <http://www.ietf.org/
			internet-drafts/
			draft-moncaster-pcn-baseline-encoding-01.txt>.
			[Menth] "Menth", 2008, <http://www3.informatik.uni-wuerzburg.de/
			staff/menth/Publications/ Menth08-PCN-Comparison.pdf>.
	Appendix A. Example algorithms		Appendix A. Example algorithms
	Note: This Appendix is informative, not normative. It is an example		Note: This Appendix is informative, not normative. It is an example
	of algorithms that implement Section 2 and is based on		of algorithms that implement Section 2 and is based on
	[draft-charny-pcn-comparison] and		[I-D.draft-charny-pcn-comparison] and [Menth].
	[http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/
	Menth08-PCN-Comparison.pdf].
	There is no attempt to optimise the algorithms. It implements the		There is no attempt to optimise the algorithms. It implements the
	metering and marking functions together. It is assumed that three		metering and marking functions together. It is assumed that three
	encoding states are available (one for threshold-marked, one for		encoding states are available (one for threshold-marked, one for
	excess-traffic-marked and one for "not PCN-marked"). It is assumed		excess-traffic-marked and one for "not PCN-marked"). It is assumed
	that all metered-packets are PCN-packets and that the link is never		that all metered-packets are PCN-packets and that the link is never
	overloaded. <example should be added?>		overloaded.
	A.1. Threshold metering and marking		A.1. Threshold metering and marking
	A token bucket with the following parameters:		A token bucket with the following parameters:
	o TB1.PCN-threshold-rate: token rate of token bucket (bits/second)		o TB1.PCN-threshold-rate: token rate of token bucket (bits/second)
	o TB1.max: depth of token bucket (bits)		o TB1.max: depth of token bucket (bits)
	o TB1.threshold: marking threshold of token bucket (bits)		o TB1.threshold: marking threshold of token bucket (bits)
	skipping to change at page 11, line 27		skipping to change at page 15, line 11
	The meter and marker can be implemented on the ingoing or outgoing		The meter and marker can be implemented on the ingoing or outgoing
	interface of a PCN-node. It may be that existing hardware can		interface of a PCN-node. It may be that existing hardware can
	support only one meter and marker per ingoing interface and one per		support only one meter and marker per ingoing interface and one per
	outgoing interface. Then for instance threshold metering and marking		outgoing interface. Then for instance threshold metering and marking
	could be run on all the ingoing interfaces and excess traffic		could be run on all the ingoing interfaces and excess traffic
	metering and marking on all the outgoing interfaces; note that the		metering and marking on all the outgoing interfaces; note that the
	same choice must be made for all the links in a PCN-domain to ensure		same choice must be made for all the links in a PCN-domain to ensure
	that the two metering behaviours are applied exactly once for all the		that the two metering behaviours are applied exactly once for all the
	links.		links.
	Note that even if there is only one encoding state both the meters		Note that even if there are only two encoding states both the meters
	are still implemented, in order to ease compatibility between		are still implemented, in order to ease compatibility between
	equipment and remove a configuration option and associated		equipment and remove a configuration option and associated
	complexity. Although this means that the Marking function ignores		complexity. Although this means that the Marking function ignores
	indications from one of the meters, they might be logged or acted		indications from one of the meters, they might be logged or acted
	upon in some other way, for example by the management system or an		upon in some other way, for example by the management system or an
	explicit signalling protocol; such considerations are out of scope of		explicit signalling protocol; such considerations are out of scope of
	PCN.		PCN.
	B.2. Classify and condition		B.2. Classify
	Traffic that has a higher DiffServ priority than PCN, but shares the		Traffic that has a higher DiffServ priority than PCN, but shares the
	same capacity, is metered as though it were PCN-traffic but cannot be		same capacity, is metered as though it were PCN-traffic but cannot be
	PCN-marked. This means that a meter may indicate a packet is to be		PCN-marked. This means that a meter may indicate a packet is to be
	PCN-marked, but the Marking function knows it cannot be marked. It		PCN-marked, but the Marking function knows it cannot be marked. It
	is left open to the implementation exactly what to do in this case;		is left open to the implementation exactly what to do in this case;
	one simple possibility is to mark the next PCN-packet. Note that		one simple possibility is to mark the next PCN-packet. Note that
	unless the PCN-packets are a large fraction of all the metered-		unless the PCN-packets are a large fraction of all the metered-
	packets then the PCN mechanisms may not work well.		packets then the PCN mechanisms may not work well.
			Similar remarks can be made with respect to other-traffic.
			B.3. Traffic conditioning
			The objective of traffic conditioning is to minimise the queueing
			delay suffered by metered-traffic at a PCN-node, since PCN-traffic
			(and other-traffic) is expected to be inelastic traffic generated by
			real time applications. "Overload" therefore means breaking this
			objective. In practice it would be defined as exceeding a specific
			traffic profile, typically based on a token bucket. If both PCN-
			traffic and other-traffic is present then the details will depend on
			how the router's implementation handles the two sorts of traffic, for
			example it could have:
			o a common traffic conditioner and a common queue for PCN-traffic
			and other-traffic;
			o separate traffic conditioners but a common queue;
			o separate traffic conditioners and separate queues.
			By conditioning traffic to a lower rate than the queue(s) can
			schedule traffic, the number of packets in the queue(s) can be
			minimised.
			The choice of whether to drop or downgrade packets is left to the
			operator. For example, if the traffic is expected to be voice then
			dropping is simple and a small amount of dropping doesn't have much
			audible effect. But the dropping of a video I-frame will lead to a
			significant impact. Downgrading needs to be done carefully to avoid
			re-ordering traffic.
			In [RFC2475] shaping is given as another possible action ("the
			process of delaying packets"). However, this is not suitable here as
			the traffic is expected to come from real time applications.
	Preferential dropping of excess-traffic-marked packets: Section 2.2		Preferential dropping of excess-traffic-marked packets: Section 2.2
	specifies: "If the level of traffic is sufficiently high to overload		specifies: "If the level of metered-traffic is sufficiently high,
	the PCN behaviour aggregate(s), then traffic MUST be conditioned ...		then ... if PCN-packets are dropped (or downgraded) then: excess-
	excess-traffic-marked PCN-packets SHOULD be preferentially dropped		traffic-marked PCN-packets SHOULD be preferentially dropped
	(downgraded)". This avoids over-termination, with the CL/SM edge		(downgraded)". This avoids over-termination, with the CL/SM edge
	behaviour, in the event of multiple bottlenecks in the PCN-domain		behaviour, in the event of multiple bottlenecks in the PCN-domain
	[ref].		[I-D.draft-charny-pcn-comparison].
	Exactly what "preferentially dropped" means is left to the		Exactly what "preferentially dropped" means is left to the
	implementation. It is also left to the implementation what to do if		implementation. It is also left to the implementation what to do if
	there are no excess-traffic-marked PCN-packets available at a		there are no excess-traffic-marked PCN-packets available at a
	particular instant.		particular instant.
	<should we leave it this open or give some options, eg: definitely		<should we leave it this open or give some options, eg: definitely
	drop an excess-traffic-marked packet or drop with a higher		drop an excess-traffic-marked packet or drop with a higher
	probability; or, if there are no excess rate marked PCN-packets		probability; or, if there are no excess rate marked PCN-packets
	available, drop any PCN-packet, drop the next excess-traffic-marked		available, drop any PCN-packet, drop the next excess-traffic-marked
	PCN-packet>		PCN-packet>
	Section 2.2 also specifies: "PCN-packets that are dropped		Section 2.2 also specifies: "PCN-packets that are dropped
	(downgraded) SHOULD NOT be metered by the Excess traffic Meter."		(downgraded) SHOULD NOT be metered by the Excess traffic Meter."
	This avoids over-termination, with the CL/SM edge behaviour, in the		This avoids over-termination, with the CL/SM edge behaviour, in the
	event of multiple bottlenecks [ref].		event of multiple bottlenecks [I-D.draft-charny-pcn-comparison].
			Effectively it means that traffic conditioning should be done before
			the meter functions - which is natural.
	B.3. Threshold metering		B.4. Threshold metering
	The description is in terms of a 'token bucket with threshold',		The description is in terms of a 'token bucket with threshold',
	however the implementation is not standardised. For example, it		however the implementation is not standardised. For example, it
	could equally well be implemented as a virtual queue [ref].		could equally well be implemented as a virtual queue
			[I-D.ietf-pcn-architecture].
	The behaviour must be functionally equivalent to the description		The behaviour must be functionally equivalent to the description
	above. "Functionally equivalent" is intended to allow implementation		above. "Functionally equivalent" is intended to allow implementation
	freedom over matters such as:		freedom over matters such as:
	<is this list helpful? accurate? trying to clarify that there is some		<is this list helpful? accurate? trying to clarify that there is some
	implementation freedom here>		implementation freedom here>
	o whether tokens are added to the token bucket at regular time		o whether tokens are added to the token bucket at regular time
	intervals or only when a packet is processed		intervals or only when a packet is processed
	o whether the new token bucket depth is calculated before or after		o whether the new token bucket depth is calculated before or after
	it is decided whether to mark the packet. The effect of this is		it is decided whether to mark the packet. The effect of this is
	simply to shift the sequence of marks by one packet.		simply to shift the sequence of marks by one packet.
	o when the token bucket is very nearly empty and a packet arrives		o when the token bucket is very nearly empty and a packet arrives
	larger than TB1.fill, then the precise change in TB1.fill is up to		larger than TB1.fill, then the precise change in TB1.fill is up to
	the implementation. Essentially any behaviour is functionally		the implementation. A behaviour is functionally equivalent if
	equivalent if either precisely the same set of packets is marked,		either precisely the same set of packets is marked, or if the set
	or if the set is shifted by one packet. For instance, the		is shifted by one packet. For instance, the following should all
	following should all be considered as "functionally equivalent":		be considered as "functionally equivalent":
	* set TB1.fill = 0 and indicate threshold-mark to the Marking		* set TB1.fill = 0 and indicate threshold-mark to the Marking
	function.		function.
	* check whether TB1.fill < TB1.threshold and if it is then		* check whether TB1.fill < TB1.threshold and if it is then
	indicate threshold-mark to the Marking function; then set		indicate threshold-mark to the Marking function; then set
	TB1.fill = 0.		TB1.fill = 0.
	* leave TB1.fill unaltered and indicate threshold-mark to the		* leave TB1.fill unaltered and indicate threshold-mark to the
	Marking function.		Marking function.
	o similarly, when the token bucket is very nearly full and a packet		o similarly, when the token bucket is very nearly full and a packet
	arrives large than (TB1.max - TB1.fill), then the precise change		arrives large than (TB1.max - TB1.fill), then the precise change
	in TB1.fill is up to the implementation.		in TB1.fill is up to the implementation.
	B.4. Excess traffic metering		o Note that all packets, even if already marked, are metered by the
			threshold meter function (unlike the excess traffic meter function
			- see below) - because all packets should contribute to the
			decision whether there is room for a new flow. The threshold
			meter
			B.5. Excess traffic metering
	The description is in terms of a token bucket, however the		The description is in terms of a token bucket, however the
	implementation is not standardised.		implementation is not standardised.
	As in Section B.3, "functionally equivalent" allows some		As in Section B.3, "functionally equivalent" allows some
	implementation flexibility when the token bucket is very nearly empty		implementation flexibility when the token bucket is very nearly empty
	or very nearly full.		or very nearly full.
	Packet size independent marking is specified as a SHOULD in Section		Packet size independent marking is specified as a SHOULD in Section
	2.4 ( "If the token bucket is within an MTU of being empty, then the		2.4 ( "If the token bucket is within an MTU of being empty, then the
	meter SHOULD indicate to the Marking function that the packet is to		meter SHOULD indicate to the Marking function that the packet is to
	be excess-traffic-marked; MTU means the maximum size of PCN-packets		be excess-traffic-marked; MTU means the maximum size of PCN-packets
	on the link.") Without it, large packets are more likely to be		on the link.") Without it, large packets are more likely to be
	excess-traffic-marked than small packets and this means that, with		excess-traffic-marked than small packets and this means that, with
	some edge behaviours, flows with large packets are more likely to be		some edge behaviours, flows with large packets are more likely to be
	terminated than flows with small packets [refs: http://		terminated than flows with small packets
	www3.informatik.uni-wuerzburg.de/staff/menth/Publications/		[I-D.draft-briscoe-tsvwg-byte-pkt-mark] [Menth].
	Menth08-PCN-MFT.pdf & http://www.ietf.org/internet-drafts/
	draft-briscoe-tsvwg-byte-pkt-mark-02.txt].
	Section 2.4 specifies: "A metered-packet SHOULD NOT be metered (by		Section 2.4 specifies: "A packet SHOULD NOT be metered (by this
	this excess traffic meter function) ... If the packet is already		excess traffic meter function) ... If the packet is already excess-
	excess-traffic-marked". This avoids over-termination (with some edge		traffic-marked". This avoids over-termination (with some edge
	behaviours) in the event that the PCN-traffic passes through multiple		behaviours) in the event that the PCN-traffic passes through multiple
	bottlenecks in the PCN-domain [ref]. Note that an implementation		bottlenecks in the PCN-domain [I-D.draft-charny-pcn-comparison].
	could determine whether the packet is already excess-traffic-marked		Note that an implementation could determine whether the packet is
	as an integral part of its Classification function.		already excess-traffic-marked as an integral part of its
			Classification function.
			Section 2.4 specifies: "A packet SHOULD NOT be metered (by this
			excess traffic meter function) ... If this PCN-node drops
			(downgrades) the packet because the link is overloaded." This avoids
			over-termination [Menth]. (A similar statement could also be made
			for the threshold meter function, but is irrelevant, as a link that
			is overloaded will already be substantially pre-congested and hence
			PCN-marking all packets.)
	Note that TB2.max is independent of TB1.max; TB2.fill is independent		Note that TB2.max is independent of TB1.max; TB2.fill is independent
	of TB1.fill (except in that a packet changes both); and the two		of TB1.fill (except in that a packet changes both); and the two
	configured rates, PCN-excess-rate and PCN-threshold-rate are		configured rates, PCN-excess-rate and PCN-threshold-rate are
	independent (except that PCN-excess-rate >= PCN-threshold-rate).		independent (except that PCN-excess-rate >= PCN-threshold-rate).
	B.5. Marking		B.6. Marking
	Although the metering functions are described separately from the		Although the metering functions are described separately from the
	Marking function, they can be implemented in an integrated fashion.		Marking function, they can be implemented in an integrated fashion.
	[pcn-encoding] specifies the encoding states. In some environments		[I-D.moncaster-pcn-baseline-encoding] specifies two encoding states
	encoding states may be scarce, for example MPLS, and then only one		and [I-D.draft-moncaster-pcn-3-state-encoding] specifies three
	encoding state may be preferable.		encoding states. In some environments encoding states may be scarce,
			for example MPLS, and then only two encoding states may be
			preferable.
	Section 2.5 states: "if three encoding states are available ... if		Section 2.6 states: "if three encoding states are available ... if
	one meter indicates marking and the other doesn't, then that marking		the threshold meter indicates marking and the excess traffic meter
	is applies". Normally this means that the Threshold Meter indicates		doesn't, then threshold-marking is applied; if the excess traffic
	marking and the Excess traffic Meter doesn't. However, the reverse		meter indicates marking and the threshold traffic meter doesn't, then
	is possible for a short time - because the meters react at different		excess-traffic-marking is applied". Normally this means that the
	speeds when the traffic rate changes.		Threshold Meter indicates marking and the Excess traffic Meter
			doesn't. However, the reverse is possible for a short time - because
			the meters react at different speeds when the traffic rate changes.
	Author's Address		Author's Address
	Philip Eardley +++		Philip Eardley +++
	BT		BT
	Adastral Park, Martlesham Heath		Adastral Park, Martlesham Heath
	Ipswich IP5 3RE		Ipswich IP5 3RE
	UK		UK
	Email: philip.eardley@bt.com		Email: philip.eardley@bt.com
End of changes. 62 change blocks.
	125 lines changed or deleted		351 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/