draft-davie-ecn-mpls-01.txt		draft-ietf-tsvwg-ecn-mpls-00.txt
	Network Working Group B. Davie		Network Working Group B. Davie
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track B. Briscoe		Intended status: Standards Track B. Briscoe
	Expires: April 21, 2007 J. Tay		Expires: August 24, 2007 J. Tay
	BT Research		BT Research
	October 18, 2006		February 20, 2007
	Explicit Congestion Marking in MPLS		Explicit Congestion Marking in MPLS
	draft-davie-ecn-mpls-01.txt		draft-ietf-tsvwg-ecn-mpls-00.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 April 21, 2007.		This Internet-Draft will expire on August 24, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	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 draft defines how an operator might define
	some of the EXP codepoints for explicit congestion notification,		some of the EXP codepoints for explicit congestion notification,
	skipping to change at page 3, line 8		skipping to change at page 3, line 8
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Changes From Previous (-00) Version . . . . . . . . . . . 4		1.1. Change History . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 6		2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 6
	3. Per-domain ECT checking . . . . . . . . . . . . . . . . . . . 8		3. Per-domain ECT checking . . . . . . . . . . . . . . . . . . . 8
	4. ECN-enabled MPLS domain . . . . . . . . . . . . . . . . . . . 9		4. ECN-enabled MPLS domain . . . . . . . . . . . . . . . . . . . 9
	4.1. Pushing (adding) one or more labels to an IP packet . . . 9		4.1. Pushing (adding) one or more labels to an IP packet . . . 9
	4.2. Pushing one or more labels onto an MPLS labelled packet . 9		4.2. Pushing one or more labels onto an MPLS labelled packet . 9
	4.3. Congestion experienced in an interior MPLS node . . . . . 9		4.3. Congestion experienced in an interior MPLS node . . . . . 9
	4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 9		4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 10
	4.5. Popping an MPLS label (not the end of the stack) . . . . . 10		4.5. Popping an MPLS label (not the end of the stack) . . . . . 10
	4.6. Popping the last MPLS label in the stack . . . . . . . . . 10		4.6. Popping the last MPLS label in the stack . . . . . . . . . 10
	4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 11		4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 11
	4.8. Extension to Pre-Congestion Notification . . . . . . . . . 11		4.8. Extension to Pre-Congestion Notification . . . . . . . . . 11
	4.8.1. Label Push onto IP packet . . . . . . . . . . . . . . 12		4.8.1. Label Push onto IP packet . . . . . . . . . . . . . . 12
	4.8.2. Pushing Additional MPLS Labels . . . . . . . . . . . . 12		4.8.2. Pushing Additional MPLS Labels . . . . . . . . . . . . 12
	4.8.3. Admission Control or Pre-emption Marking inside		4.8.3. Admission Control or Pre-emption Marking inside
	MPLS domain . . . . . . . . . . . . . . . . . . . . . 12		MPLS domain . . . . . . . . . . . . . . . . . . . . . 12
	4.8.4. Popping an MPLS Label (not end of stack) . . . . . . . 12		4.8.4. Popping an MPLS Label (not end of stack) . . . . . . . 12
	4.8.5. Popping the last MPLS Label to expose IP header . . . 12		4.8.5. Popping the last MPLS Label to expose IP header . . . 12
	5. ECN-disabled MPLS domain . . . . . . . . . . . . . . . . . . . 13		5. ECN-disabled MPLS domain . . . . . . . . . . . . . . . . . . . 13
	6. The use of more codepoints with E-LSPs and L-LSPs . . . . . . 13		6. The use of more codepoints with E-LSPs and L-LSPs . . . . . . 13
	7. Relationship to tunnel behavior in RFC 3168 . . . . . . . . . 13		7. Relationship to tunnel behavior in RFC 3168 . . . . . . . . . 14
	7.1. Alternative approach to support ECN in an MPLS domain . . 14		7.1. Alternative approach to support ECN in an MPLS domain . . 14
	8. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 15		8. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. RFC3168-style ECN . . . . . . . . . . . . . . . . . . . . 15		8.1. RFC3168-style ECN . . . . . . . . . . . . . . . . . . . . 15
	8.2. ECN Co-existence with Diffserv E-LSPs . . . . . . . . . . 15		8.2. ECN Co-existence with Diffserv E-LSPs . . . . . . . . . . 15
	8.3. Congestion-feedback-based Traffic Engineering . . . . . . 16		8.3. Congestion-feedback-based Traffic Engineering . . . . . . 16
	8.4. PCN flow admission control and flow pre-emption . . . . . 16		8.4. PCN flow admission control and flow pre-emption . . . . . 16
	9. Deployment Considerations . . . . . . . . . . . . . . . . . . 17		9. Deployment Considerations . . . . . . . . . . . . . . . . . . 17
	9.1. Marking non-ECN Capable Packets . . . . . . . . . . . . . 17		9.1. Marking non-ECN Capable Packets . . . . . . . . . . . . . 17
	9.2. Non-ECN capable routers in an MPLS Domain . . . . . . . . 17		9.2. Non-ECN capable routers in an MPLS Domain . . . . . . . . 18
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 18		11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 19		13.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	13.2. Informative References . . . . . . . . . . . . . . . . . . 20		13.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . . . 22		Intellectual Property and Copyright Statements . . . . . . . . . . 22
	1. Introduction		1. Introduction
	1.1. Changes From Previous (-00) Version		1.1. Change History
	[Note to RFC Editor: This section to be removed before publication]		[Note to RFC Editor: This section to be removed before publication]
			This version (draft-ietf-tsvwg-ecn-mpls-00.txt) differs from the last
			(draft-davie-mpls-ecn-01.txt) only in title, date, and updated
			references.
			Changes from draft-davie-ecn-mpls-00 to draft-davie-ecn-mpls-01:
	o Corrected the description of ECN-MPLS marking proposed in		o Corrected the description of ECN-MPLS marking proposed in
	[Shayman], which closely corresponds to that proposed in this		[Shayman], which closely corresponds to that proposed in this
	document.		document.
	o Pre-congestion notification (PCN) marking is now described in a		o Pre-congestion notification (PCN) marking is now described in a
	way that does not require normative references to PCN		way that does not require normative references to PCN
	specifications. PCN discussion now serves only to illustrate how		specifications. PCN discussion now serves only to illustrate how
	the ECN marking concepts can be extended to cover more complex		the ECN marking concepts can be extended to cover more complex
	scenarios, with PCN being an example.		scenarios, with PCN being an example.
	skipping to change at page 7, line 44		skipping to change at page 7, line 50
	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 LSRs 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.
	skipping to change at page 19, line 11		skipping to change at page 19, line 19
	misbehavior by senders or receivers or other routers. Like the ECN		misbehavior by senders or receivers or other routers. Like the ECN
	nonce, it works correctly without requiring any specific support from		nonce, it works correctly without requiring any specific support from
	the proposal in this draft. It uses a bit in the IP header (the RE		the proposal in this draft. It uses a bit in the IP header (the RE
	bit) which is set by the sender and never changed along the path-it		bit) which is set by the sender and never changed along the path-it
	is only read by certain policing elements in the network. There is		is only read by certain policing elements in the network. There is
	no need for a copy of this bit in the MPLS shim, as policing nodes		no need for a copy of this bit in the MPLS shim, as policing nodes
	can examine the IP header if they need to, particularly given they		can examine the IP header if they need to, particularly given they
	are intended to only be necessary at domain borders where MPLS		are intended to only be necessary at domain borders where MPLS
	headers are often removed.		headers are often removed.
	12. Acknowledgements		12. 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 Joe Babiarz, Ben Niven-Jenkins, Phil Eardley,		of ECN packets, and to Joe Babiarz, Ben Niven-Jenkins, Phil Eardley,
	and Ruediger Geib for their comments on the draft.		and Ruediger Geib for their comments on the draft.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	skipping to change at page 20, line 15		skipping to change at page 20, line 20
	13.2. Informative References		13.2. Informative References
	[Floyd] "A Proposal to Incorporate ECN in MPLS", 1999.		[Floyd] "A Proposal to Incorporate ECN in MPLS", 1999.
	Work in progress. http://www.icir.org/floyd/papers/		Work in progress. http://www.icir.org/floyd/papers/
	draft-ietf-mpls-ecn-00.txt		draft-ietf-mpls-ecn-00.txt
	[I-D.briscoe-tsvwg-cl-architecture]		[I-D.briscoe-tsvwg-cl-architecture]
	Briscoe, B., "An edge-to-edge Deployment Model for Pre-		Briscoe, B., "An edge-to-edge Deployment Model for Pre-
	Congestion Notification: Admission Control over a		Congestion Notification: Admission Control over a
	DiffServ Region", draft-briscoe-tsvwg-cl-architecture-03		DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04
	(work in progress), June 2006.		(work in progress), October 2006.
	[I-D.briscoe-tsvwg-cl-phb]		[I-D.briscoe-tsvwg-cl-phb]
	Briscoe, B., "Pre-Congestion Notification marking",		Briscoe, B., "Pre-Congestion Notification marking",
	draft-briscoe-tsvwg-cl-phb-02 (work in progress),		draft-briscoe-tsvwg-cl-phb-03 (work in progress),
	June 2006.		October 2006.
	[I-D.briscoe-tsvwg-re-ecn-border-cheat]		[I-D.briscoe-tsvwg-re-ecn-border-cheat]
	Briscoe, B., "Emulating Border Flow Policing using Re-ECN		Briscoe, B., "Emulating Border Flow Policing using Re-ECN
	on Bulk Data", draft-briscoe-tsvwg-re-ecn-border-cheat-01		on Bulk Data", draft-briscoe-tsvwg-re-ecn-border-cheat-01
	(work in progress), June 2006.		(work in progress), June 2006.
	[I-D.briscoe-tsvwg-re-ecn-tcp]		[I-D.briscoe-tsvwg-re-ecn-tcp]
	Briscoe, B., "Re-ECN: Adding Accountability for Causing		Briscoe, B., "Re-ECN: Adding Accountability for Causing
	Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-02		Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-03
	(work in progress), June 2006.		(work in progress), October 2006.
	[I-D.chan-tsvwg-diffserv-class-aggr]		[I-D.chan-tsvwg-diffserv-class-aggr]
	Chan, K., "Aggregation of DiffServ Service Classes",		Chan, K., "Aggregation of DiffServ Service Classes",
	draft-chan-tsvwg-diffserv-class-aggr-03 (work in		draft-chan-tsvwg-diffserv-class-aggr-03 (work in
	progress), January 2006.		progress), January 2006.
	[I-D.ietf-nsis-rmd]		[I-D.ietf-nsis-rmd]
	Bader, A., "RMD-QOSM - The Resource Management in Diffserv		Bader, A., "RMD-QOSM - The Resource Management in Diffserv
	QOS Model", draft-ietf-nsis-rmd-07 (work in progress),		QOS Model", draft-ietf-nsis-rmd-08 (work in progress),
	June 2006.		October 2006.
	[I-D.lefaucheur-rsvp-ecn]		[I-D.lefaucheur-rsvp-ecn]
	Faucheur, F., "RSVP Extensions for Admission Control over		Faucheur, F., "RSVP Extensions for Admission Control over
	Diffserv using Pre-congestion Notification (PCN)",		Diffserv using Pre-congestion Notification (PCN)",
	draft-lefaucheur-rsvp-ecn-01 (work in progress),		draft-lefaucheur-rsvp-ecn-01 (work in progress),
	June 2006.		June 2006.
	[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit		[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
	Congestion Notification (ECN) Signaling with Nonces",		Congestion Notification (ECN) Signaling with Nonces",
	RFC 3540, June 2003.		RFC 3540, June 2003.
	skipping to change at page 22, line 7		skipping to change at page 22, line 7
	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 Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	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 AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 20 change blocks.
	26 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/