draft-ietf-tsvwg-ecn-mpls-02.txt		rfc5129.txt
	Network Working Group B. Davie		Network Working Group B. Davie
	Internet-Draft Cisco Systems, Inc.		Request for Comments: 5129 Cisco Systems, Inc.
	Intended status: Standards Track B. Briscoe		Category: Standards Track B. Briscoe
	Expires: April 6, 2008 J. Tay		J. Tay
	BT Research		BT Research
	October 4, 2007		January 2008
	Explicit Congestion Marking in MPLS		Explicit Congestion Marking in MPLS
	draft-ietf-tsvwg-ecn-mpls-02.txt
	Status of this Memo
	By submitting this Internet-Draft, each author represents that any
	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
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 6, 2008.
	Copyright Notice		Status of This Memo
	Copyright (C) The IETF Trust (2007).		This document specifies an Internet standards track protocol for the
			Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
			Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Abstract		Abstract
	RFC 3270 defines how to support the Diffserv architecture in MPLS		RFC 3270 defines how to support the Diffserv architecture in MPLS
	networks, including how to encode Diffserv Code Points (DSCPs) in an		networks, including how to encode Diffserv Code Points (DSCPs) in an
	MPLS header. DSCPs may be encoded in the EXP field, while other uses		MPLS header. DSCPs may be encoded in the EXP field, while other uses
	of that field are not precluded. RFC3270 makes no statement about		of that field are not precluded. RFC3270 makes no statement about
	how Explicit Congestion Notification (ECN) marking might be encoded		how Explicit Congestion Notification (ECN) marking might be encoded
	in the MPLS header. This draft defines how an operator might define		in the MPLS header. This document defines how an operator might
	some of the EXP codepoints for explicit congestion notification,		define some of the EXP codepoints for explicit congestion
	without precluding other uses.		notification, without precluding other uses.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	Change History
	[Note to RFC Editor: This section to be removed before publication]
	Changes in this version (draft-ietf-tsvwg-ecn-mpls-02.txt) relative
	to the last (draft-ietf-tsvwg-ecn-mpls-01.txt):
	o Added new text about misordering considerations in Section 6.
	o Swapped order of Section 8 and Section 9.
	o Explained more fully the example of congestion-based traffic
	engineering in Section 9.3.
	o Trimmed the example of PCN in Section 9.4 and updated to latest
	preferred PCN terminology in PCN appendix.
	Changes in draft-ietf-tsvwg-ecn-mpls-01.txt relative to
	draft-ietf-tsvwg-ecn-mpls-00.txt:
	o Moved the detailed discussion of marking procedures for Pre-
	Congestion Notification (PCN) to an appendix.
	o Removed PCN as a motivation for the efficient code-point usage in
	Section 2.
	o Clarified the rationale for preferring the ECT-checking approach
	over the approach of [Floyd] in Section 8.1.
	o Updated discussion of relationship to RFC3168 in Section 7
	o Removed discussion of re-ECN from Security Considerations.
	o Fixed typos and nits.
	Changes in draft-ietf-tsvwg-ecn-mpls-00.txt relative to
	draft-davie-ecn-mpls-00:
	o Corrected the description of ECN-MPLS marking proposed in
	[Shayman], which closely corresponds to that proposed in this
	document.
	o Pre-congestion notification (PCN) marking is now described in a
	way that does not require normative references to PCN
	specifications. PCN discussion now serves only to illustrate how
	the ECN marking concepts can be extended to cover more complex
	scenarios, with PCN being an example.
	o Added specification of behavior when MPLS encapsulated packets
	cross from an ECN-enabled domain to a domain that is not ECN-
	enabled.
	o Clarified that copying MPLS ECN or PCN marking into exposed IP
	header on egress is not mandatory
	o Fixed typos and nits
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 7		2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 5
	3. Per-domain ECT checking . . . . . . . . . . . . . . . . . . . 9		3. Per-Domain ECT Checking . . . . . . . . . . . . . . . . . . . 7
	4. ECN-enabled MPLS domain . . . . . . . . . . . . . . . . . . . 9		4. ECN-Enabled MPLS Domain . . . . . . . . . . . . . . . . . . . 8
	4.1. Pushing (adding) one or more labels to an IP packet . . . 10		4.1. Pushing (Adding) One or More Labels to an IP Packet . . . 8
	4.2. Pushing one or more labels onto an MPLS labelled packet . 10		4.2. Pushing One or More Labels onto an MPLS Labeled Packet . . 8
	4.3. Congestion experienced in an interior MPLS node . . . . . 10		4.3. Congestion Experienced in an Interior MPLS Node . . . . . 8
	4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 10		4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 8
	4.5. Popping an MPLS label (not the end of the stack) . . . . . 11		4.5. Popping an MPLS Label (Not the End of the Stack) . . . . . 9
	4.6. Popping the last MPLS label in the stack . . . . . . . . . 11		4.6. Popping the Last MPLS Label in the Stack . . . . . . . . . 9
	4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 11		4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 10
	5. ECN-disabled MPLS domain . . . . . . . . . . . . . . . . . . . 12		5. ECN-Disabled MPLS Domain . . . . . . . . . . . . . . . . . . . 10
	6. The use of more codepoints with E-LSPs and L-LSPs . . . . . . 12		6. The Use of More Codepoints with E-LSPs and L-LSPs . . . . . . 10
	7. Relationship to tunnel behavior in RFC 3168 . . . . . . . . . 12		7. Relationship to Tunnel Behavior in RFC 3168 . . . . . . . . . 11
	8. Deployment Considerations . . . . . . . . . . . . . . . . . . 13		8. Deployment Considerations . . . . . . . . . . . . . . . . . . 11
	8.1. Marking non-ECN Capable Packets . . . . . . . . . . . . . 13		8.1. Marking Non-ECN-Capable Packets . . . . . . . . . . . . . 11
	8.2. Non-ECN capable routers in an MPLS Domain . . . . . . . . 14		8.2. Non-ECN-Capable Routers in an MPLS Domain . . . . . . . . 12
	9. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. RFC3168-style ECN . . . . . . . . . . . . . . . . . . . . 14		9.1. RFC 3168-Style ECN . . . . . . . . . . . . . . . . . . . . 13
	9.2. ECN Co-existence with Diffserv E-LSPs . . . . . . . . . . 15		9.2. ECN Co-Existence with Diffserv E-LSPs . . . . . . . . . . 13
	9.3. Congestion-feedback-based Traffic Engineering . . . . . . 15		9.3. Congestion-Feedback-Based Traffic Engineering . . . . . . 14
	9.4. PCN flow admission control and flow termination . . . . . 16		9.4. PCN Flow Admission Control and Flow Termination . . . . . 14
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 16		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		Appendix A. Extension to Pre-Congestion Notification . . . . . . 16
	Appendix A. Extension to Pre-Congestion Notification . . . . . . 17		A.1. Label Push onto IP Packet . . . . . . . . . . . . . . . . . 16
	Appendix A.1. Label Push onto IP packet . . . . . . . . . . . . . 18		A.2. Pushing Additional MPLS Labels . . . . . . . . . . . . . . 16
	Appendix A.2. Pushing Additional MPLS Labels . . . . . . . . . . . 18		A.3. Admission Control or Flow Termination Marking Inside
	Appendix A.3. Admission Control or Flow Termination Marking		MPLS Domain . . . . . . . . . . . . . . . . . . . . . . . . 17
	inside MPLS domain . . . . . . . . . . . . . . . . . 18		A.4. Popping an MPLS Label (Not End of Stack) . . . . . . . . . 17
	Appendix A.4. Popping an MPLS Label (not end of stack) . . . . . . 18		A.5. Popping the Last MPLS Label to Expose IP Header . . . . . . 17
	Appendix A.5. Popping the last MPLS Label to expose IP header . . 19		Normative References . . . . . . . . . . . . . . . . . . . . . . . 18
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		Informative References . . . . . . . . . . . . . . . . . . . . . . 18
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	13.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . . . 23
	1. Introduction		1. Introduction
	1.1. Background		1.1. Background
	[RFC3168] defines Explicit Congestion Notification for IP. The		[RFC3168] defines Explicit Congestion Notification (ECN) for IP. The
	primary purpose of ECN is to allow congestion to be signalled without		primary purpose of ECN is to allow congestion to be signalled without
	dropping packets.		dropping packets.
	[RFC3270] defines how to support the Diffserv architecture in MPLS		[RFC3270] defines how to support the Diffserv architecture in MPLS
	networks, including how to encode Diffserv Code Points (DSCPs) in an		networks, including how to encode Diffserv Code Points (DSCPs) in an
	MPLS header. DSCPs may be encoded in the EXP field, while other uses		MPLS header. DSCPs may be encoded in the EXP field, while other uses
	of that field are not precluded. RFC3270 makes no statement about		of that field are not precluded. RFC3270 makes no statement about
	how Explicit Congestion Notification (ECN) marking might be encoded		how Explicit Congestion Notification (ECN) marking might be encoded
	in the MPLS header.		in the MPLS header.
	This draft defines how an operator might define some of the EXP		This document defines how an operator might define some of the EXP
	codepoints for explicit congestion notification, without precluding		codepoints for explicit congestion notification, without precluding
	other uses. In parallel to the activity defining the addition of ECN		other uses. In parallel to the activity defining the addition of ECN
	to IP [RFC3168], two proposals were made to add ECN to MPLS		to IP [RFC3168], two proposals were made to add ECN to MPLS
	[Floyd][Shayman]. These proposals, however, fell by the wayside.		[Floyd][Shayman]. These proposals, however, fell by the wayside.
	With ECN for IP now being a proposed standard, and developing		With ECN for IP now being a proposed standard, and developing
	interest in using pre-congestion notification (PCN) for admission		interest in using pre-congestion notification (PCN) for admission
	control and flow termination [I-D.ietf-pcn-architecture], there is		control and flow termination [PCN], there is consequent interest in
	consequent interest in being able to support ECN across IP networks		being able to support ECN across IP networks consisting of MPLS-
	consisting of MPLS-enabled domains. Therefore it is necessary to		enabled domains. Therefore, it is necessary to specify the protocol
	specify the protocol for including ECN in the MPLS shim header, and		for including ECN in the MPLS shim header and the protocol behavior
	the protocol behavior of edge MPLS nodes.		of edge MPLS nodes.
	We note that in [RFC3168] there are four codepoints used for ECN		We note that in [RFC3168], there are four codepoints used for ECN
	marking, which are encoded using two bits of the IP header. The MPLS		marking, which are encoded using two bits of the IP header. The MPLS
	EXP field is the logical place to encode ECN codepoints, but with		EXP field is the logical place to encode ECN codepoints, but with
	only 3 bits (8 codepoints) available, and with the same field being		only 3 bits (8 codepoints) available, and with the same field being
	used to convey DSCP information as well, there is a clear incentive		used to convey DSCP information as well, there is a clear incentive
	to conserve the number of codepoints consumed for ECN purposes.		to conserve the number of codepoints consumed for ECN purposes.
	Efficient use of the EXP field has been a focus of prior drafts		Efficient use of the EXP field has been a focus of prior documents
	[Floyd] [Shayman] and we draw on those efforts in this draft as well.		[Floyd] [Shayman], and we draw on those efforts in this document as
			well.
	We also note that [RFC3168] defines default usage of the ECN field		We also note that [RFC3168] defines default usage of the ECN field,
	but allows for the possibility that some Diffserv PHBs might include		but it allows for the possibility that some Diffserv Per Hop
	different specifications on how the ECN field is to be used. This		Behaviors (PHBs) might include different specifications on how the
	draft seeks to preserve that capability.		ECN field is to be used. This document seeks to preserve that
			capability.
	1.2. Intent		1.2. Intent
	Our intent is to specify how the MPLS shim header [RFC3032] should		Our intent is to specify how the MPLS shim header [RFC3032] should
	denote ECN marking and how MPLS nodes should understand whether the		denote ECN marking and how MPLS nodes should understand whether the
	transport for a packet will be ECN capable. We offer this as a		transport for a packet will be ECN capable. We offer this as a
	building block, from which to build different congestion notification		building block, from which to build different congestion-notification
	systems. We do not intend to specify how the resulting congestion		systems. We do not intend to specify how the resulting congestion
	notification is fed back to an upstream node that can mitigate		notification is fed back to an upstream node that can mitigate
	congestion. For instance, unlike [Shayman], we do not specify edge-		congestion. For instance, unlike [Shayman], we do not specify edge-
	to-edge MPLS domain feedback, but we also do not preclude it.		to-edge MPLS domain feedback, but we also do not preclude it.
	Nonetheless, we do specify how the egress node of an MPLS domain		Nonetheless, we do specify how the egress node of an MPLS domain
	should copy congestion notification from the MPLS shim into the		should copy congestion notification from the MPLS shim into the
	encapsulated IP header if the ECN is to be carried onward towards the		encapsulated IP header if the ECN is to be carried onward towards the
	IP receiver. But we do NOT mandate that MPLS congestion notification		IP receiver; but we do *not* mandate that MPLS congestion
	must be copied into the IP header for onward transmission. This		notification must be copied into the IP header for onward
	draft aims to be generic for any use of congestion notification in		transmission. This document aims to be generic for any use of
	MPLS. Support of [RFC3168] is our primary motivation; some		congestion notification in MPLS. Support of [RFC3168] is our primary
	additional potential applications to illustrate the flexibility of		motivation; some additional potential applications to illustrate the
	our approach are described in Section 9. In particular, we aim to		flexibility of our approach are described in Section 9. In
	support possible future schemes that may use more than one level of		particular, we aim to support possible future schemes that may use
	congestion marking.		more than one level of congestion marking.
	1.3. Terminology		1.3. Terminology
	This document draws freely on the terminology of ECN [RFC3168] and		This document draws freely on the terminology of ECN [RFC3168] and
	MPLS [RFC3031]. For ease of reference, we have included some		MPLS [RFC3031]. For ease of reference, we have included some
	definitions here, but refer the reader to the references above for		definitions here, but refer the reader to the references above for
	complete specifications of the relevant technologies:		complete specifications of the relevant technologies:
	o CE: Congestion Experienced. One of the states with which a packet		o CE: Congestion Experienced. One of the states with which a packet
	may be marked in a network supporting ECN. A packet is marked in		may be marked in a network supporting ECN. A packet is marked in
	this state by an ECN-capable router, to indicate that this router		this state by an ECN-capable router to indicate that this router
	was experiencing congestion at the time the packet arrived.		was experiencing congestion at the time the packet arrived.
	o ECT: ECN-capable Transport. One of the ECN states which a packet		o ECT: ECN-capable Transport. One of the ECN states that a packet
	may be in when it is sent by an end system. An end system marks a		may be in when it is sent by an end system. An end system marks a
	packet with an ECT codepoint to indicate that the end-points of		packet with an ECT codepoint to indicate that the endpoints of the
	the transport protocol are ECN-capable. A router may not mark a		transport protocol are ECN-capable. A router may not mark a
	packet as CE unless the packet was marked ECT when it arrived.		packet as CE unless the packet was marked ECT when it arrived.
	o Not-ECT: Not ECN capable transport. An end system marks a packet		o Not-ECT: Not ECN-capable transport. An end system marks a packet
	with this codepoint to indicate that the end-points of the		with this codepoint to indicate that the endpoints of the
	transport protocol are not ECN-capable. A congested router cannot		transport protocol are not ECN-capable. A congested router cannot
	mark such packets as CE, and thus can only drop them to indicate		mark such packets as CE, and thus it can only drop them to
	congestion.		indicate congestion.
	o EXP field. A 3 bit field in the MPLS label header [RFC3032] which		o EXP field. A 3-bit field in the MPLS label header [RFC3032] that
	may be used to convey Diffserv information (and is also used in		may be used to convey Diffserv information (and is also used in
	this draft to carry ECN information).		this document to carry ECN information).
	o PHP. Penultimate Hop Popping. An MPLS operation in which the		o PHP. Penultimate Hop Popping. An MPLS operation in which the
	penultimate Label Switching Router (LSR) on a Label Switched Path		penultimate Label Switching Router (LSR) on a Label Switched Path
	(LSP) removes the top label from the packet before forwarding the		(LSP) removes the top label from the packet before forwarding the
	packet to the final LSR on the LSP.		packet to the final LSR on the LSP.
			Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Use of MPLS EXP Field for ECN		2. Use of MPLS EXP Field for ECN
	We propose that LSRs configured for explicit congestion notification		We propose that LSRs configured for explicit congestion notification
	should use the EXP field in the MPLS shim header. However, [RFC3270]		should use the EXP field in the MPLS shim header. However, [RFC3270]
	already defines use of codepoints in the EXP field for differentiated		already defines use of codepoints in the EXP field for differentiated
	services. Although it does not preclude other compatible uses of the		services. Although it does not preclude other compatible uses of the
	EXP field, this clearly seems to limit the space available for ECN,		EXP field, this clearly seems to limit the space available for ECN,
	given the field is only 3 bits (8 codepoints).		given the field is only 3 bits (8 codepoints).
	[RFC3270] defines two possible approaches for requesting		[RFC3270] defines two possible approaches for requesting
	differentiated service treatment from an LSR.		differentiated service treatment from an LSR:
	o In the E-LSP approach, different codepoints of the EXP field in		o In the EXP-Inferred-PSC LSP (E-LSP) approach, different codepoints
	the MPLS shim header are used to indicate the packet's per hop		of the EXP field in the MPLS shim header are used to indicate the
	behavior (PHB).		packet's per hop behavior (PHB).
	o In the L-LSP approach, an MPLS label is assigned for each PHB		o In the Label-Only-Inferred-PSC LSP (L-LSP) approach, an MPLS label
	scheduling class (PSC, as defined in [RFC3260], so that an LSR		is assigned for each PHB scheduling class (PSC, as defined in
	determines both its forwarding and its scheduling behavior from		[RFC3260], so that an LSR determines both its forwarding and its
	the label.		scheduling behavior from the label.
	If an MPLS domain uses the L-LSP approach, there is likely to be		If an MPLS domain uses the L-LSP approach, there is likely to be
	space in the EXP field for ECN codepoint(s). Where the E-LSP		space in the EXP field for ECN codepoint(s). Where the E-LSP
	approach is used, then codepoint space in the EXP field is likely to		approach is used, codepoint space in the EXP field is likely to be
	be scarce. This draft focuses on interworking ECN marking with the		scarce. This document focuses on interworking ECN marking with the
	E-LSP approach as it is the tougher problem. Consequently the same		E-LSP approach, as it is the tougher problem. Consequently, the same
	approach can also be applied with L-LSPs.		approach can also be applied with L-LSPs.
	We recommend that explicit congestion notification in MPLS should use		We recommend that explicit congestion notification in MPLS should use
	codepoints instead of bits in the EXP field. Since not every PHB		codepoints instead of bits in the EXP field. Since not every PHB
	will necessarily require an associated ECN codepoint it would be		will necessarily require an associated ECN codepoint, it would be
	wasteful to assign a dedicated bit for ECN. (There may also be cases		wasteful to assign a dedicated bit for ECN. (There may also be cases
	where a given PHB might need more than one ECN-like codepoint; see		where a given PHB might need more than one ECN-like codepoint; see
	Section 9.4 for an example.)		Section 9.4 for an example).
	For each PHB that uses ECN marking, we assume one EXP codepoint will		For each PHB that uses ECN marking, we assume one EXP codepoint will
	be defined meaning not congestion marked (Not-CM), and at least one		be defined as not congestion marked (Not-CM), and at least one other
	other codepoint will be defined meaning congestion marked (CM).		codepoint will be defined as congestion marked (CM). Therefore, each
	Therefore, each PHB that uses ECN marking will consume at least two		PHB that uses ECN marking will consume at least two EXP codepoints,
	EXP codepoints. But PHBs that do not use ECN marking will only		but PHBs that do not use ECN marking will only consume one.
	consume one.
	Further, we wish to use minimal space in the MPLS shim header to tell		Further, we wish to use minimal space in the MPLS shim header to tell
	interior LSRs whether each packet will be received by an ECN-capable		interior LSRs whether each packet will be received by an ECN-capable
	transport (ECT). Nonetheless, we must ensure that an end-point that		transport (ECT). Nonetheless, we must ensure that an endpoint that
	would not understand an ECN mark will not receive one, otherwise it		would not understand an ECN mark will not receive one, otherwise it
	will not be able to respond to congestion as it should. In the past,		will not be able to respond to congestion as it should. In the past,
	three solutions to this problem have been proposed:		three solutions to this problem have been proposed:
	o One possible approach is for congested LSRs to mark the ECN field		o One possible approach is for congested LSRs to mark the ECN field
	in the underlying IP header at the bottom of the label stack.		in the underlying IP header at the bottom of the label stack.
	Although many commercial LSRs routinely access the IP header for		Although many commercial LSRs routinely access the IP header for
	other reasons (ECMP), there are numerous drawbacks to attempting		other reasons (equal cost multi-path - ECMP), there are numerous
	to find an IP header beneath an MPLS label stack. Notably, there		drawbacks to attempting to find an IP header beneath an MPLS label
	is the challenge of detecting the absence of an IP header when		stack. Notably, there is the challenge of detecting the absence
	non-IP packets are carried on an LSP. Therefore we will not		of an IP header when non-IP packets are carried on an LSP.
	consider this approach further.		Therefore, we will not consider this approach further.
	o In the scheme suggested by [Floyd] ECT and CE are overloaded into		o In the scheme suggested by [Floyd], ECT and CE are overloaded into
	one bit, so that a 0 means ECT while a 1 might either mean Not-ECT		one bit, so that a 0 means ECT while a 1 might either mean Not-ECT
	or it might mean CE. A packet that has been marked as having		or it might mean CE. A packet that has been marked as having
	experienced congestion upstream, and then is picked out for		experienced congestion upstream, and then is picked out for
	marking at a second congested LSR, will be dropped by the second		marking at a second congested LSR, will be dropped by the second
	LSR since it cannot determine whether the packet has previously		LSR since it cannot determine whether the packet has previously
	experienced congestion or if ECN is not supported by the		experienced congestion or if ECN is not supported by the
	transport.		transport.
	While such an approach seemed potentially palatable, we do not		While such an approach seemed potentially palatable, we do not
	recommend it here for the following reasons. In some cases we		recommend it here for the following reasons. In some cases, we
	wish to be able to use ECN marking long before actual congestion		wish to be able to use ECN marking long before actual congestion
	(e.g. pre-congestion notification). In these circumstances,		(e.g., pre-congestion notification). In these circumstances,
	marking rates at each LSR might be non-negligible most of the		marking rates at each LSR might be non-negligible most of the
	time, so the chances of a previously marked packet encountering an		time, so the chances of a previously marked packet encountering an
	LSR that wants to mark it again will also be non-negligible. In		LSR that wants to mark it again will also be non-negligible. In
	the case where CE and not-ECT are indistinguishable to core		the case where CE and not-ECT are indistinguishable to core
	routers, such a scenario could lead to unacceptable drop rates.		routers, such a scenario could lead to unacceptable drop rates.
	If the typical marking rate at every router or LSR is p, and the		If the typical marking rate at every router or LSR is p, and the
	typical diameter of the network of LSRs is d, then the probability		typical diameter of the network of LSRs is d, then the probability
	that a marked packet will be chosen for marking more than once is		that a marked packet will be chosen for marking more than once is
	1-[Pr(never marked) + Pr(marked at exactly one hop)] = 1- [(1-p)^d		1-[Pr(never marked) + Pr(marked at exactly one hop)] = 1- [(1-p)^d
	+ dp(1-p)^(d-1)]. For instance, with 6 LSRs in a row, each		+ dp(1-p)^(d-1)]. For instance, with 6 LSRs in a row, each
	marking ECN with 1% probability, the chances of a packet that is		marking ECN with 1% probability, the chances of a packet that is
	already marked being chosen for marking a second time is 0.15%.		already marked being chosen for marking a second time is 0.15%.
	The bit overloading scheme would therefore introduce a drop rate		The bit-overloading scheme would therefore introduce a drop rate
	of 0.15% unnecessarily. Given that most modern core networks are		of 0.15% unnecessarily. Given that most modern core networks are
	sized to introduce near-zero packet drop, it may be unacceptable		sized to introduce near-zero packet drop, it may be unacceptable
	to drop over one in a thousand packets unnecessarily.		to drop over one in a thousand packets unnecessarily.
	o A third possible approach was suggested by [Shayman]. In this		o A third possible approach was suggested by [Shayman]. In this
	scheme, interior LSRs assume that the endpoints are ECN-capable,		scheme, interior LSRs assume that the endpoints are ECN-capable,
	but this assumption is checked when the final label is popped. If		but this assumption is checked when the final label is popped. If
	an interior LSR has marked ECN in the EXP field of the shim		an interior LSR has marked ECN in the EXP field of the shim
	header, but the IP header says the endpoints are not ECN capable,		header, but the IP header says the endpoints are not ECN-capable,
	the edge router (or penultimate router, if using penultimate hop		the edge router (or penultimate router, if using penultimate hop
	popping) drops the packet. We recommend this scheme, which we		popping) drops the packet. We recommend this scheme, which we
	call `per-domain ECT checking', and define it more precisely in		call `per-domain ECT checking', and define it more precisely in
	the following section. Its chief drawback is that it can cause		the following section. Its chief drawback is that it can cause
	packets to be forwarded after encountering congestion only to be		packets to be forwarded after encountering congestion only to be
	dropped at the egress of the MPLS domain. The rationale for this		dropped at the egress of the MPLS domain. The rationale for this
	decision is given in Section 8.1.		decision is given in Section 8.1.
	3. Per-domain ECT checking		3. Per-Domain ECT Checking
	For the purposes of this discussion, we define the egress nodes of an		For the purposes of this discussion, we define the egress nodes of an
	MPLS domain as the nodes that pop the last MPLS label from the label		MPLS domain as the nodes that pop the last MPLS label from the label
	stack, exposing the IP (or, potentially non-IP) header. Note that		stack, exposing the IP (or, potentially non-IP) header. Note that
	such a node may be the ultimate or penultimate hop of an LSP,		such a node may be the ultimate or penultimate hop of an LSP,
	depending on whether penultimate hop popping (PHP) is employed.		depending on whether penultimate hop popping (PHP) is employed.
	In the per-domain ECT checking approach, the egress nodes take		In the per-domain ECT checking approach, the egress nodes take
	responsibility for checking whether the transport is ECN capable.		responsibility for checking whether the transport is ECN-capable.
	This draft does not specify how these nodes should pass on congestion		This document does not specify how these nodes should pass on
	notification, because different approaches are likely in different		congestion notification because different approaches are likely in
	scenarios. However, if congestion notification in the MPLS header is		different scenarios. However, if congestion notification in the MPLS
	copied into the IP header, the procedure MUST conform to the		header is copied into the IP header, the procedure MUST conform to
	specification given here.		the specification given here.
	If congestion notification is passed to the transport without first		If congestion notification is passed to the transport without first
	passing it onward in the IP header, the approach used must take		passing it onward in the IP header, the approach used must take
	similar care to check that the transport is ECN capable before		similar care to check that the transport is ECN-capable before
	passing it ECN markings. Specifically, if the transport for a		passing it ECN markings. Specifically, if the transport for a
	particular congestion marked MPLS packet is found not to be ECN-		particular congestion marked MPLS packet is found not to be ECN-
	capable, the packet MUST be dropped at this egress node.		capable, the packet MUST be dropped at this egress node.
	In the per-domain ECT checking approach, only the egress nodes check		In the per-domain ECT checking approach, only the egress nodes check
	whether an IP packet is destined for an ECN-capable transport.		whether an IP packet is destined for an ECN-capable transport.
	Therefore, any single LSR within an MPLS domain MUST NOT be		Therefore, any single LSR within an MPLS domain MUST NOT be
	configured to enable ECN marking unless all the egress LSRs		configured to enable ECN marking unless all the egress LSRs
	surrounding it are already configured to handle ECN marking.		surrounding it are already configured to handle ECN marking.
	We call a domain surrounded by ECN-capable egress LSRs an ECN-enabled		We call a domain surrounded by ECN-capable egress LSRs an ECN-enabled
	MPLS domain. This term only implies that all the egress LSRs are		MPLS domain. This term only implies that all the egress LSRs are
	ECN-enabled; some interior LSRs may not be ECN-enabled. For		ECN-enabled; some interior LSRs may not be ECN-enabled. For
	instance, it would be possible to use some legacy LSRs incapable of		instance, it would be possible to use some legacy LSRs incapable of
	supporting ECN in the interior of an MPLS domain as long as all the		supporting ECN in the interior of an MPLS domain as long as all the
	egress LSRs were ECN-capable. Note that if PHP is used, the		egress LSRs were ECN-capable. Note that if PHP is used, the
	"penultimate hop" routers which perform the pop operation do need to		"penultimate hop" routers that perform the pop operation do need to
	be ECN-enabled, since they are acting in this context as egress LSRs.		be ECN-enabled since they are acting in this context as egress LSRs.
	4. ECN-enabled MPLS domain		4. ECN-Enabled MPLS Domain
	In the following subsections we describe various operations affecting		In the following subsections, we describe various operations
	the ECN marking of a packet that may be performed at MPLS edge and		affecting the ECN marking of a packet that may be performed at MPLS-
	core LSRs.		edge and core LSRs.
	4.1. Pushing (adding) one or more labels to an IP packet		4.1. Pushing (Adding) One or More Labels to an IP Packet
	On encapsulating an IP packet with an MPLS label stack, the ECN field		On encapsulating an IP packet with an MPLS label stack, the ECN field
	must be translated from the IP packet into the MPLS EXP field. The		must be translated from the IP packet into the MPLS EXP field. The
	Not-CM (not congestion marked) state is set in the MPLS EXP field if		Not-CM (not congestion marked) state is set in the MPLS EXP field if
	the ECN status of the IP packet is "Not ECT" or ECT(1) or ECT(0).		the ECN status of the IP packet is Not-ECT or ECT(1) or ECT(0). The
	The CM state is set if the ECN status of the IP packet is "CE". If		CM state is set if the ECN status of the IP packet is CE. If more
	more than one label is pushed at one time, the same value should be		than one label is pushed at one time, the same value should be placed
	placed in the EXP value of all label stack entries.		in the EXP value of all label stack entries.
	4.2. Pushing one or more labels onto an MPLS labelled packet		4.2. Pushing One or More Labels onto an MPLS Labeled Packet
	The EXP field is copied directly from the topmost label before the		The EXP field is copied directly from the topmost label before the
	push to the newly added outer label. If more than one label is being		push to the newly added outer label. If more than one label is being
	pushed, the same EXP value is copied to all label stack entries.		pushed, the same EXP value is copied to all label-stack entries.
	4.3. Congestion experienced in an interior MPLS node		4.3. Congestion Experienced in an Interior MPLS Node
	If the EXP codepoint of the packet maps to a PHB that uses ECN		If the EXP codepoint of the packet maps to a PHB that uses ECN
	marking and the marking algorithm requires the packet to be marked,		marking, and the marking algorithm requires the packet to be marked,
	the CM state is set (irrespective of whether it is already in the CM		the CM state is set (irrespective of whether it is already in the CM
	state).		state).
	If the buffer is full, a packet is dropped.		If the buffer is full, a packet is dropped.
	4.4. Crossing a Diffserv Domain Boundary		4.4. Crossing a Diffserv Domain Boundary
	If an MPLS-encapsulated packet crosses a Diffserv domain boundary, it		If an MPLS-encapsulated packet crosses a Diffserv domain boundary, it
	may be the case that the two domains use different encodings of the		may be the case that the two domains use different encodings of the
	same PHB in the EXP field. In such cases, the EXP field must be		same PHB in the EXP field. In such cases, the EXP field must be
	rewritten at the domain boundary. If the PHB is one that supports		rewritten at the domain boundary. If the PHB is one that supports
	ECN, then the appropriate ECN marking should also be preserved when		ECN, then the appropriate ECN marking should also be preserved when
	the EXP field is mapped at the boundary.		the EXP field is mapped at the boundary.
	If an MPLS-encapsulated packet that is in the CM state crosses from a		If an MPLS-encapsulated packet that is in the CM state crosses from a
	domain that is ECN-enabled (as defined in Section 3) to a domain that		domain that is ECN-enabled (as defined in Section 3) to a domain that
	is not ECN-enabled, then it is necessary to perform the egress		is not ECN-enabled, then it is necessary to perform the egress
	checking procedures at the egress LSR of the ECN-enabled domain.		checking procedures at the egress LSR of the ECN-enabled domain.
	This means that if the encapsulated packet is not ECN capable, the		This means that if the encapsulated packet is not ECN-capable, the
	packet MUST be dropped. Note that this implies the egress LSR must		packet MUST be dropped. Note that this implies the egress LSR must
	be able to look beneath the MPLS header without popping the label		be able to look beneath the MPLS header without popping the label
	stack.		stack.
	The related issue of Diffserv tunnel models is discussed in		The related issue of Diffserv tunnel models is discussed in
	Section 4.7.		Section 4.7.
	4.5. Popping an MPLS label (not the end of the stack)		4.5. Popping an MPLS Label (Not the End of the Stack)
	When a packet has more than one MPLS label in the stack and the top		When a packet has more than one MPLS label in the stack and the top
	label is popped, another MPLS label is exposed. In this case the ECN		label is popped, another MPLS label is exposed. In this case, the
	information should be transferred from the outer EXP field to the		ECN information should be transferred from the outer EXP field to the
	inner MPLS label in the following manner. If the inner EXP field is		inner MPLS label in the following manner. If the inner EXP field is
	Not-CM, the inner EXP field is set to the same CM or Not-CM state as		Not-CM, the inner EXP field is set to the same CM or Not-CM state as
	the outer EXP field. If the inner EXP field is CM, it remains		the outer EXP field. If the inner EXP field is CM, it remains
	unchanged whatever the outer EXP field. Note that an inner value of		unchanged whatever the outer EXP field. Note that an inner value of
	CM and an outer value of not-CM should be considered anomalous, and		CM and an outer value of not-CM should be considered anomalous, and
	SHOULD be logged in some way by the LSR.		SHOULD be logged in some way by the LSR.
	4.6. Popping the last MPLS label in the stack		4.6. Popping the Last MPLS Label in the Stack
	When the last MPLS label is popped from the packet, its payload is		When the last MPLS label is popped from the packet, its payload is
	exposed. If that packet is not IP, and does not have any capability		exposed. If that packet is not IP, and does not have any capability
	equivalent to ECT, it is assumed Not-ECT and treated as such. That		equivalent to ECT, it is assumed Not-ECT, and it is treated as such.
	means that if the EXP value of the MPLS header was CM, the packet		That means that if the EXP value of the MPLS header is CM, the packet
	MUST be dropped.		MUST be dropped.
	Assuming an IP packet was exposed, we have to examine whether that		Assuming an IP packet was exposed, we have to examine whether or not
	packet is ECT or not. A Not-ECT packet MUST be dropped if the EXP		that packet is ECT. A Not-ECT packet MUST be dropped if the EXP
	field is CM.		field is CM.
	For the remainder of this section, we describe the behavior that is		For the remainder of this section, we describe the behavior that is
	required if the ECN information is to be transferred from the MPLS		required if the ECN information is to be transferred from the MPLS
	header into the exposed IP header for onward transmission. As noted		header into the exposed IP header for onward transmission. As noted
	in Section 1.2, such behavior is not mandated by this document, but		in Section 1.2, such behavior is not mandated by this document, but
	may be selected by an operator.		may be selected by an operator.
	If the inner IP packet is Not-ECT, its ECN field remains unchanged if		If the inner IP packet is Not-ECT, its ECN field remains unchanged if
	the EXP field is Not-CM. If the ECN field of the inner packet is set		the EXP field is Not-CM. If the ECN field of the inner packet is set
	to ECT(0), ECT(1) or CE, the ECN field remains unchanged if the EXP		to ECT(0), ECT(1), or CE, the ECN field remains unchanged if the EXP
	field is set to Not-CM. The ECN field is set to CE if the EXP field		field is set to Not-CM. The ECN field is set to CE if the EXP field
	is CM. Note that an inner value of CE and an outer value of not-CM		is CM. Note that an inner value of CE and an outer value of not-CM
	should be considered anomalous, and SHOULD be logged in some way by		should be considered anomalous, and SHOULD be logged in some way by
	the LSR.		the LSR.
	4.7. Diffserv Tunneling Models		4.7. Diffserv Tunneling Models
	[RFC3270] describes three tunneling models for Diffserv support		[RFC3270] describes three tunneling models for Diffserv support
	across MPLS Domains, referred to as the uniform, short pipe, and pipe		across MPLS Domains, referred to as the uniform, short pipe, and pipe
	models. The differences between these models lie in whether the		models. The differences between these models lie in whether the
	Diffserv treatment that applies to a packet while it travels along a		Diffserv treatment that applies to a packet while it travels along a
	particular LSP is carried to the last hop of the LSP and beyond the		particular LSP is carried to the ingress of the last hop, to the
	last hop. Depending on which mode is preferred by an operator, the		egress of the last hop, or beyond the last hop. Depending on which
	EXP value or DSCP value of an exposed header following a label pop		mode is preferred by an operator, the EXP value or DSCP value of an
	may or may not be dependent on the EXP value of the label that is		exposed header following a label pop may or may not be dependent on
	removed by the pop operation. We believe that in the case of ECN		the EXP value of the label that is removed by the pop operation. We
	marking, the use of these models should only apply to the encoding of		believe that, in the case of ECN marking, the use of these models
	the Diffserv PHB in the EXP value, and that the choice of codepoint		should only apply to the encoding of the Diffserv PHB in the EXP
	for ECN should always be made based on the procedures described		value, and that the choice of codepoint for ECN should always be made
	above, independent of the tunneling model.		based on the procedures described above, independent of the tunneling
			model.
	5. ECN-disabled MPLS domain		5. ECN-Disabled MPLS Domain
	If ECN is not enabled on all the egress LSRs of a domain, ECN MUST		If ECN is not enabled on all the egress LSRs of a domain, ECN MUST
	NOT be enabled on any LSRs throughout the domain. If congestion is		NOT be enabled on any LSRs throughout the domain. If congestion is
	experienced on any LSR in an ECN-disabled MPLS domain, packets MUST		experienced on any LSR in an ECN-disabled MPLS domain, packets MUST
	be dropped, NOT marked. The exact algorithm for deciding when to		be dropped; they MUST NOT be marked. The exact algorithm for
	drop packets during congestion (e.g. tail-drop, RED, etc.) is a local		deciding when to drop packets during congestion (e.g., tail-drop,
	matter for the operator of the domain.		RED, etc.) is a local matter for the operator of the domain.
	6. The use of more codepoints with E-LSPs and L-LSPs		6. The Use of More Codepoints with E-LSPs and L-LSPs
	[RFC3270] gives different options with E-LSPs and L-LSPs and some of		[RFC3270] gives different options with E-LSPs and L-LSPs, and some of
	those could potentially provide ample EXP codepoints for ECN.		those could potentially provide ample EXP codepoints for ECN.
	However, deploying L-LSPs vs E-LSPs has many implications such as		However, deploying L-LSPs vs. E-LSPs has many implications, such as
	platform support and operational complexity. The above ECN MPLS		platform support and operational complexity. The above ECN MPLS
	solution should provide some flexibility. If the operator has		solution should provide some flexibility. If the operator has
	deployed one L-LSP per PHB scheduling class, then EXP space will be a		deployed one L-LSP per PHB scheduling class, then EXP space will be a
	non-issue and it could be used to achieve more sophisticated ECN		non-issue, and it could be used to achieve more sophisticated ECN
	behavior if required. If the operator wants to stick to E-LSPs and		behavior if required. If the operator wants to stick to E-LSPs and
	uses a handful of EXP codepoints for Diffserv, it may be desirable to		uses a handful of EXP codepoints for Diffserv, it may be desirable to
	operate with a minimum number of extra ECN codepoints, even if this		operate with a minimum number of extra ECN codepoints, even if this
	comes with some compromise on ECN optimality. See Section 9 for		comes with some compromise on ECN optimality. See Section 9 for
	discussion of some possible deployment scenarios.		discussion of some possible deployment scenarios.
	We note that in a network where L-LSPs are used, ECN marking SHOULD		We note that in a network where L-LSPs are used, ECN marking SHOULD
	NOT cause packets from the same microflow but with different ECN		NOT cause packets from the same microflow, but with different ECN
	markings to be sent on different LSPs. As discussed in [RFC3270],		markings, to be sent on different LSPs. As discussed in [RFC3270],
	packets of a single microflow should always travel on the same LSP to		packets of a single microflow should always travel on the same LSP to
	avoid possible misordering. Thus, ECN marking of packets on L-LSPs		avoid possible misordering. Thus, ECN marking of packets on L-LSPs
	SHOULD only affect the EXP value of the packets.		SHOULD only affect the EXP value of the packets.
	7. Relationship to tunnel behavior in RFC 3168		7. Relationship to Tunnel Behavior in RFC 3168
	[RFC3168] defines two modes of encapsulating ECN-marked IP packets		[RFC3168] defines two modes of encapsulating ECN-marked IP packets
	inside additional IP headers when tunnels are used. The two modes		inside additional IP headers when tunnels are used. The two modes
	are the "full functionality" and "limited functionality" modes. In		are the "full functionality" and "limited functionality" modes. In
	the full functionality mode, the ECT information from the inner		the full functionality mode, the ECT information from the inner
	header is copied to the outer header at the tunnel ingress, but the		header is copied to the outer header at the tunnel ingress, but the
	CE information is not. In the limited functionality mode, neither		CE information is not. In the limited functionality mode, neither
	ECT nor CE information is copied to the outer header, and thus ECN		ECT nor CE information is copied to the outer header, and thus ECN
	cannot be applied to the encapsulated packet.		cannot be applied to the encapsulated packet.
	skipping to change at page 13, line 26		skipping to change at page 11, line 42
	termination marking mechanism proposed for PCN works by only		termination marking mechanism proposed for PCN works by only
	considering packets for marking that have not already been marked		considering packets for marking that have not already been marked
	upstream. Unless existing flow termination marking is copied from		upstream. Unless existing flow termination marking is copied from
	the inner to the outer header at tunnel ingress, the mechanism		the inner to the outer header at tunnel ingress, the mechanism
	doesn't terminate enough traffic in cases where anomalous events hit		doesn't terminate enough traffic in cases where anomalous events hit
	multiple domains at once. [RFC3168] does not give any reasons		multiple domains at once. [RFC3168] does not give any reasons
	against conveying CE information from the inner header to the outer		against conveying CE information from the inner header to the outer
	in the "full functionality" mode. Furthermore, [RFC4301] specifies		in the "full functionality" mode. Furthermore, [RFC4301] specifies
	that the ECN marking should be copied from inner header to outer		that the ECN marking should be copied from inner header to outer
	header in IPSEC tunnels, consistent with the approach defined here.		header in IPSEC tunnels, consistent with the approach defined here.
	[I-D.briscoe-tsvwg-ecn-tunnel] discusses this issue in more detail.		[BRISCOE-ECN] discusses this issue in more detail. In summary, the
	In summary, the approach described in Section 4 appears to be both a		approach described in Section 4 appears to be both a sound technical
	sound technical choice and consistent with the current state of		choice and consistent with the current state of thinking in the IETF.
	thinking in the IETF.
	8. Deployment Considerations		8. Deployment Considerations
	8.1. Marking non-ECN Capable Packets		8.1. Marking Non-ECN-Capable Packets
	What are the consequences of marking a packet that is not ECN-		What are the consequences of marking a packet that is not ECN-
	capable? Even if it will be dropped before leaving the domain,		capable? Even if it will be dropped before leaving the domain,
	doesn't this consume resources unnecessarily?		doesn't this consume resources unnecessarily?
	The problem only arises if there is congestion downstream of an		The problem only arises if there is congestion downstream of an
	earlier congested queue in the same MPLS domain. Downstream		earlier congested queue in the same MPLS domain. Congested LSRs
	congested LSRs might forward packets already marked, even though they		downstream might forward packets already marked, even though they
	will be dropped later when the inner IP header is found to be Not-ECT		will be dropped later when the inner IP header is found to be Not-ECT
	on decapsulation. Such packets might cause the downstream LSRs to		on decapsulation. Such packets might cause the downstream LSRs to
	mark (or drop) other packets that they would otherwise not have had		mark (or drop) other packets that they would otherwise not have had
	to.		to.
	We expect congestion will typically be rare in MPLS networks, but it		We expect congestion will typically be rare in MPLS networks, but it
	might not be. The extra unnecessary load at downstream LSRs will not		might not be. The extra unnecessary load at downstream LSRs will not
	be more than the fraction of marked packets from upstream LSRs, even		be more than the fraction of marked packets from upstream LSRs, even
	in the worst case where no transports are ECN capable. Therefore the		in the worst case where no transports are ECN-capable. Therefore,
	amount of unnecessary marking (or drop) on an LSR will not be more		the amount of unnecessary marking (or drop) on an LSR will not be
	than the product of its local marking rate and the marking rate due		more than the product of its local marking rate and the marking rate
	to upstream LSRs within the same domain - typically the product of		due to upstream LSRs within the same domain -- typically the product
	two small (often zero) probabilities.		of two small (often zero) probabilities.
	This is why we decided to use the per-domain ECT checking approach -		This is why we decided to use the per-domain ECT checking approach --
	because the most likely effect would be a very slightly increased		because the most likely effect would be a very slightly increased
	marking rate, which would result in very slightly higher drop only		marking rate, which would result in very slightly higher drop only
	for non-ECN-capable transports. We chose not to use the [Floyd]		for non-ECN-capable transports. We chose not to use the [Floyd]
	alternative which introduced a low but persistent level of		alternative, which introduced a low but persistent level of
	unnecessary packet drop for all time, even for ECN-capable		unnecessary packet drop for all time, even for ECN-capable
	transports. Although that scheme did not carry traffic to the edge		transports. Although that scheme did not carry traffic to the edge
	of the MPLS domain only to be dropped on decapsulation, we felt our		of the MPLS domain only to be dropped on decapsulation, we felt our
	minor inefficiency was a small price to pay. And it would get		minor inefficiency was a small price to pay; and it would get smaller
	smaller still if ECN deployment widened.		still if ECN deployment widened.
	A partial solution would be to preferentially drop packets arriving		A partial solution would be to preferentially drop packets arriving
	at a congested router that were already marked. There is no solution		at a congested router that were already marked. There is no solution
	to the problem of marking a packet when congestion is caused by		to the problem of marking a packet when congestion is caused by
	another packet that should have been dropped. However, the chance of		another packet that should have been dropped. However, the chance of
	such an occurrence is very low and the consequences are not		such an occurrence is very low, and the consequences are not
	significant. It merely causes an application to very occasionally		significant. It merely causes an application to very occasionally
	slow down its rate when it did not have to.		slow down its rate when it did not have to.
	8.2. Non-ECN capable routers in an MPLS Domain		8.2. Non-ECN-Capable Routers in an MPLS Domain
	What if an MPLS domain wants to use ECN, but not all legacy routers		What if an MPLS domain wants to use ECN, but not all legacy routers
	are able to support it?		are able to support it?
	If the legacy router(s) are used in the interior, this is not a		If the legacy router(s) are used in the interior, this is not a
	problem. They will simply have to drop the packets if they are		problem. They will simply have to drop the packets if they are
	congested, rather than mark them, which is the standard behavior for		congested, rather than mark them, which is the standard behavior for
	IP routers that are not ECN-enabled.		IP routers that are not ECN-enabled.
	If the legacy router were used as an egress router, it would not be		If the legacy router were used as an egress router, it would not be
	able to check the ECN capability of the transport correctly. An		able to check the ECN-capability of the transport correctly. An
	operator in this position would not be able to use this solution and		operator in this position would not be able to use this solution and
	therefore MUST NOT enable ECN unless all egress routers are ECN-		therefore MUST NOT enable ECN unless all egress routers are ECN-
	capable.		capable.
	9. Example Uses		9. Example Uses
	9.1. RFC3168-style ECN		9.1. RFC 3168-Style ECN
	[RFC3168] proposes the use of ECN in TCP and introduces the use of		[RFC3168] proposes the use of ECN in TCP, and it introduces the use
	ECN-Echo and CWR flags in the TCP header for initialization. The TCP		of ECN-Echo and Congestion Window Reduced (CWR) flags in the TCP
	sender responds accordingly (such as not increasing the congestion		header for initialization. The TCP sender responds accordingly (such
	window) when it receives an ECN-Echo (ECE) ACK packet (that is, an		as not increasing the congestion window) when it receives an ECN-Echo
	ACK packet with ECN-Echo flag set in the TCP header), then the sender		(ECE) ACK packet (that is, an ACK packet with ECN-Echo flag set in
	knows that congestion was encountered in the network on the path from		the TCP header), then the sender knows that congestion was
	the sender to the receiver.		encountered in the network on the path from the sender to the
			receiver.
	It would be possible to enable ECN in an MPLS domain for Diffserv		It would be possible to enable ECN in an MPLS domain for Diffserv
	PHBs like AF and best efforts that are expected to be used by TCP and		PHBs like AF and best efforts that are expected to be used by TCP and
	similar transports (e.g. DCCP [RFC4340]). Then end-to-end		similar transports (e.g., DCCP [RFC4340]). Then, end-to-end
	congestion control in transports capable of understanding ECN would		congestion control in transports capable of understanding ECN would
	be able to respond to approaching congestion on LSRs without having		be able to respond to approaching congestion on LSRs without having
	to rely on packet discard to signal congestion.		to rely on packet discard to signal congestion.
	9.2. ECN Co-existence with Diffserv E-LSPs		9.2. ECN Co-Existence with Diffserv E-LSPs
	Many operators today have deployed Diffserv using the E-LSP approach		Many operators today have deployed Diffserv using the E-LSP approach
	of [RFC3270]. In many cases the number of PHBs used is less than 8,		of [RFC3270]. In many cases, the number of PHBs used is less than 8,
	and hence there remain available codepoints in the EXP space. If an		and hence there remain available codepoints in the EXP space. If an
	operator wished to support ECN for single PHB, this can be		operator wished to support ECN for a single PHB, this could be
	accomplished by simply allocated a second codepoint to the PHB for		accomplished by simply allocating a second codepoint to the PHB for
	the "CM" state of that PHB and retaining the old codepoint for the		the CM state of that PHB and retaining the old codepoint for the
	"not-CM" state. An operator with only four deployed PHBs could of		not-CM state. An operator with only four deployed PHBs could, of
	course enable ECN marking on all those PHBs. It is easy to imagine		course, enable ECN marking on all those PHBs. It is easy to imagine
	cases where some PHBs might benefit more from ECN than others - for		cases where some PHBs might benefit more from ECN than others -- for
	example, an operator might use ECN on a premium data service but not		example, an operator might use ECN on a premium data service but not
	on a PHB used for best effort internet traffic.		on a PHB used for best-effort Internet traffic.
	As an illustrative example of how the EXP field might be used in this		As an illustrative example of how the EXP field might be used in this
	case, consider the example of an operator who is using the aggregated		case, consider the example of an operator who is using the aggregated
	service classes proposed in [I-D.ietf-tsvwg-diffserv-class-aggr]. He		service classes proposed in [TSVWG]. He may choose to support ECN
	may choose to support ECN only for the Assured Elastic Treatment		only for the Assured Elastic Treatment Aggregate, using the EXP
	Aggregate, using the EXP codepoint 010 for the not-CM state and 011		codepoint 010 for the not-CM state and 011 for the CM state. All
	for the CM state. All other codepoints could be the same as in		other codepoints could be the same as in [TSVWG]. Of course, any
	[I-D.ietf-tsvwg-diffserv-class-aggr]. Of course any other		other combination of EXP values can be used according to the specific
	combination of EXP values can be used according to the specific set		set of PHBs and marking conventions used within that operator's
	of PHBs and marking conventions used within that operator's network.		network.
	9.3. Congestion-feedback-based Traffic Engineering		9.3. Congestion-Feedback-Based Traffic Engineering
	Shayman's traffic engineering [Shayman] presents another example		Shayman's traffic engineering [Shayman] presents another example
	application of ECN feedback in an MPLS domain. Shayman proposed the		application of ECN feedback in an MPLS domain. Shayman proposed the
	use of ECN by an egress LSR feeding back congestion to an ingress LSR		use of ECN by an egress LSR feeding back congestion to an ingress LSR
	to mitigate congestion by employing dynamic traffic engineering		to mitigate congestion by employing dynamic traffic engineering
	techniques such as shifting flows to an alternate path. It proposed		techniques, such as shifting flows to an alternate path. It proposed
	a new RSVP message which was sent by the egress LSR to the ingress		a new Resource Reservation Protocol (RSVP) message, which was sent by
	LSR (and ignored by transit LSRs) to indicate congestion along the		the egress LSR to the ingress LSR (and ignored by transit LSRs) to
	path. Thus, rather than providing the same style of congestion		indicate congestion along the path. Thus, rather than providing the
	notification to endpoints as defined in [RFC3168], [Shayman] limits		same style of congestion notification to endpoints as defined in
	its scope to the MPLS domain only. This application of ECN in an		[RFC3168], [Shayman] limits its scope to the MPLS domain only. This
	MPLS domain could make use of the ECN encoding in the MPLS header		application of ECN in an MPLS domain could make use of the ECN
	that is defined in this document.		encoding in the MPLS header that is defined in this document.
	9.4. PCN flow admission control and flow termination		9.4. PCN Flow Admission Control and Flow Termination
	[I-D.ietf-pcn-architecture] proposes using pre-congestion		[PCN] proposes using pre-congestion notification (PCN) on routers
	notification (PCN) on routers within an edge-to-edge Diffserv region		within an edge-to-edge Diffserv region to control admission of new
	to control admission of new flows to the region and, if necessary, to		flows to the region and, if necessary, to terminate existing flows in
	terminate existing flows in response to disasters and other anomalous		response to disasters and other anomalous routing events. In this
	routing events. In this approach, the current level of PCN marking		approach, the current level of PCN marking is picked up by the
	is picked up by the signalling used to initiate each flow in order to		signaling used to initiate each flow in order to inform the admission
	inform the admission control decision for the whole region at once.		control decision for the whole region at once. For example,
	For example, extensions to RSVP [I-D.lefaucheur-rsvp-ecn] and NSIS		extensions to RSVP [LEFAUCHEUR] and Next Steps in Signaling (NSIS)
	[I-D.ietf-nsis-rmd], [I-D.arumaithurai-nsis-pcn] have been proposed.		[NSIS], [ARUMAITHURAI] have been proposed.
	If LSRs are able to mark packets to signify congestion in MPLS, PCN		If LSRs are able to mark packets to signify congestion in MPLS, PCN
	marking could be used for admission control and flow termination		marking could be used for admission control and flow termination
	across a Diffserv region, irrespective of whether it contained pure		across a Diffserv region, irrespective of whether it contained pure
	IP routers, MPLS LSRs, or both. Indeed, the solution could be		IP routers, MPLS LSRs, or both. Indeed, the solution could be
	somewhat more efficient to implement if aggregates could identify		somewhat more efficient to implement if aggregates could identify
	themselves by their MPLS label. Appendix A describes the mechanisms		themselves by their MPLS label. Appendix A describes the mechanisms
	by which the necessary markings for PCN could be carried in the MPLS		by which the necessary markings for PCN could be carried in the MPLS
	header.		header.
	10. IANA Considerations		10. Security Considerations
	This document makes no request of IANA.
	Note to RFC Editor: this section may be removed on publication as an
	RFC.
	11. Security Considerations
	We believe no new vulnerabilities are introduced by this draft.		We believe no new vulnerabilities are introduced by this document.
	We have considered whether malicious sources might be able to exploit		We have considered whether malicious sources might be able to exploit
	the fact that interior LSRs will mark packets that are Not-ECT,		the fact that interior LSRs will mark packets that are Not-ECT,
	relying on their egress LSR to drop them. Although this might allow		relying on their egress LSR to drop them. Although this might allow
	sources to engineer a situation where more traffic is carried across		sources to engineer a situation where more traffic is carried across
	an MPLS domain than should be, we figured that even if we hadn't		an MPLS domain than should be, we figured that even if we hadn't
	introduced this feature, these sources would have been able to		introduced this feature, these sources would have been able to
	prevent these LSRs dropping this traffic anyway, simply by setting		prevent these LSRs dropping this traffic anyway, simply by setting
	ECT in the first place.		ECT in the first place.
	An ECN sender can use the ECN nonce [RFC3540] to detect a misbehaving		An ECN sender can use the ECN nonce [RFC3540] to detect a misbehaving
	receiver. The ECN nonce works correctly across an MPLS domain		receiver. The ECN nonce works correctly across an MPLS domain
	without requiring any specific support from the proposal in this		without requiring any specific support from the proposal in this
	draft. The nonce does not need to be present in the MPLS shim		document. The nonce does not need to be present in the MPLS shim
	header. As long as the nonce is present in the IP header when the		header to detect a misbehaving receiver. As long as the nonce is
	ECN information is copied from the last MPLS shim header, it will be		present in the IP header when the ECN information is copied from the
	overwritten if congestion has been experienced by an LSR. This is		last MPLS shim header, it will be overwritten if congestion has been
	all that is necessary for the sender to detect a misbehaving		experienced by an LSR. This is all that is necessary for the sender
	receiver.		to detect a misbehaving receiver. If there were a need for an ECN
			nonce in the MPLS shim header (e.g., to detect if one LSR were
			erasing the markings of an upstream LSR in the same domain), we
			believe this proposal does not preclude the later addition of an ECN
			nonce capability for specific DSCPs, just as it does not preclude any
			other use of the EXP codepoints.
	12. Acknowledgments		11. Acknowledgments
	Thanks to K.K. Ramakrishnan and Sally Floyd for getting us thinking		Thanks to K.K. Ramakrishnan and Sally Floyd for getting us thinking
	about this in the first place and for providing advice on tunneling		about this in the first place and for providing advice on tunneling
	of ECN packets, and to Sally Floyd, Joe Babiarz, Ben Niven-Jenkins,		of ECN packets, and to Sally Floyd, Joe Babiarz, Ben Niven-Jenkins,
	Phil Eardley, Ruediger Geib, and Magnus Westerlund for their comments		Phil Eardley, Ruediger Geib, and Magnus Westerlund for their comments
	on the draft.		on the document.
	Appendix A. Extension to Pre-Congestion Notification		Appendix A. Extension to Pre-Congestion Notification
	This appendix describes how the mechanisms decribed in the body of		This appendix describes how the mechanisms described in the body of
	the document can be extended to support PCN		the document can be extended to support PCN [PCN]. Our intent here
	[I-D.ietf-pcn-architecture]. Our intent here is to show that the		is to show that the mechanisms are readily extended to more complex
	mechanisms are readily extended to more complex scenarios than ECN,		scenarios than ECN, particularly in the case where more codepoints
	particulary in the case where more codepoints are needed, but this		are needed, but this appendix may be safely ignored if one is
	appendix may be safely ignored if one is interested only in		interested only in supporting ECN. Note that the PCN standards are
	supporting ECN. Note that the PCN standards are still very much		still very much under development at the time of writing; hence, the
	under development at the time of writing, hence the precise details		precise details contained in this appendix may be subject to change,
	contained in this appendix may be subject to change, and we stress		and we stress that this appendix is for illustrative purposes only.
	that this appendix is for illustrative purposes only.
	The relevant aspects of PCN for the purposes of this discussion are:		The relevant aspects of PCN for the purposes of this discussion are:
	o PCN uses 3 states rather than 2 for ECN - these are referred to as		o PCN uses 3 states rather than 2 for ECN -- these are referred to
	admission marked (AM), termination marked (TM) and not marked (NM)		as admission marked (AM), termination marked (TM), and not marked
	states. (See Section 9.4 for further discussion of PCN and the		(NM) states. (See Section 9.4 for further discussion of PCN and
	possibility of using fewer codepoints.)		the possibility of using fewer codepoints).
	o A packet can go from NM to AM, from NM to TM, or from AM to TM,		o A packet can go from NM to AM, from NM to TM, or from AM to TM,
	but no other transition is possible.		but no other transition is possible.
	o The determination of whether a packet is subject to PCN is based		o The determination of whether a packet is subject to PCN is based
	on the PHB of the packet.		on the PHB of the packet.
	Thus, to support PCN fully in an MPLS domain for a particular PHB, a		Thus, to support PCN fully in an MPLS domain for a particular PHB, a
	total of 3 codepoints need to be allocated for that PHB. These 3		total of 3 codepoints need to be allocated for that PHB. These 3
	codepoints represent the admission marked (AM), termination marked		codepoints represent the admission marked (AM), termination marked
	(TM) and not marked (NM) states. The procedures described in		(TM), and not marked (NM) states. The procedures described in
	Section 4 above need to be slightly modified to support this		Section 4 above need to be slightly modified to support this
	scenario. The following procedures are invoked when the topmost DSCP		scenario. The following procedures are invoked when the topmost DSCP
	or EXP value indicates a PHB that supports PCN.		or EXP value indicates a PHB that supports PCN.
	Appendix A.1. Label Push onto IP packet		A.1. Label Push onto IP Packet
	If the IP packet header indicates AM, set the EXP value of all		If the IP packet header indicates AM, set the EXP value of all
	entries in the label stack to AM. If the IP packet header indicates		entries in the label stack to AM. If the IP packet header indicates
	TM, set the EXP value of all entries in the label stack to TM. For		TM, set the EXP value of all entries in the label stack to TM. For
	any other marking of the IP header, set the EXP value of all entries		any other marking of the IP header, set the EXP value of all entries
	in the label stack to NM.		in the label stack to NM.
	Appendix A.2. Pushing Additional MPLS Labels		A.2. Pushing Additional MPLS Labels
	The procedures of Section 4.2 apply.		The procedures of Section 4.2 apply.
	Appendix A.3. Admission Control or Flow Termination Marking inside MPLS		A.3. Admission Control or Flow Termination Marking Inside MPLS Domain
	domain
	The EXP value can be set to AM or TM according to the same procedures		The EXP value can be set to AM or TM according to the same procedures
	as described in [I-D.briscoe-tsvwg-cl-phb]. For the purposes of this		as described in [BRISCOE-CL]. For the purposes of this document, it
	document, it does not matter exactly what algorithms are used to		does not matter exactly which algorithms are used to decide when to
	decide when to set AM or TM; all that matters is that if a router		set AM or TM; all that matters is that if a router would have marked
	would have marked AM (or TM) in the IP header, it should set the EXP		AM (or TM) in the IP header, it should set the EXP value in the MPLS
	value in the MPLS header to the AM (or TM) codepoint.		header to the AM (or TM) codepoint.
	Appendix A.4. Popping an MPLS Label (not end of stack)		A.4. Popping an MPLS Label (Not End of Stack)
	When popping an MPLS Label exposes another MPLS label, the AM or TM		When popping an MPLS Label exposes another MPLS label, the AM or TM
	marking should be transferred to the exposed EXP field in the		marking should be transferred to the exposed EXP field in the
	following manner:		following manner:
	o If the inner EXP value is NM, then it should be set to the same		o If the inner EXP value is NM, then it should be set to the same
	marking state as the EXP value of the popped label stack entry.		marking state as the EXP value of the popped label stack entry.
	o If the inner EXP value is AM, it should be unchanged if the popped		o If the inner EXP value is AM, it should be unchanged if the popped
	EXP value was AM, and it should be set to TM if the popped EXP		EXP value was AM, and it should be set to TM if the popped EXP
	value was TM. If the popped EXP value was NM, this should be		value was TM. If the popped EXP value was NM, this should be
	logged in some way and the inner EXP value should be unchanged.		logged in some way, and the inner EXP value should be unchanged.
	o If the inner EXP value is TM, it should be unchanged whatever the		o If the inner EXP value is TM, it should be unchanged whatever the
	popped EXP value was, but any EXP value other than TM should be		popped EXP value was, but any EXP value other than TM should be
	logged.		logged.
	Appendix A.5. Popping the last MPLS Label to expose IP header		A.5. Popping the Last MPLS Label to Expose IP Header
	When popping the last MPLS Label exposes the IP header, there are two		When popping the last MPLS Label exposes the IP header, there are two
	cases to consider:		cases to consider:
	o the popping LSR is NOT the egress router of the PCN region, in		o the popping LSR is *not* the egress router of the PCN region, in
	which case AM or TM marking should be transferred to the exposed		which case AM or TM marking should be transferred to the exposed
	IP header field; or		IP header field; or
	o the popping LSR IS the egress router of the PCN region.		o the popping LSR *is* the egress router of the PCN region.
	In the latter case, the behavior of the egress LSR is defined in		In the latter case, the behavior of the egress LSR is defined in
	[I-D.ietf-pcn-architecture] and is beyond the scope of this document.		[PCN] and is beyond the scope of this document. In the former case,
	In the former case, the marking should be transferred from the popped		the marking should be transferred from the popped MPLS header to the
	MPLS header to the exposed IP header as follows:		exposed IP header as follows:
	o If the inner IP header value is neither AM nor TM, and the EXP		o If the inner IP header value is neither AM nor TM, and the EXP
	value was NM, then the IP header should be unchanged. For any		value was NM, then the IP header should be unchanged. For any
	other EXP value, the IP header should be set to the same marking		other EXP value, the IP header should be set to the same marking
	state as the EXP value of the popped label stack entry.		state as the EXP value of the popped label stack entry.
	o If the inner IP header value is AM, it should be unchanged if the		o If the inner IP header value is AM, it should be unchanged if the
	popped EXP value was AM, and it should be set to TM if the popped		popped EXP value was AM, and it should be set to TM if the popped
	EXP value was TM. If the popped EXP value was NM, this should be		EXP value was TM. If the popped EXP value was NM, this should be
	logged in some way and the inner IP header value should be		logged in some way and the inner IP header value should be
	unchanged.		unchanged.
	o If the IP header value is TM, it should be unchanged whatever the		o If the IP header value is TM, it should be unchanged whatever the
	popped EXP value was, but any EXP value other than TM should be		popped EXP value was, but any EXP value other than TM should be
	logged.		logged.
	13. References		Normative References
	13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
	Label Switching Architecture", RFC 3031, January 2001.		"Multiprotocol Label Switching Architecture",
			RFC 3031, January 2001.
	[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,		[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
	Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack		Farinacci, D., Li, T., and A. Conta, "MPLS Label
	Encoding", RFC 3032, January 2001.		Stack Encoding", RFC 3032, January 2001.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
	of Explicit Congestion Notification (ECN) to IP",		Addition of Explicit Congestion Notification (ECN) to
	RFC 3168, September 2001.		IP", RFC 3168, September 2001.
	[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,		[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
	P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-		Vaananen, P., Krishnan, R., Cheval, P., and J.
	Protocol Label Switching (MPLS) Support of Differentiated		Heinanen, "Multi-Protocol Label Switching (MPLS)
	Services", RFC 3270, May 2002.		Support of Differentiated Services", RFC 3270,
			May 2002.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	13.2. Informative References		Informative References
	[Floyd] "A Proposal to Incorporate ECN in MPLS", 1999.
	Work in progress. http://www.icir.org/floyd/papers/
	draft-ietf-mpls-ecn-00.txt
	[I-D.arumaithurai-nsis-pcn]		[ARUMAITHURAI] Arumaithurai, M., "NSIS PCN-QoSM: A Quality of
	Arumaithurai, M., "NSIS PCN-QoSM: A Quality of Service		Service Model for Pre-Congestion Notification (PCN)",
	Model for Pre-Congestion Notification (PCN)",		Work in Progress, September 2007.
	draft-arumaithurai-nsis-pcn-00 (work in progress),
	September 2007.
	[I-D.briscoe-tsvwg-cl-phb]		[BRISCOE-CL] Briscoe, B., "Pre-Congestion Notification Marking",
	Briscoe, B., "Pre-Congestion Notification marking",		Work in Progress, October 2006.
	draft-briscoe-tsvwg-cl-phb-03 (work in progress),
	October 2006.
	[I-D.briscoe-tsvwg-ecn-tunnel]		[BRISCOE-ECN] Briscoe, B., "Layered Encapsulation of Congestion
	Briscoe, B., "Layered Encapsulation of Congestion		Notification", Work in Progress, July 2007.
	Notification", draft-briscoe-tsvwg-ecn-tunnel-00 (work in
	progress), July 2007.
	[I-D.ietf-nsis-rmd]		[Floyd] Ramakrishnan, K., Floyd, S., and B. Davie, "A
	Bader, A., "RMD-QOSM - The Resource Management in Diffserv		Proposal to Incorporate ECN in MPLS", Work in
	QOS Model", draft-ietf-nsis-rmd-11 (work in progress),		Progress, June 1999.
	August 2007.
	[I-D.ietf-pcn-architecture]		[LEFAUCHEUR] Faucheur, F., Charny, A., Briscoe, B., Eardley, P.,
	Eardley, P., "Pre-Congestion Notification Architecture",		Barbiaz, J., and K. Chan, "RSVP Extensions for
	draft-ietf-pcn-architecture-00 (work in progress),		Admission Control over Diffserv using Pre-congestion
	August 2007.		Notification (PCN)", Work in Progress, June 2006.
	[I-D.ietf-tsvwg-diffserv-class-aggr]		[NSIS] Bader, A., Westberg, L., Karagiannis, G., Cornelia,
	Chan, K., "Aggregation of DiffServ Service Classes",		C., and T. Phelan, "RMD-QOSM - The Resource
	draft-ietf-tsvwg-diffserv-class-aggr-04 (work in		Management in Diffserv QOS Model", Work in Progress,
	progress), August 2007.		November 2007.
	[I-D.lefaucheur-rsvp-ecn]		[PCN] Eardley, P., "Pre-Congestion Notification
	Faucheur, F., "RSVP Extensions for Admission Control over		Architecture", Work in Progress, November 2007.
	Diffserv using Pre-congestion Notification (PCN)",
	draft-lefaucheur-rsvp-ecn-01 (work in progress),
	June 2006.
	[RFC3260] Grossman, D., "New Terminology and Clarifications for		[RFC3260] Grossman, D., "New Terminology and Clarifications for
	Diffserv", RFC 3260, April 2002.		Diffserv", RFC 3260, April 2002.
	[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit		[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust
	Congestion Notification (ECN) Signaling with Nonces",		Explicit Congestion Notification (ECN) Signaling with
	RFC 3540, June 2003.		Nonces", RFC 3540, June 2003.
	[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram		[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
	Congestion Control Protocol (DCCP)", RFC 4340, March 2006.		Congestion Control Protocol (DCCP)", RFC 4340,
			March 2006.
	[Shayman] "Using ECN to Signal Congestion Within an MPLS Domain",		[Shayman] Shayman, M. and R. Jaeger, "Using ECN to Signal
	2000.		Congestion Within an MPLS Domain", Work in Progress,
			November 2000.
	Work in progress. http://www.ee.umd.edu/~shayman/papers.d/		[TSVWG] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
	draft-shayman-mpls-ecn-00.txt		DiffServ Service Classes", Work in Progress,
			November 2007.
	Authors' Addresses		Authors' Addresses
	Bruce Davie		Bruce Davie
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1414 Mass. Ave.		1414 Mass. Ave.
	Boxborough, MA 01719		Boxborough, MA 01719
	USA		USA
	Email: bsd@cisco.com		EMail: bsd@cisco.com
	Bob Briscoe		Bob Briscoe
	BT Research		BT Research
	B54/77, Sirius House		B54/77, Sirius House
	Adastral Park		Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich		Ipswich
	Suffolk IP5 3RE		Suffolk IP5 3RE
	United Kingdom		United Kingdom
	Email: bob.briscoe@bt.com		EMail: bob.briscoe@bt.com
	June Tay		June Tay
	BT Research		BT Research
	B54/77, Sirius House		B54/77, Sirius House
	Adastral Park		Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich		Ipswich
	Suffolk IP5 3RE		Suffolk IP5 3RE
	United Kingdom		United Kingdom
	Email: june.tay@bt.com		EMail: june.tay@bt.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	skipping to change at page 23, line 44		skipping to change at line 907
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgments
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA). This document was produced
	using xml2rfc v1.32 (of http://xml.resource.org/) from a source in
	RFC-2629 XML format.
End of changes. 128 change blocks.
	428 lines changed or deleted		331 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/