< draft-briscoe-re-pcn-border-cheat-02.txt		draft-briscoe-re-pcn-border-cheat-03.txt >
	PCN Working Group B. Briscoe		PCN Working Group B. Briscoe
	Internet-Draft BT & UCL		Internet-Draft BT
	Intended status: Standards Track September 13, 2008		Intended status: Standards Track October 26, 2009
	Expires: March 17, 2009		Expires: April 29, 2010
	Emulating Border Flow Policing using Re-PCN on Bulk Data		Emulating Border Flow Policing using Re-PCN on Bulk Data
	draft-briscoe-re-pcn-border-cheat-02		draft-briscoe-re-pcn-border-cheat-03
	Status of this Memo		Status of This Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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		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 March 17, 2009.		This Internet-Draft will expire on April 29, 2010.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	Abstract		Abstract
	Scaling per flow admission control to the Internet is a hard problem.		Scaling per flow admission control to the Internet is a hard problem.
	The approach of combining Diffserv and pre-congestion notification		The approach of combining Diffserv and pre-congestion notification
	(PCN) provides a service slightly better than Intserv controlled load		(PCN) provides a service slightly better than Intserv controlled load
	that scales to networks of any size without needing Diffserv's usual		that scales to networks of any size without needing Diffserv's usual
	overprovisioning, but only if domains trust each other to comply with		overprovisioning, but only if domains trust each other to comply with
	admission control and rate policing. This memo claims to solve this		admission control and rate policing. This memo claims to solve this
	trust problem without losing scalability. It provides a sufficient		trust problem without losing scalability. It provides a sufficient
	emulation of per-flow policing at borders but with only passive bulk		emulation of per-flow policing at borders but with only passive bulk
	metering rather than per-flow processing. Measurements are		metering rather than per-flow processing. Measurements are
	sufficient to apply penalties against cheating neighbour networks.		sufficient to apply penalties against cheating neighbour networks.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11		2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11
	3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 11		3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.1. The Traditional Per-flow Policing Problem . . . . . . . . 11		3.1. The Traditional Per-flow Policing Problem . . . . . . . . 11
	3.2. Generic Scenario . . . . . . . . . . . . . . . . . . . . . 14		3.2. Generic Scenario . . . . . . . . . . . . . . . . . . . . . 13
	4. Re-ECN Protocol in IP with Two Congestion Marking Levels . . . 17		4. Re-ECN Protocol in IP with Two Congestion Marking Levels . . . 16
	4.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 17		4.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 16
	4.2. Re-PCN Abstracted Network Layer Wire Protocol (IPv4 or		4.2. Re-PCN Abstracted Network Layer Wire Protocol (IPv4 or
	v6) . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		v6) . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.2.1. Re-ECN Recap . . . . . . . . . . . . . . . . . . . . . 18		4.2.1. Re-ECN Recap . . . . . . . . . . . . . . . . . . . . . 18
	4.2.2. Re-ECN Combined with Pre-Congestion Notification		4.2.2. Re-ECN Combined with Pre-Congestion Notification
	(re-PCN) . . . . . . . . . . . . . . . . . . . . . . . 20		(re-PCN) . . . . . . . . . . . . . . . . . . . . . . . 20
	4.3. Protocol Operation . . . . . . . . . . . . . . . . . . . . 22		4.3. Protocol Operation . . . . . . . . . . . . . . . . . . . . 22
	4.3.1. Protocol Operation for an Established Flow . . . . . . 23		4.3.1. Protocol Operation for an Established Flow . . . . . . 22
	4.3.2. Aggregate Bootstrap . . . . . . . . . . . . . . . . . 24		4.3.2. Aggregate Bootstrap . . . . . . . . . . . . . . . . . 24
	4.3.3. Flow Bootstrap . . . . . . . . . . . . . . . . . . . . 26		4.3.3. Flow Bootstrap . . . . . . . . . . . . . . . . . . . . 25
	4.3.4. Router Forwarding Behaviour . . . . . . . . . . . . . 26		4.3.4. Router Forwarding Behaviour . . . . . . . . . . . . . 26
	4.3.5. Extensions . . . . . . . . . . . . . . . . . . . . . . 28		4.3.5. Extensions . . . . . . . . . . . . . . . . . . . . . . 28
	5. Emulating Border Policing with Re-ECN . . . . . . . . . . . . 28		5. Emulating Border Policing with Re-ECN . . . . . . . . . . . . 28
	5.1. Informal Terminology . . . . . . . . . . . . . . . . . . . 28		5.1. Informal Terminology . . . . . . . . . . . . . . . . . . . 28
	5.2. Policing Overview . . . . . . . . . . . . . . . . . . . . 30		5.2. Policing Overview . . . . . . . . . . . . . . . . . . . . 29
	5.3. Pre-requisite Contractual Arrangements . . . . . . . . . . 31		5.3. Pre-requisite Contractual Arrangements . . . . . . . . . . 31
	5.4. Emulation of Per-Flow Rate Policing: Rationale and		5.4. Emulation of Per-Flow Rate Policing: Rationale and
	Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 34		Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	5.5. Sanctioning Dishonest Marking . . . . . . . . . . . . . . 36		5.5. Sanctioning Dishonest Marking . . . . . . . . . . . . . . 36
	5.6. Border Mechanisms . . . . . . . . . . . . . . . . . . . . 38		5.6. Border Mechanisms . . . . . . . . . . . . . . . . . . . . 37
	5.6.1. Border Accounting Mechanisms . . . . . . . . . . . . . 38		5.6.1. Border Accounting Mechanisms . . . . . . . . . . . . . 37
	5.6.2. Competitive Routing . . . . . . . . . . . . . . . . . 41		5.6.2. Competitive Routing . . . . . . . . . . . . . . . . . 41
	5.6.3. Fail-safes . . . . . . . . . . . . . . . . . . . . . . 42		5.6.3. Fail-safes . . . . . . . . . . . . . . . . . . . . . . 42
	6. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 43		6. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	7. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 46		7. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 45
	8. Design Choices and Rationale . . . . . . . . . . . . . . . . . 47		8. Design Choices and Rationale . . . . . . . . . . . . . . . . . 47
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 49		9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
	11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 50		11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 50
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
	13. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 52		13. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 51
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 52		14.1. Normative References . . . . . . . . . . . . . . . . . . . 51
	14.2. Informative References . . . . . . . . . . . . . . . . . . 53		14.2. Informative References . . . . . . . . . . . . . . . . . . 53
	Appendix A. Implementation . . . . . . . . . . . . . . . . . . . 55		Appendix A. Implementation . . . . . . . . . . . . . . . . . . . 56
	A.1. Ingress Gateway Algorithm for Blanking the RE flag . . . . 55		A.1. Ingress Gateway Algorithm for Blanking the RE flag . . . . 56
	A.2. Downstream Congestion Metering Algorithms . . . . . . . . 56		A.2. Downstream Congestion Metering Algorithms . . . . . . . . 57
	A.2.1. Bulk Downstream Congestion Metering Algorithm . . . . 56		A.2.1. Bulk Downstream Congestion Metering Algorithm . . . . 57
	A.2.2. Inflation Factor for Persistently Negative Flows . . . 56		A.2.2. Inflation Factor for Persistently Negative Flows . . . 58
	A.3. Algorithm for Sanctioning Negative Traffic . . . . . . . . 57		A.3. Algorithm for Sanctioning Negative Traffic . . . . . . . . 58
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 57
	Intellectual Property and Copyright Statements . . . . . . . . . . 59
	Status (to be removed by the RFC Editor)		Status (to be removed by the RFC Editor)
	The IETF PCN working group is initially chartered to consider PCN		The IETF PCN working group is initially chartered to consider PCN
	domains only under a single trust authority. However, after its		domains only under a single trust authority. However, after its
	initial work is complete the charter says the working group may re-		initial work is complete the charter says the working group may re-
	charter to consider concatenated Diffserv domains, amongst other new		charter to consider concatenated Diffserv domains, amongst other new
	work items. The charter ends by stating "The details of these work		work items. The charter ends by stating "The details of these work
	items are outside the scope of the initial phase; but the WG may		items are outside the scope of the initial phase; but the WG may
	consider their requirements to design components that are		consider their requirements to design components that are
	skipping to change at page 5, line 4		skipping to change at page 5, line 4
	track and one for informational status. But until it becomes an item		track and one for informational status. But until it becomes an item
	of IETF working group business the whole proposal has been kept		of IETF working group business the whole proposal has been kept
	together to aid understanding. Only the text of Section 4 of this		together to aid understanding. Only the text of Section 4 of this
	document is intended to be normative (requiring standardisation).		document is intended to be normative (requiring standardisation).
	The rest of the sections are merely informative, describing how a		The rest of the sections are merely informative, describing how a
	system might be built from these protocols by the operators of an		system might be built from these protocols by the operators of an
	internetwork. Note in particular that the policing and monitoring		internetwork. Note in particular that the policing and monitoring
	functions proposed for the trust boundaries between operators would		functions proposed for the trust boundaries between operators would
	not need standardisation by the IETF. They simply represent one		not need standardisation by the IETF. They simply represent one
	possible way that the proposed protocols could be used to extend the		possible way that the proposed protocols could be used to extend the
	PCN architecture [I-D.ietf-pcn-architecture] to span multiple domains		PCN architecture [RFC5559] to span multiple domains without mutual
	without mutual trust between the operators.		trust between the operators.
	Dependencies (to be removed by the RFC Editor)		Dependencies (to be removed by the RFC Editor)
	To realise the system described, this document also depends on other		To realise the system described, this document also depends on other
	documents chartered in the IETF Transport Area progressing along the		documents chartered in the IETF Transport Area progressing along the
	standards track:		standards track:
	o Pre-congestion notification (PCN) marking on interior nodes		o Pre-congestion notification (PCN) marking on interior nodes
	[I-D.eardley-pcn-marking-behaviour], chartered for standardisation		[I-D.ietf-pcn-marking-behaviour], chartered for standardisation in
	in the PCN w-g;		the PCN w-g;
	o The baseline encoding of pre-congestion notification in the IP		o The baseline encoding of pre-congestion notification in the IP
	header [I-D.moncaster-pcn-baseline-encoding], also chartered for		header [I-D.ietf-pcn-baseline-encoding], also chartered for
	standardisation in the PCN w-g;		standardisation in the PCN w-g;
	o Feedback of aggregate PCN measurements by suitably extending the		o Feedback of aggregate PCN measurements by suitably extending the
	admission control signalling protocol (e.g. RSVP extension		admission control signalling protocol (e.g. RSVP extension
	[RSVP-ECN] or NSIS extension [I-D.arumaithurai-nsis-pcn]).		[RSVP-ECN] or NSIS extension [I-D.arumaithurai-nsis-pcn]).
	The baseline encoding makes no new demands on codepoint space in the		The baseline encoding makes no new demands on codepoint space in the
	IP header but provides just two PCN encoding states (not marked and		IP header but provides just two PCN encoding states (not marked and
	marked). The PCN architecture recognises that operators might want		marked). The PCN architecture recognises that operators might want
	PCN marking to trigger two functions (admission control and flow		PCN marking to trigger two functions (admission control and flow
	skipping to change at page 5, line 43		skipping to change at page 5, line 43
	under certain conditions that might be typical. As it seems likely		under certain conditions that might be typical. As it seems likely
	that PCN might need three encoding states to be fully operational, we		that PCN might need three encoding states to be fully operational, we
	want to be sure that three encoding states can be extended to work		want to be sure that three encoding states can be extended to work
	inter-domain. Therefore, we have defined a three-state extension		inter-domain. Therefore, we have defined a three-state extension
	encoding scheme in this document, then we have added the re-PCN		encoding scheme in this document, then we have added the re-PCN
	scheme to it. The three-state encoding we have chosen depends on		scheme to it. The three-state encoding we have chosen depends on
	standardisation of yet another document in the IETF Transport Area:		standardisation of yet another document in the IETF Transport Area:
	o Propagation beyond the tunnel decapsulator of any changes in the		o Propagation beyond the tunnel decapsulator of any changes in the
	ECN field to ECT(0) or ECT(1) made within a tunnel (the ideal		ECN field to ECT(0) or ECT(1) made within a tunnel (the ideal
	decapsulation rules of [I-D.briscoe-tsvwg-ecn-tunnel]);		decapsulation rules of [I-D.ietf-tsvwg-ecn-tunnel]);
	Changes from previous drafts (to be removed by the RFC Editor)		Changes from previous drafts (to be removed by the RFC Editor)
	Full diffs of incremental changes between drafts are available at		Full diffs of incremental changes between drafts are available at
	URL: <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#repcn>		URL: <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#repcn>
			Changes from <draft-briscoe-re-pcn-border-cheat-02> to
			<draft-briscoe-re-pcn-border-cheat-03> (current version): Updated
			references and other minor changes.
	Changes from <draft-briscoe-re-pcn-border-cheat-01> to		Changes from <draft-briscoe-re-pcn-border-cheat-01> to
	<draft-briscoe-re-pcn-border-cheat-02> (current version):		<draft-briscoe-re-pcn-border-cheat-02>:
	Considerably updated the 'Status' note to explain the		Considerably updated the 'Status' note to explain the
	relationship of this draft to other documents in the IETF		relationship of this draft to other documents in the IETF
	process (or not) and to chartered PCN w-g activity.		process (or not) and to chartered PCN w-g activity.
	Split out the dependencies into a separate note and added		Split out the dependencies into a separate note and added
	dependencies on new PCN documents in progress.		dependencies on new PCN documents in progress.
	Made scalability motivation in the introduction clearer,		Made scalability motivation in the introduction clearer,
	explaining why Diffserv over-provisioning doesn't scale unless		explaining why Diffserv over-provisioning doesn't scale unless
	skipping to change at page 8, line 37		skipping to change at page 8, line 37
	for resilience to newly identified attacks.		for resilience to newly identified attacks.
	1. Introduction		1. Introduction
	The Internet community largely lost interest in the Intserv		The Internet community largely lost interest in the Intserv
	architecture after it was clarified that it would be unlikely to		architecture after it was clarified that it would be unlikely to
	scale to the whole Internet [RFC2208]. Although Intserv mechanisms		scale to the whole Internet [RFC2208]. Although Intserv mechanisms
	proved impractical, the bandwidth reservation service it aimed to		proved impractical, the bandwidth reservation service it aimed to
	offer is still very much required.		offer is still very much required.
	A recently proposed approach [I-D.ietf-pcn-architecture] combines		A recently proposed approach [RFC5559] combines Diffserv and pre-
	Diffserv and pre-congestion notification (PCN) to provide a service		congestion notification (PCN) to provide a service slightly better
	slightly better than Intserv controlled load [RFC2211]. PCN does not		than Intserv controlled load [RFC2211]. PCN does not require the
	require the considerable over-provisioning that is normally required		considerable over-provisioning that is normally required for
	for admission control over Diffserv [RFC2998] to be robust against		admission control over Diffserv [RFC2998] to be robust against re-
	re-routes or variation in the traffic matrix. It has been proved		routes or variation in the traffic matrix. It has been proved that
	that Diffserv's over-provisioning requirement grows linearly with the		Diffserv's over-provisioning requirement grows linearly with the
	network diameter in hops [QoS_scale].		network diameter in hops [QoS_scale].
	A number of PCN domains can be concatenated into a larger PCN region		A number of PCN domains can be concatenated into a larger PCN region
	without any per-flow processing between them, but only if each domain		without any per-flow processing between them, but only if each domain
	trusts the ingress network to have checked that upstream customers		trusts the ingress network to have checked that upstream customers
	aren't taking more bandwidth than they reserved, either accidentally		aren't taking more bandwidth than they reserved, either accidentally
	or deliberately. Unfortunately, networks can gain considerably by		or deliberately. Unfortunately, networks can gain considerably by
	breaking this trust. One way for a network to protect itself against		breaking this trust. One way for a network to protect itself against
	others is to handle flow signalling at its own border and police		others is to handle flow signalling at its own border and police
	traffic against reservations itself. However, this reintroduces the		traffic against reservations itself. However, this reintroduces the
	skipping to change at page 9, line 29		skipping to change at page 9, line 28
	least proportionate to the severity of the cheat. Re-PCN neither		least proportionate to the severity of the cheat. Re-PCN neither
	requires the unscalable over-provisioning of Diffserv nor the per-		requires the unscalable over-provisioning of Diffserv nor the per-
	flow processing at borders of Intserv over Diffserv.		flow processing at borders of Intserv over Diffserv.
	It should therefore scale controlled load service to the whole		It should therefore scale controlled load service to the whole
	internetwork without the cost of Diffserv's linearly increasing over-		internetwork without the cost of Diffserv's linearly increasing over-
	provisioning, or the cost of per-flow policing at each border. To		provisioning, or the cost of per-flow policing at each border. To
	achieve such scaling, this memo combines two recent proposals, both		achieve such scaling, this memo combines two recent proposals, both
	of which it briefly recaps:		of which it briefly recaps:
	o The pre-congestion notification (PCN)		o The pre-congestion notification (PCN) architecture[RFC5559]
	architecture[I-D.ietf-pcn-architecture] describes how bulk pre-		describes how bulk pre-congestion notification on routers within
	congestion notification on routers within an edge-to-edge Diffserv		an edge-to-edge Diffserv region can emulate the precision of per-
	region can emulate the precision of per-flow admission control to		flow admission control to provide controlled load service without
	provide controlled load service without unscalable per-flow		unscalable per-flow processing;
	processing;
	o Re-ECN: Adding Accountability to TCP/		o Re-ECN: Adding Accountability to TCP/
	IP [I-D.briscoe-tsvwg-re-ecn-tcp].		IP [I-D.briscoe-tsvwg-re-ecn-tcp].
	We coin the term re-PCN for the combination of PCN and re-ECN.		We coin the term re-PCN for the combination of PCN and re-ECN.
	The trick that addresses cheating at borders is to recognise that		The trick that addresses cheating at borders is to recognise that
	border policing is mainly necessary because cheating upstream		border policing is mainly necessary because cheating upstream
	networks will admit traffic when they shouldn't only as long as they		networks will admit traffic when they shouldn't only as long as they
	don't directly experience the downstream congestion their		don't directly experience the downstream congestion their
	skipping to change at page 15, line 7		skipping to change at page 14, line 47
	'C', as well as the inward facing interfaces of the ingress and		'C', as well as the inward facing interfaces of the ingress and
	egress gateways. An ingress and egress border router (BR) is shown		egress gateways. An ingress and egress border router (BR) is shown
	interconnecting each interior domain with the next. There will		interconnecting each interior domain with the next. There will
	typically be other interior routers (not shown) within each interior		typically be other interior routers (not shown) within each interior
	domain.		domain.
	In two paragraphs we now briefly recap how pre-congestion		In two paragraphs we now briefly recap how pre-congestion
	notification is intended to be used to control flow admission to a		notification is intended to be used to control flow admission to a
	large Diffserv region. The first paragraph describes data plane		large Diffserv region. The first paragraph describes data plane
	functions and the second describes signalling in the control plane.		functions and the second describes signalling in the control plane.
	We omit many details from [I-D.ietf-pcn-architecture] including		We omit many details from [RFC5559] including behaviour during
	behaviour during routing changes. For brevity here we assume other		routing changes. For brevity here we assume other flows are already
	flows are already in progress across a path through the Diffserv		in progress across a path through the Diffserv region before a new
	region before a new one arrives, but how bootstrap works is described		one arrives, but how bootstrap works is described in Section 4.3.2.
	in Section 4.3.2.
	Figure 1 shows a single simplex reserved flow from the sending (Sx)		Figure 1 shows a single simplex reserved flow from the sending (Sx)
	end host to the receiving (Rx) end host. The ingress gateway polices		end host to the receiving (Rx) end host. The ingress gateway polices
	incoming traffic and colours conforming traffic within an admitted		incoming traffic and colours conforming traffic within an admitted
	reservation to a combination of Diffserv codepoint and ECN field that		reservation to a combination of Diffserv codepoint and ECN field that
	defines the traffic as 'PCN-enabled'. This redefines the meaning of		defines the traffic as 'PCN-enabled'. This redefines the meaning of
	the ECN field as a PCN field, which is largely the same as ECN		the ECN field as a PCN field, which is largely the same as ECN
	[RFC3168], but with slightly different semantics defined in		[RFC3168], but with slightly different semantics defined in
	[I-D.moncaster-pcn-baseline-encoding] (or various extensions that are		[I-D.ietf-pcn-baseline-encoding] (or various extensions that are
	currently experimental). The Diffserv region is called a PCN-region		currently experimental). The Diffserv region is called a PCN-region
	because all the queues within it are PCN-enabled. This means the		because all the queues within it are PCN-enabled. This means the
	per-hop behaviour they apply to PCN-enabled traffic consists of both		per-hop behaviour they apply to PCN-enabled traffic consists of both
	a scheduling behaviour and a new ECN marking behaviour that we call		a scheduling behaviour and a new ECN marking behaviour that we call
	`pre-congestion notification' [I-D.eardley-pcn-marking-behaviour]. A		`pre-congestion notification' [I-D.ietf-pcn-marking-behaviour]. A
	PCN-enabled queue typically re-uses the definition of expedited		PCN-enabled queue typically re-uses the definition of expedited
	forwarding (EF) [RFC3246] for its scheduling behaviour. The new		forwarding (EF) [RFC3246] for its scheduling behaviour. The new
	congestion marking behaviour sets the PCN field of an increasing		congestion marking behaviour sets the PCN field of an increasing
	proportion of PCN packets to the PCN-marked (PM) codepoint		proportion of PCN packets to the PCN-marked (PM) codepoint
	[I-D.moncaster-pcn-baseline-encoding] as their load approaches a		[I-D.ietf-pcn-baseline-encoding] as their load approaches a threshold
	threshold rate that is lower than the line rate		rate that is lower than the line rate
	[I-D.eardley-pcn-marking-behaviour]. This can be achieved with an		[I-D.ietf-pcn-marking-behaviour]. This can be achieved with an
	algorithm similar to a token-bucket called a virtual queue. The aim		algorithm similar to a token-bucket called a virtual queue. The aim
	is for a queue to start marking PCN traffic to trigger admission		is for a queue to start marking PCN traffic to trigger admission
	control before the real queue builds up any congestion delay. The		control before the real queue builds up any congestion delay. The
	level of a queue's pre-congestion marking is detected at the egress		level of a queue's pre-congestion marking is detected at the egress
	of the Diffserv region and used by the signalling system to control		of the Diffserv region and used by the signalling system to control
	admission of further traffic that would otherwise overload that		admission of further traffic that would otherwise overload that
	queue, as follows.		queue, as follows.
	The end-to-end QoS signalling for a new reservation (to be concrete		The end-to-end QoS signalling for a new reservation (to be concrete
	we will use RSVP) takes one giant hop from ingress to egress gateway,		we will use RSVP) takes one giant hop from ingress to egress gateway,
	skipping to change at page 17, line 15		skipping to change at page 17, line 6
	routers_--where scalability is most critical.		routers_--where scalability is most critical.
	4. Re-ECN Protocol in IP with Two Congestion Marking Levels		4. Re-ECN Protocol in IP with Two Congestion Marking Levels
	4.1. Protocol Overview		4.1. Protocol Overview
	First we need to recap the way routers accumulate PCN congestion		First we need to recap the way routers accumulate PCN congestion
	marking along a path (it accumulates the same way as ECN). Each PCN-		marking along a path (it accumulates the same way as ECN). Each PCN-
	capable queue into a link might mark some packets with a PCN-marked		capable queue into a link might mark some packets with a PCN-marked
	(PM) codepoint, the marking probability increasing with the length of		(PM) codepoint, the marking probability increasing with the length of
	the queue [I-D.eardley-pcn-marking-behaviour]. With a series of PCN-		the queue [I-D.ietf-pcn-marking-behaviour]. With a series of PCN-
	capable routers on a path, a stream of packets accumulates the		capable routers on a path, a stream of packets accumulates the
	fraction of PCN markings that each queue adds. The combined effect		fraction of PCN markings that each queue adds. The combined effect
	of the packet marking of all the queues along the path signals		of the packet marking of all the queues along the path signals
	congestion of the whole path to the receiver. So, for example, if		congestion of the whole path to the receiver. So, for example, if
	one queue early in a path is marking 1% of packets and another later		one queue early in a path is marking 1% of packets and another later
	in a path is marking 2%, flows that pass through both queues will		in a path is marking 2%, flows that pass through both queues will
	experience approximately 3% marking over a sequence of packets.		experience approximately 3% marking over a sequence of packets.
	(Note: Whenever the word 'congestion' is used in this document it		(Note: Whenever the word 'congestion' is used in this document it
	should be taken to mean congestion of the virtual resource assigned		should be taken to mean congestion of the virtual resource assigned
	skipping to change at page 20, line 41		skipping to change at page 20, line 14
	4.2.2. Re-ECN Combined with Pre-Congestion Notification (re-PCN)		4.2.2. Re-ECN Combined with Pre-Congestion Notification (re-PCN)
	As permitted by the ECN specification [RFC3168] and by the guidelines		As permitted by the ECN specification [RFC3168] and by the guidelines
	for specifying alternative semantics for the ECN field [RFC4774], a		for specifying alternative semantics for the ECN field [RFC4774], a
	proposal is currently being advanced in the IETF to define different		proposal is currently being advanced in the IETF to define different
	semantics for how queues might mark the ECN field of certain packets.		semantics for how queues might mark the ECN field of certain packets.
	The idea is to be able to notify congestion when the queue's load		The idea is to be able to notify congestion when the queue's load
	approaches a logical limit, rather than the physical limit of the		approaches a logical limit, rather than the physical limit of the
	line. This new marking is called pre-congestion		line. This new marking is called pre-congestion
	notification [I-D.eardley-pcn-marking-behaviour] and we will use the		notification [I-D.ietf-pcn-marking-behaviour] and we will use the
	term PCN-enabled queue for a queue that can apply pre-congestion		term PCN-enabled queue for a queue that can apply pre-congestion
	notification marking to the ECN fields of packets.		notification marking to the ECN fields of packets.
	[RFC3168] recommends that a packet's Diffserv codepoint should		[RFC3168] recommends that a packet's Diffserv codepoint should
	determine which type of ECN marking it receives. A PCN-capable		determine which type of ECN marking it receives. A PCN-capable
	packet must meet two conditions; it must carry a DSCP that has been		packet must meet two conditions; it must carry a DSCP that has been
	associated with PCN marking and it must carry an ECN field that turns		associated with PCN marking and it must carry an ECN field that turns
	on PCN marking.		on PCN marking.
	As an example, a packet carrying the VOICE-ADMIT		As an example, a packet carrying the VOICE-ADMIT
	[I-D.ietf-tsvwg-admitted-realtime-dscp] DSCP would be associated with		[I-D.ietf-tsvwg-admitted-realtime-dscp] DSCP would be associated with
	expedited forwarding [RFC3246] as its scheduling behaviour and pre-		expedited forwarding [RFC3246] as its scheduling behaviour and pre-
	congestion notification as its congestion marking behaviour. PCN		congestion notification as its congestion marking behaviour. PCN
	would only be turned on within a PCN-region by an ECN codepoint other		would only be turned on within a PCN-region by an ECN codepoint other
	than Not-ECT (00). Then we would describe packets with the VOICE-		than Not-ECT (00). Then we would describe packets with the VOICE-
	ADMIT DSCP and with ECN turned on as PCN-capable packets.		ADMIT DSCP and with ECN turned on as PCN-capable packets.
	[I-D.eardley-pcn-marking-behaviour] actually proposes that two		[I-D.ietf-pcn-marking-behaviour] actually proposes that two logical
	logical limits can be used for pre-congestion notification, with the		limits can be used for pre-congestion notification, with the higher
	higher limit as a back-stop for dealing with anomalous events. It		limit as a back-stop for dealing with anomalous events. It envisages
	envisages PCN will be used to admission control inelastic real-time		PCN will be used to admission control inelastic real-time traffic, so
	traffic, so marking at the lower limit will trigger admission		marking at the lower limit will trigger admission control, while at
	control, while at the higher limit it will trigger flow termination.		the higher limit it will trigger flow termination.
	Because it needs two types of congestion marking, PCN needs four		Because it needs two types of congestion marking, PCN needs four
	states: Not PCN-capable (Not-PCN), PCN-capable but not PCN-marked		states: Not PCN-capable (Not-PCN), PCN-capable but not PCN-marked
	(NM), Admission Marked (AM) and Flow Termination Marked (TM). A		(NM), Admission Marked (AM) and Flow Termination Marked (TM). A
	proposed encoding of the four required PCN states is shown on the		proposed encoding of the four required PCN states is shown on the
	left of Table 2. Note that these codepoints of the ECN field only		left of Table 2. Note that these codepoints of the ECN field only
	take on the semantics of pre-congestion notification if they are		take on the semantics of pre-congestion notification if they are
	combined with a Diffserv codepoint that the operator has configured		combined with a Diffserv codepoint that the operator has configured
	to be associated with PCN marking.		to be associated with PCN marking.
	This encoding only correctly traverses an IP in IP tunnel if the		This encoding only correctly traverses an IP in IP tunnel if the
	ideal decapsulation rules in [I-D.briscoe-tsvwg-ecn-tunnel] are		ideal decapsulation rules in [I-D.ietf-tsvwg-ecn-tunnel] are followed
	followed when combining the ECN fields of the outer and inner		when combining the ECN fields of the outer and inner headers. If
	headers. If instead the decapsulation rules in [RFC3168] or		instead the decapsulation rules in [RFC3168] or [RFC4301] are
	[RFC4301] are followed, any admission marking applied to an outer		followed, any admission marking applied to an outer header will be
	header will be incorrectly removed on decapsulation at the tunnel		incorrectly removed on decapsulation at the tunnel egress.
	egress.
	The RFC3168 ECN field includes space for the experimental ECN		The RFC3168 ECN field includes space for the experimental ECN
	Nonce [RFC3540], which seems to require a fifth state if it is also		Nonce [RFC3540], which seems to require a fifth state if it is also
	needed with re-PCN. But re-PCN supersedes any need for the Nonce		needed with re-PCN. But re-PCN supersedes any need for the Nonce
	within the PCN-region. The ECN Nonce is an elegant scheme, but it		within the PCN-region. The ECN Nonce is an elegant scheme, but it
	only allows a sending node (or its proxy) to detect suppression of		only allows a sending node (or its proxy) to detect suppression of
	congestion marking in the feedback loop. Thus the Nonce requires the		congestion marking in the feedback loop. Thus the Nonce requires the
	sender (or in our case the PCN ingress) to be trusted to respond		sender (or in our case the PCN ingress) to be trusted to respond
	correctly to congestion. But this is precisely the main cheat we		correctly to congestion. But this is precisely the main cheat we
	want to protect against (as well as many others). Also, the ECN		want to protect against (as well as many others). Also, the ECN
	nonce only works once the receiver has placed packets in the same		nonce only works once the receiver has placed packets in the same
	order as they left the ingress, which cannot be done by an edge node		order as they left the ingress, which cannot be done by an edge node
	without adding unnecessary edge-edge packet ordering. Nonetheless,		without adding unnecessary edge-edge packet ordering. Nonetheless,
	if the ECN nonce were in use outside the PCN region (end-to-end), the		if the ECN nonce were in use outside the PCN region (end-to-end), the
	ingress would have to tunnel the arriving IP header across the PCN		ingress would have to tunnel the arriving IP header across the PCN
	region ([I-D.ietf-pcn-architecture]).		region ([RFC5559]).
	For the rest of this memo, to mean either Admission Marking or		For the rest of this memo, to mean either Admission Marking or
	Termination Marking we will call both "congestion marking" or "PCN		Termination Marking we will call both "congestion marking" or "PCN
	marking" unless we need to be specific. With the above encoding,		marking" unless we need to be specific. With the above encoding,
	congestion marking can be read to mean any packet with the right-most		congestion marking can be read to mean any packet with the right-most
	bit of the ECN field set.		bit of the ECN field set.
	The re-ECN protocol can be used to control misbehaving sources		The re-ECN protocol can be used to control misbehaving sources
	whether congestion is with respect to a logical threshold (PCN) or		whether congestion is with respect to a logical threshold (PCN) or
	the physical line rate (ECN). In either case the RE flag can be used		the physical line rate (ECN). In either case the RE flag can be used
	skipping to change at page 25, line 7		skipping to change at page 24, line 42
	4.3.2. Aggregate Bootstrap		4.3.2. Aggregate Bootstrap
	When a new reservation PATH message arrives at the egress, if there		When a new reservation PATH message arrives at the egress, if there
	are currently no flows in progress from the same ingress, there will		are currently no flows in progress from the same ingress, there will
	be no state maintaining the current level of pre-congestion marking		be no state maintaining the current level of pre-congestion marking
	for the aggregate. In the case of RSVP reservation signalling, while		for the aggregate. In the case of RSVP reservation signalling, while
	the signal continues onward towards the receiving host, the egress		the signal continues onward towards the receiving host, the egress
	gateway can return an RSVP message to the ingress with a		gateway can return an RSVP message to the ingress with a
	flag [RSVP-ECN] asking the ingress to send a specified number of data		flag [RSVP-ECN] asking the ingress to send a specified number of data
	probes between them. The more general possibilities for bootstrap		probes between them. The more general possibilities for bootstrap
	behaviour are described in the PCN		behaviour are described in the PCN architecture [RFC5559], including
	architecture [I-D.ietf-pcn-architecture], including using the		using the reservation signal itself as a probe.
	reservation signal itself as a probe.
	However, with our new re-PCN scheme, the ingress does not know what		However, with our new re-PCN scheme, the ingress does not know what
	proportion of the data probes should have the RE flag blanked,		proportion of the data probes should have the RE flag blanked,
	because it has no estimate yet of pre-congestion for the path across		because it has no estimate yet of pre-congestion for the path across
	the PCN-region.		the PCN-region.
	To be conservative, following the guidance for specifying other re-		To be conservative, following the guidance for specifying other re-
	ECN transports in [I-D.briscoe-tsvwg-re-ecn-tcp], the ingress SHOULD		ECN transports in [I-D.briscoe-tsvwg-re-ecn-tcp], the ingress SHOULD
	set the FNE codepoint of the extended PCN header in all probe packets		set the FNE codepoint of the extended PCN header in all probe packets
	(Table 2). As per the PCN deployment model, the egress gateway		(Table 2). As per the PCN deployment model, the egress gateway
	skipping to change at page 27, line 38		skipping to change at page 27, line 17
	understand drop, not congestion marking. But a PCN-capable router		understand drop, not congestion marking. But a PCN-capable router
	can mark rather than drop an FNE packet, even though its ECN field		can mark rather than drop an FNE packet, even though its ECN field
	when looked at in isolation is '00' which appears to be a legacy		when looked at in isolation is '00' which appears to be a legacy
	Not-ECT packet. Therefore, if a packet's RE flag is '1', even if		Not-ECT packet. Therefore, if a packet's RE flag is '1', even if
	its ECN field is '00', a PCN-enabled router SHOULD use congestion		its ECN field is '00', a PCN-enabled router SHOULD use congestion
	marking. This allows the `feedback not established' (FNE)		marking. This allows the `feedback not established' (FNE)
	codepoint to be used for probe packets, in order to pick up PCN		codepoint to be used for probe packets, in order to pick up PCN
	marking when bootstrapping an aggregate.		marking when bootstrapping an aggregate.
	PCN marking rather than dropping of FNE packets MUST only be		PCN marking rather than dropping of FNE packets MUST only be
	deployed in controlled environments, such as that in		deployed in controlled environments, such as that in [RFC5559],
	[I-D.ietf-pcn-architecture], where the presence of an egress node		where the presence of an egress node that understands PCN marking
	that understands PCN marking is assured. Congestion events might		is assured. Congestion events might otherwise be ignored if the
	otherwise be ignored if the receiver only understands drop, rather		receiver only understands drop, rather than PCN marking. This is
	than PCN marking. This is because there is no guarantee that PCN		because there is no guarantee that PCN capability has been
	capability has been negotiated if feedback is not established		negotiated if feedback is not established (FNE). Also,
	(FNE). Also, [I-D.briscoe-tsvwg-re-ecn-tcp] places the strong		[I-D.briscoe-tsvwg-re-ecn-tcp] places the strong condition that a
	condition that a router MUST apply drop rather than marking to FNE		router MUST apply drop rather than marking to FNE packets unless
	packets unless it can guarantee that FNE packets are rate limited		it can guarantee that FNE packets are rate limited either locally
	either locally or upstream.		or upstream.
	+---------+-------+-----------------+---------+---------------------+		+---------+-------+-----------------+---------+---------------------+
	| PCN | RE | Extended PCN | Drop | Re-PCN meaning |		| PCN | RE | Extended PCN | Drop | Re-PCN meaning |
	| field | flag | codepoint | Pref | |		| field | flag | codepoint | Pref | |
	+---------+-------+-----------------+---------+---------------------+		+---------+-------+-----------------+---------+---------------------+
	| 10 | 0 | Re-PCT-Echo | 5/4 | Re-echoed |		| 10 | 0 | Re-PCT-Echo | 5/4 | Re-echoed |
	| | | | | congestion and |		| | | | | congestion and |
	| | | | | Re-PCT |		| | | | | Re-PCT |
	| 00 | 1 | FNE | 4 | Feedback not |		| 00 | 1 | FNE | 4 | Feedback not |
	| | | | | established |		| | | | | established |
	skipping to change at page 50, line 47		skipping to change at page 50, line 27
	10. IANA Considerations		10. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	11. Conclusions		11. Conclusions
	This memo solves the classic problem of making flow admission control		This memo solves the classic problem of making flow admission control
	scale to any size network. It builds on a technique, called PCN,		scale to any size network. It builds on a technique, called PCN,
	which involves the use of Diffserv in a domain and uses pre-		which involves the use of Diffserv in a domain and uses pre-
	congestion notification feedback to control admission into each		congestion notification feedback to control admission into each
	network path across the domain [I-D.ietf-pcn-architecture].		network path across the domain [RFC5559].
	Without PCN, Diffserv requires over-provisioning that must grow		Without PCN, Diffserv requires over-provisioning that must grow
	linearly with network diameter to cater for variation in the traffic		linearly with network diameter to cater for variation in the traffic
	matrix. However, even with PCN, multiple network domains can only		matrix. However, even with PCN, multiple network domains can only
	join together into one larger PCN region if all domains trust each		join together into one larger PCN region if all domains trust each
	other to comply with the protocols, invoking admission control and		other to comply with the protocols, invoking admission control and
	flow termination when requested. Domains could join together and		flow termination when requested. Domains could join together and
	still police flows at their borders by requiring reservation		still police flows at their borders by requiring reservation
	signalling to touch each border and only use PCN internally to each		signalling to touch each border and only use PCN internally to each
	domain. But the per-flow processing at borders would still limit		domain. But the per-flow processing at borders would still limit
	skipping to change at page 52, line 22		skipping to change at page 51, line 47
	13. Comments Solicited		13. 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 Congestion and Pre-Congestion Notification		addressed to the IETF Congestion and Pre-Congestion Notification
	working group's mailing list <pcn@ietf.org>, and/or to the author(s).		working group's mailing list <pcn@ietf.org>, and/or to the author(s).
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[I-D.briscoe-tsvwg-ecn-tunnel]		[I-D.briscoe-tsvwg-re-ecn-tcp] Briscoe, B., Jacquet, A.,
	Briscoe, B., "Layered Encapsulation of Congestion		Moncaster, T., and A. Smith,
	Notification", draft-briscoe-tsvwg-ecn-tunnel-01 (work in		"Re-ECN: Adding
	progress), July 2008.		Accountability for Causing
			Congestion to TCP/IP", draft
			-briscoe-tsvwg-re-ecn-tcp-08
			(work in progress),
			September 2009.
	[I-D.briscoe-tsvwg-re-ecn-tcp]		[I-D.ietf-pcn-baseline-encoding] Moncaster, T., Briscoe, B.,
	Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith,		and M. Menth, "Baseline
	"Re-ECN: Adding Accountability for Causing Congestion to		Encoding and Transport of
	TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-06 (work in		Pre-Congestion Information",
	progress), August 2008.		draft-ietf-pcn-baseline-
			encoding-07 (work in
			progress), September 2009.
	[I-D.eardley-pcn-marking-behaviour]		[I-D.ietf-pcn-marking-behaviour] Eardley, P., "Metering and
	Eardley, P., "Marking behaviour of PCN-nodes",		marking behaviour of PCN-
	draft-eardley-pcn-marking-behaviour-01 (work in progress),		nodes", draft-ietf-pcn-
	June 2008.		marking-behaviour-05 (work
			in progress), August 2009.
	[I-D.moncaster-pcn-baseline-encoding]		[I-D.ietf-tsvwg-ecn-tunnel] Briscoe, B., "Tunnelling of
	Moncaster, T., Briscoe, B., and M. Menth, "Baseline		Explicit Congestion
	Encoding and Transport of Pre-Congestion Information",		Notification", draft-ietf-
	draft-moncaster-pcn-baseline-encoding-02 (work in		tsvwg-ecn-tunnel-03 (work in
	progress), July 2008.		progress), July 2009.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for
	Requirement Levels", BCP 14, RFC 2119, March 1997.		use in RFCs to Indicate
			Requirement Levels", BCP 14,
			RFC 2119, March 1997.
	[RFC2211] Wroclawski, J., "Specification of the Controlled-Load		[RFC2211] Wroclawski, J.,
	Network Element Service", RFC 2211, September 1997.		"Specification of the
			Controlled-Load Network
			Element Service", RFC 2211,
			September 1997.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S.,
	of Explicit Congestion Notification (ECN) to IP",		and D. Black, "The Addition
	RFC 3168, September 2001.		of Explicit Congestion
			Notification (ECN) to IP",
			RFC 3168, September 2001.
	[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,		[RFC3246] Davie, B., Charny, A.,
	J., Courtney, W., Davari, S., Firoiu, V., and D.		Bennet, J., Benson, K., Le
	Stiliadis, "An Expedited Forwarding PHB (Per-Hop		Boudec, J., Courtney, W.,
	Behavior)", RFC 3246, March 2002.		Davari, S., Firoiu, V., and
			D. Stiliadis, "An Expedited
			Forwarding PHB (Per-Hop
			Behavior)", RFC 3246,
			March 2002.
	[RFC4774] Floyd, S., "Specifying Alternate Semantics for the		[RFC4774] Floyd, S., "Specifying
	Explicit Congestion Notification (ECN) Field", BCP 124,		Alternate Semantics for the
	RFC 4774, November 2006.		Explicit Congestion
			Notification (ECN) Field",
			BCP 124, RFC 4774,
			November 2006.
	14.2. Informative References		14.2. Informative References
	[CLoop_pol]		[CLoop_pol] Salvatori, A., "Closed Loop
	Salvatori, A., "Closed Loop Traffic Policing", Politecnico		Traffic Policing",
	Torino and Institut Eurecom Masters Thesis ,		Politecnico Torino and
	September 2005.		Institut Eurecom Masters
			Thesis , September 2005.
	[ECN-BGP] Mortier, R. and I. Pratt, "Incentive Based Inter-Domain		[ECN-BGP] Mortier, R. and I. Pratt,
	Routeing", Proc Internet Charging and QoS Technology		"Incentive Based Inter-
	Workshop (ICQT'03) pp308--317, September 2003, <http://		Domain Routeing", Proc
	research.microsoft.com/users/mort/publications.aspx>.		Internet Charging and QoS
			Technology Workshop
			(ICQT'03) pp308--317,
			September 2003, <http://
			research.microsoft.com/
			users/mort/
			publications.aspx>.
	[I-D.arumaithurai-nsis-pcn]		[I-D.arumaithurai-nsis-pcn] Arumaithurai, M., "NSIS PCN-
	Arumaithurai, M., "NSIS PCN-QoSM: A Quality of Service		QoSM: A Quality of Service
	Model for Pre-Congestion Notification (PCN)",		Model for Pre-Congestion
	draft-arumaithurai-nsis-pcn-00 (work in progress),		Notification (PCN)", draft-
	September 2007.		arumaithurai-nsis-pcn-00
			(work in progress),
			September 2007.
	[I-D.charny-pcn-single-marking]		[I-D.charny-pcn-single-marking] Charny, A., Zhang, X.,
	Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre-		Faucheur, F., and V.
	Congestion Notification Using Single Marking for Admission		Liatsos, "Pre-Congestion
	and Termination", draft-charny-pcn-single-marking-03		Notification Using Single
	(work in progress), November 2007.		Marking for Admission and
			Termination", draft-charny-
			pcn-single-marking-03 (work
			in progress), November 2007.
	[I-D.ietf-nsis-rmd]		[I-D.ietf-nsis-rmd] Bader, A., Westberg, L.,
	Bader, A., "RMD-QOSM - The Resource Management in Diffserv		Karagiannis, G., Kappler,
	QOS Model", draft-ietf-nsis-rmd-12 (work in progress),		C., Tschofenig, H., Phelan,
	November 2007.		T., Takacs, A., and A.
			Csaszar, "RMD-QOSM - The
			Resource Management in
			Diffserv QOS Model",
			draft-ietf-nsis-rmd-15 (work
			in progress), July 2009.
	[I-D.ietf-pcn-architecture]		[I-D.ietf-tsvwg-admitted-realtime-dscp] Baker, F., Polk, J., and M.
	Eardley, P., "Pre-Congestion Notification (PCN)		Dolly, "DSCP for Capacity-
	Architecture", draft-ietf-pcn-architecture-06 (work in		Admitted Traffic", draft-
	progress), September 2008.		ietf-tsvwg-admitted-
			realtime-dscp-05 (work in
			progress), November 2008.
	[I-D.ietf-tsvwg-admitted-realtime-dscp]		[IXQoS] Briscoe, B. and S. Rudkin,
	Baker, F., Polk, J., and M. Dolly, "DSCPs for Capacity-		"Commercial Models for IP
	Admitted Traffic",		Quality of Service
	draft-ietf-tsvwg-admitted-realtime-dscp-04 (work in		Interconnect", BT Technology
	progress), February 2008.		Journal (BTTJ) 23(2)171--
			195, April 2005, <http://
			www.cs.ucl.ac.uk/staff/
			B.Briscoe/pubs.html#ixqos>.
	[IXQoS] Briscoe, B. and S. Rudkin, "Commercial Models for IP		[QoS_scale] Reid, A., "Economics and
	Quality of Service Interconnect", BT Technology Journal		Scalability of QoS
	(BTTJ) 23(2)171--195, April 2005,		Solutions", BT Technology
	<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#ixqos>.		Journal (BTTJ) 23(2)97--117,
			April 2005.
	[QoS_scale]		[RFC2205] Braden, B., Zhang, L.,
	Reid, A., "Economics and Scalability of QoS Solutions", BT		Berson, S., Herzog, S., and
	Technology Journal (BTTJ) 23(2)97--117, April 2005.		S. Jamin, "Resource
			ReSerVation Protocol (RSVP)
			-- Version 1 Functional
			Specification", RFC 2205,
			September 1997.
	[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2207] Berger, L. and T. O'Malley,
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		"RSVP Extensions for IPSEC
	Functional Specification", RFC 2205, September 1997.		Data Flows", RFC 2207,
			September 1997.
	[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC		[RFC2208] Mankin, A., Baker, F.,
	Data Flows", RFC 2207, September 1997.		Braden, B., Bradner, S.,
			O'Dell, M., Romanow, A.,
			Weinrib, A., and L. Zhang,
			"Resource ReSerVation
			Protocol (RSVP) Version 1
			Applicability Statement Some
			Guidelines on Deployment",
			RFC 2208, September 1997.
	[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell,		[RFC2747] Baker, F., Lindell, B., and
	M., Romanow, A., Weinrib, A., and L. Zhang, "Resource		M. Talwar, "RSVP
	ReSerVation Protocol (RSVP) Version 1 Applicability		Cryptographic
	Statement Some Guidelines on Deployment", RFC 2208,		Authentication", RFC 2747,
	September 1997.		January 2000.
	[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic		[RFC2998] Bernet, Y., Ford, P.,
	Authentication", RFC 2747, January 2000.		Yavatkar, R., Baker, F.,
			Zhang, L., Speer, M.,
			Braden, R., Davie, B.,
			Wroclawski, J., and E.
			Felstaine, "A Framework for
			Integrated Services
			Operation over Diffserv
			Networks", RFC 2998,
			November 2000.
	[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,		[RFC3540] Spring, N., Wetherall, D.,
	Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.		and D. Ely, "Robust Explicit
	Felstaine, "A Framework for Integrated Services Operation		Congestion Notification
	over Diffserv Networks", RFC 2998, November 2000.		(ECN) Signaling with
			Nonces", RFC 3540,
			June 2003.
	[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit		[RFC4301] Kent, S. and K. Seo,
	Congestion Notification (ECN) Signaling with Nonces",		"Security Architecture for
	RFC 3540, June 2003.		the Internet Protocol",
			RFC 4301, December 2005.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4727] Fenner, B., "Experimental
	Internet Protocol", RFC 4301, December 2005.		Values In IPv4, IPv6,
			ICMPv4, ICMPv6, UDP, and TCP
			Headers", RFC 4727,
			November 2006.
	[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,		[RFC5129] Davie, B., Briscoe, B., and
	ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.		J. Tay, "Explicit Congestion
			Marking in MPLS", RFC 5129,
			January 2008.
	[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion		[RFC5559] Eardley, P., "Pre-Congestion
	Marking in MPLS", RFC 5129, January 2008.		Notification (PCN)
			Architecture", RFC 5559,
			June 2009.
	[RSVP-ECN]		[RSVP-ECN] Le Faucheur, F., Charny, A.,
	Le Faucheur, F., Charny, A., Briscoe, B., Eardley, P.,		Briscoe, B., Eardley, P.,
	Babiarz, J., and K. Chan, "RSVP Extensions for Admission		Babiarz, J., and K. Chan,
	Control over Diffserv using Pre-congestion Notification",		"RSVP Extensions for
	draft-lefaucheur-rsvp-ecn-01 (work in progress),		Admission Control over
	June 2006.		Diffserv using Pre-
			congestion Notification",
			draft-lefaucheur-rsvp-ecn-01
			(work in progress),
			June 2006.
	[Re-fb] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C.,		[Re-fb] Briscoe, B., Jacquet, A., Di
	Salvatori, A., Soppera, A., and M. Koyabe, "Policing		Cairano-Gilfedder, C.,
	Congestion Response in an Internetwork Using Re-Feedback",		Salvatori, A., Soppera, A.,
	ACM SIGCOMM CCR 35(4)277--288, August 2005, <http://		and M. Koyabe, "Policing
	www.acm.org/sigs/sigcomm/sigcomm2005/		Congestion Response in an
	techprog.html#session8>.		Internetwork Using Re-
			Feedback", ACM SIGCOMM
			CCR 35(4)277--288,
			August 2005, <http://
			www.acm.org/sigs/sigcomm/
			sigcomm2005/
			techprog.html#session8>.
	[Smart_rtg]		[Smart_rtg] Goldenberg, D., Qiu, L.,
	Goldenberg, D., Qiu, L., Xie, H., Yang, Y., and Y. Zhang,		Xie, H., Yang, Y., and Y.
	"Optimizing Cost and Performance for Multihoming", ACM		Zhang, "Optimizing Cost and
	SIGCOMM CCR 34(4)79--92, October 2004,		Performance for
	<http://citeseer.ist.psu.edu/698472.html>.		Multihoming", ACM SIGCOMM
			CCR 34(4)79--92,
			October 2004, <http://
			citeseer.ist.psu.edu/
			698472.html>.
	[Steps_DoS]		[Steps_DoS] Handley, M. and A.
	Handley, M. and A. Greenhalgh, "Steps towards a DoS-		Greenhalgh, "Steps towards a
	resistant Internet Architecture", Proc. ACM SIGCOMM		DoS-resistant Internet
	workshop on Future directions in network architecture		Architecture", Proc. ACM
	(FDNA'04) pp 49--56, August 2004.		SIGCOMM workshop on Future
			directions in network
			architecture (FDNA'04) pp
			49--56, August 2004.
	Appendix A. Implementation		Appendix A. Implementation
	A.1. Ingress Gateway Algorithm for Blanking the RE flag		A.1. Ingress Gateway Algorithm for Blanking the RE flag
	The ingress gateway receives regular feedback 'PCN-feedback-		The ingress gateway receives regular feedback 'PCN-feedback-
	information' reporting the fraction of congestion marked octets for		information' reporting the fraction of congestion marked octets for
	each aggregate arriving at the egress. So for each aggregate it		each aggregate arriving at the egress. So for each aggregate it
	should blank the RE flag on this fraction of octets. A suitable		should blank the RE flag on this fraction of octets. A suitable
	pseudo-code algorithm for the ingress gateway is as follows:		pseudo-code algorithm for the ingress gateway is as follows:
	skipping to change at page 58, line 8		skipping to change at page 59, line 8
	A.3. Algorithm for Sanctioning Negative Traffic		A.3. Algorithm for Sanctioning Negative Traffic
	{ToDo: Write up algorithms similar to Appendix E of		{ToDo: Write up algorithms similar to Appendix E of
	[I-D.briscoe-tsvwg-re-ecn-tcp] for the negative flow monitor with		[I-D.briscoe-tsvwg-re-ecn-tcp] for the negative flow monitor with
	flow management algorithm and the variant with bounded flow state.}		flow management algorithm and the variant with bounded flow state.}
	Author's Address		Author's Address
	Bob Briscoe		Bob Briscoe
	BT & UCL		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://www.cs.ucl.ac.uk/staff/B.Briscoe/		URI: http://bobbriscoe.net/
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
	Acknowledgment
	This document was produced using xml2rfc v1.33 (of
	http://xml.resource.org/) from a source in RFC-2629 XML format.
End of changes. 67 change blocks.
	209 lines changed or deleted		306 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/