draft-ietf-mpls-ecmp-bcp-03.txt		rfc4928.txt
	Network Working Group George Swallow		Network Working Group G. Swallow
	Internet Draft Cisco Systems, Inc.		Request for Comments: 4928 S. Bryant
	Category: Standards Track		BCP: 128 Cisco Systems, Inc.
	Expiration Date: August 2007		Category: Best Current Practice L. Andersson
	Stewart Bryant		Acreo AB
	Cisco Systems, Inc.
	Loa Andersson
	Acreo
	February 2007
	Avoiding Equal Cost Multipath Treatment in MPLS Networks		Avoiding Equal Cost Multipath Treatment in MPLS Networks
	draft-ietf-mpls-ecmp-bcp-03.txt		Status of This Memo
	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		This document specifies an Internet Best Current Practices for the
	and may be updated, replaced, or obsoleted by other documents at any		Internet Community, and requests discussion and suggestions for
	time. It is inappropriate to use Internet-Drafts as reference		improvements. Distribution of this memo is unlimited.
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		Copyright Notice
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		Copyright (C) The IETF Trust (2007).
	http://www.ietf.org/shadow.html
	Abstract		Abstract
	This document describes the Equal Cost Multipath (ECMP) behavior of		This document describes the Equal Cost Multipath (ECMP) behavior of
	currently deployed MPLS networks. This document makes best practice		currently deployed MPLS networks. This document makes best practice
	recommendations for anyone defining an application to run over an		recommendations for anyone defining an application to run over an
	MPLS network that wishes to avoid the reordering that can result from		MPLS network that wishes to avoid the reordering that can result from
	transmission of different packets from the same flow over multiple		transmission of different packets from the same flow over multiple
	different equal cost paths.		different equal cost paths. These recommendations rely on inspection
			of the IP version number field in packets. Despite the heuristic
			nature of the recommendations, they provide a relatively safe way to
			operate MPLS networks, even if future allocations of IP version
			numbers were made for some purpose.
	Contents		Table of Contents
	1 Introduction .............................................. 3		1. Introduction ....................................................2
	1.1 Terminology ............................................... 3		1.1. Terminology ................................................2
	2 Current ECMP Practices .................................... 3		2. Current ECMP Practices ..........................................2
	3 Recommendations for Avoiding ECMP Treatment ............... 5		3. Recommendations for Avoiding ECMP Treatment .....................4
	4 Security Considerations ................................... 6		4. Security Considerations .........................................5
	5 References ................................................ 6		5. IANA Considerations .............................................5
	5.1 Normative References ...................................... 6		6. References ......................................................6
	5.2 Informative References .................................... 7		6.1. Normative References .......................................6
	6 Authors' Addresses ........................................ 8		6.2. Informative References .....................................6
	1. Introduction		1. Introduction
	This document describes the Equal Cost Multipath (ECMP) behavior of		This document describes the Equal Cost Multipath (ECMP) behavior of
	currently deployed MPLS networks. We discuss cases where multiple		currently deployed MPLS networks. We discuss cases where multiple
	packets from the same top-level LSP might be transmitted over differ-		packets from the same top-level LSP might be transmitted over
	ent equal cost paths, resulting in possible mis-ordering of packets		different equal cost paths, resulting in possible mis-ordering of
	which are part of the same top-level LSP. This document also makes		packets that are part of the same top-level LSP. This document also
	best practice recommendations for anyone defining an application to		makes best practice recommendations for anyone defining an
	run over an MPLS network that wishes to avoid the resulting potential		application to run over an MPLS network that wishes to avoid the
	for mis-ordered packets. While disabling ECMP behavior is an option		resulting potential for mis-ordered packets. While disabling ECMP
	open to most operators, few (if any) have chosen to do so, and the		behavior is an option open to most operators, few (if any) have
	application designer does not have control over the behavior of the		chosen to do so, and the application designer does not have control
	networks that the application may run over. Thus ECMP behavior is a		over the behavior of the networks that the application may run over.
	reality that must be reckoned with.		Thus, ECMP behavior is a reality that must be reckoned with.
	1.1. Terminology		1.1. Terminology
	ECMP Equal Cost Multipath		ECMP Equal Cost Multipath
	FEC Forwarding Equivalence Class		FEC Forwarding Equivalence Class
	IP ECMP A forwarding behavior in which the selection of the		IP ECMP A forwarding behavior in which the selection of the
	next-hop between equal cost routes is based on the		next-hop between equal cost routes is based on the
	header(s) of an IP packet		header(s) of an IP packet
	Label ECMP A forwarding behavior in which the selection of the		Label ECMP A forwarding behavior in which the selection of the
	next-hop between equal cost routes is based on the		next-hop between equal cost routes is based on the label
	label stack of an MPLS packet		stack of an MPLS packet
	LSP Label Switched Path		LSP Label Switched Path
	LSR Label Switching Router		LSR Label Switching Router
	2. Current ECMP Practices		2. Current ECMP Practices
	The MPLS label stack and Forwarding Equivalence Classes are defined		The MPLS label stack and Forwarding Equivalence Classes are defined
	in [RFC3031]. The MPLS label stack does not carry a Protocol Identi-		in [RFC3031]. The MPLS label stack does not carry a Protocol
	fier. Instead the payload of an MPLS packet is identified by the		Identifier. Instead the payload of an MPLS packet is identified by
	Forwarding Equivalence Class (FEC) of the bottom most label. Thus it		the Forwarding Equivalence Class (FEC) of the bottom most label.
	is not possible to know the payload type if one does not know the		Thus, it is not possible to know the payload type if one does not
	label binding for the bottom most label. Since an LSR which is pro-		know the label binding for the bottom most label. Since an LSR,
	cessing a label stack need only know the binding for the label(s) it		which is processing a label stack, need only know the binding for the
	must process, it is very often the case that LSRs along an LSP are		label(s) it must process, it is very often the case that LSRs along
	unable to determine the payload type of the carried contents.		an LSP are unable to determine the payload type of the carried
			contents.
	As a means of potentially reducing delay and congestion, IP networks		As a means of potentially reducing delay and congestion, IP networks
	have taken advantage of multiple paths through a network by splitting		have taken advantage of multiple paths through a network by splitting
	traffic flows across those paths. The general name for this practice		traffic flows across those paths. The general name for this practice
	is Equal Cost Multipath or ECMP. In general this is done by hashing		is Equal Cost Multipath or ECMP. In general, this is done by hashing
	on various fields on the IP or contained headers. In practice,		on various fields on the IP or contained headers. In practice,
	within a network core, the hashing is based mainly or exclusively on		within a network core, the hashing is based mainly or exclusively on
	the IP source and destination addresses. The reason for splitting		the IP source and destination addresses. The reason for splitting
	aggregated flows in this manner is to minimize the re-ordering of		aggregated flows in this manner is to minimize the re-ordering of
	packets belonging to individual flows contained within the aggregated		packets belonging to individual flows contained within the aggregated
	flow. Within this document we use the term IP ECMP for this type of		flow. Within this document, we use the term IP ECMP for this type of
	forwarding algorithm.		forwarding algorithm.
	For packets that contain both a label stack and an encapsulated IPv4		For packets that contain both a label stack and an encapsulated IPv4
	(or IPv6) packet, current implementations in some cases may hash on		(or IPv6) packet, current implementations in some cases may hash on
	any combination of labels and IPv4 (or IPv6) source and destination		any combination of labels and IPv4 (or IPv6) source and destination
	labels.		addresses.
	In the early days of MPLS, the payload was almost exclusively IP.		In the early days of MPLS, the payload was almost exclusively IP.
	Even today the overwhelming majority of carried traffic remains IP.		Even today the overwhelming majority of carried traffic remains IP.
	Providers of MPLS equipment sought to continue this IP ECMP behavior.		Providers of MPLS equipment sought to continue this IP ECMP behavior.
	As shown above, it is not possible to know whether the payload of an		As shown above, it is not possible to know whether the payload of an
	MPLS packet is IP at every place where IP ECMP needs to be performed.		MPLS packet is IP at every place where IP ECMP needs to be performed.
	Thus vendors have taken the liberty of guessing what the payload is.		Thus vendors have taken the liberty of guessing the payload. By
	By inspecting the first nibble beyond the label stack, existing		inspecting the first nibble beyond the label stack, existing
	equipment infers that a packet is not IPv4 or IPv6 if the value of		equipment infers that a packet is not IPv4 or IPv6 if the value of
	the nibble (where the IP version number would be found) is not 0x4 or		the nibble (where the IP version number would be found) is not 0x4 or
	0x6 respectively. Most deployed LSRs will treat a packet whose first		0x6 respectively. Most deployed LSRs will treat a packet whose first
	nibble is equal to 0x4 as if the payload were IPv4 for purposes of IP		nibble is equal to 0x4 as if the payload were IPv4 for purposes of IP
	ECMP.		ECMP.
	A consequence of this is that any application which defines a FEC		A consequence of this is that any application that defines an FEC
	which does not take measures to prevent the values 0x4 and 0x6 from		that does not take measures to prevent the values 0x4 and 0x6 from
	occurring in the first nibble of the payload may be subject to IP		occurring in the first nibble of the payload may be subject to IP
	ECMP and thus having their flows take multiple paths and arriving		ECMP and thus having their flows take multiple paths and arriving
	with considerable jitter and possibly out of order. While none of		with considerable jitter and possibly out of order. While none of
	this is in violation of the basic service offering of IP, it is		this is in violation of the basic service offering of IP, it is
	detrimental to the performance of various classes of applications.		detrimental to the performance of various classes of applications.
	It also complicates the measurement, monitoring and tracing of those		It also complicates the measurement, monitoring, and tracing of those
	flows.		flows.
	New MPLS payload types are emerging such as those specified by the		New MPLS payload types are emerging, such as those specified by the
	IETF PWE3 and AVT working groups. These payloads are not IP and, if		IETF PWE3 and AVT working groups. These payloads are not IP and, if
	specified without constraint might be mistaken for IP.		specified without constraint, might be mistaken for IP.
	It must also be noted that LSRs which correctly identify a payload as		It must also be noted that LSRs that correctly identify a payload as
	not being IP, most often will load-share traffic across multiple		not being IP most often will load-share traffic across multiple
	equal-cost paths based on the label stack. Any reserved label, no		equal-cost paths based on the label stack. Any reserved label, no
	matter where it is located in the stack, may be included in the com-		matter where it is located in the stack, may be included in the
	putation for load balancing. Modification of the label stack between		computation for load balancing. Modification of the label stack
	packets of a single flow could result in re-ordering that flow. That		between packets of a single flow could result in re-ordering that
	is, were an explicit null or a router-alert label to be added to a		flow. That is, were an explicit null or a router-alert label to be
	packet, that packet could take a different path through the network.		added to a packet, that packet could take a different path through
			the network.
	Note that for some applications, being mistaken for IPv4 may not be		Note that for some applications, being mistaken for IPv4 may not be
	detrimental. The trivial case where the payload behind the top label		detrimental. The trivial case being where the payload behind the top
	is a packet belonging to an MPLS IPv4 VPN. Here the real payload is		label is a packet belonging to an MPLS IPv4 VPN. Here the real
	IP and most (if not all) deployed equipment will locate the end of		payload is IP and most (if not all) deployed equipment will locate
	the label stack and correctly perform IP ECMP.		the end of the label stack and correctly perform IP ECMP.
	A less obvious case is when the packets of a given flow happen to		A less obvious case is when the packets of a given flow happen to
	have constant values in the fields upon which IP ECMP would be per-		have constant values in the fields upon which IP ECMP would be
	formed. For example if an ethernet frame immediately follows the		performed. For example, if an Ethernet frame immediately follows the
	label and the LSR does not do ECMP on IPv6, then either the first		label and the LSR does ECMP on IPv4, but does not do ECMP on IPv6,
	nibble will be 0x4 or it will be something else. If the nibble is		then either the first nibble will be 0x4, or it will be something
	not 0x4 then no IP ECMP is performed, but Label ECMP may be per-		else. If the nibble is not 0x4 then no IP ECMP is performed, but
	formed. If it is 0x4, then the constant values of the MAC addresses		Label ECMP may be performed. If it is 0x4, then the constant values
	overlay the fields that would have been occupied by the source and		of the MAC addresses overlay the fields that would have been occupied
	destination addresses of an IP header. As a result the ECMP algo-		by the source and destination addresses of an IP header. In this
	rithm would be feed a constant value and thus would always return the		case, the input to the ECMP algorithm would be a constant value and
	same result.		thus the algorithm would always return the same result.
	3. Recommendations for Avoiding ECMP Treatment		3. Recommendations for Avoiding ECMP Treatment
	We will use the term "Application Label" to refer to a label that has		We will use the term "Application Label" to refer to a label that has
	been allocated with a FEC Type that is defined (or simply used) by an		been allocated with an FEC Type that is defined (or simply used) by
	application. Such labels necessarily appear at the bottom of the		an application. Such labels necessarily appear at the bottom of the
	label stack, that is, below labels associated with transporting the		label stack, that is, below labels associated with transporting the
	packet across an MPLS network. The FEC Type of the Application label		packet across an MPLS network. The FEC Type of the Application label
	defines the payload that follows. Anyone defining an application to		defines the payload that follows. Anyone defining an application to
	be transported over MPLS is free to define new FEC Types and the for-		be transported over MPLS is free to define new FEC Types and the
	mat of the payload which will be carried.		format of the payload that will be carried.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label | Exp |0| TTL |		| Label | Exp |0| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. . . . .		. . . . .
	. . . . .		. . . . .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label | Exp |0| TTL |		| Label | Exp |0| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Application Label | Exp |1| TTL |		| Application Label | Exp |1| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1st Nbl| |		|1st Nbl| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	In order to avoid IP ECMP treatment it is necessary that an applica-		In order to avoid IP ECMP treatment, it is necessary that an
	tion take precautions to not be mistaken as IP by deployed equipment		application take precautions to not be mistaken as IP by deployed
	that snoops on the presumed location of the IP Version field. Thus,		equipment that snoops on the presumed location of the IP Version
	at a minimum, the chosen format must disallow the values 0x4 and 0x6		field. Thus, at a minimum, the chosen format must disallow the
	in the first nibble of their payload.		values 0x4 and 0x6 in the first nibble of their payload.
	It is strongly recommended, however, that applications restrict the		It is REQUIRED, however, that applications depend upon in-order
	first nibble values to 0x0 and 0x1. This will ensure that that their		packet delivery restrict the first nibble values to 0x0 and 0x1.
	traffic flows will not be affected if some future routing equipment		This will ensure that their traffic flows will not be affected if
	does similar snooping on some future version of IP.		some future routing equipment does similar snooping on some future
			version(s) of IP.
			This behavior implies that if in the future an IP version is defined
			with a version number of 0x0 or 0x1, then equipment complying with
			this BCP would be unable to look past one or more MPLS headers, and
			loadsplit traffic from a single LSP across multiple paths based on a
			hash of specific fields in the IPv0 or IPv1 headers. That is, IP
			traffic employing these version numbers would be safe from
			disturbances caused by inappropriate loadsplitting, but would also
			not be able to get the performance benefits.
	For an example of how ECMP is avoided in Pseudowires, see [RFC4385].		For an example of how ECMP is avoided in Pseudowires, see [RFC4385].
	4. Security Considerations		4. Security Considerations
	This memo discusses the conditions under which MPLS traffic associ-		This memo discusses the conditions under which MPLS traffic
	ated with a single top-level LSP either does or does not have the		associated with a single top-level LSP either does or does not have
	possibility of being split between multiple paths, implying the pos-		the possibility of being split between multiple paths, implying the
	sibility of mis-ordering between packets belonging to the same top-		possibility of mis-ordering between packets belonging to the same
	level LSP. From a security point of view, the worse that could result		top-level LSP. From a security point of view, the worse that could
	from a security breach of the mechanisms described here would be mis-		result from a security breach of the mechanisms described here would
	ordering of packets, and possible corresponding loss of throughput		be mis-ordering of packets, and possible corresponding loss of
	(for example, TCP connections may in some cases reduce the window		throughput (for example, TCP connections may in some cases reduce the
	size in response to mis-ordered packets). However, in order to create		window size in response to mis-ordered packets). However, in order
	even this limited result, a hacker would need to either change the		to create even this limited result, an attacker would need to either
	configuration or implementation of a router, or change the bits on		change the configuration or implementation of a router, or change the
	the wire as transmitted in a packet.		bits on the wire as transmitted in a packet.
	Other security issues in the deployment of MPLS are outside of the		Other security issues in the deployment of MPLS are outside the scope
	scope of this document, but are discussed in other MPLS specifica-		of this document, but are discussed in other MPLS specifications,
	tions such as RFCs 3031, 3036, 3107, 3209, 3478, 3479, 4206, 4220,		such as [RFC3031], [RFC3036], [RFC3107], [RFC3209], [RFC3478],
	4221, 4378, AND 4379.		[RFC3479], [RFC4206], [RFC4220], [RFC4221], [RFC4378], AND [RFC4379].
	5. References		5. IANA Considerations
	5.1. Normative References		IANA has marked the value 0x1 in the IP protocol version number space
			as "Reserved" and placed a reference to this document to both values
			0x0 and 0x1.
	[RFC3031] Rosen, E. et al., "Multiprotocol Label Switching		Note that this document does not in any way change the policies
	Architecture", RFC 3031, January 2001.		regarding the allocation of version numbers, including the possible
			use of the reserved numbers for some future purpose.
	5.2. Informative References		6. References
	[RFC3036] Andersson, L., et. al., "LDP Specification", RFC 3036,		6.1. Normative References
	January 2001.
			[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
			Label Switching Architecture", RFC 3031, January 2001.
			6.2. Informative References
			[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
			B. Thomas, "LDP Specification", RFC 3036, January 2001.
	[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in		[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
	BGP-4", RFC 3107, May 2001.		BGP-4", RFC 3107, May 2001.
	[RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	LSP Tunnels", RFC 3209, December 2001.		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
			Tunnels", RFC 3209, December 2001.
	[RFC3478] Leelanivas, M., et. al., "Graceful Restart Mechanism for		[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful
	Label Distribution Protocol", RFC 3478, February 2003.		Restart Mechanism for Label Distribution Protocol", RFC
			3478, February 2003.
	[RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution		[RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label
	Protocol (LDP)", RFC 3479, February 2003.		Distribution Protocol (LDP)", RFC 3479, February 2003.
	[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)		[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
	Hierarchy with Generalized Multi-Protocol Label Switching		Hierarchy with Generalized Multi-Protocol Label Switching
	(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.		(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
	[RFC4220] Dubuc, M., et. al., "Traffic Engineering Link Management		[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering
	Information Base", RFC 4220, November 2005.		Link Management Information Base", RFC 4220, November
			2005.
	[RFC4221] Nadeau, T., et. al., "Multiprotocol Label Switching (MPLS)		[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol
	Management Overview", RFC 4221, November 2005.		Label Switching (MPLS) Management Overview", RFC 4221,
			November 2005.
	[RFC4378] Allan, D. and T. Nadeau, "A Framework for Multi-Protocol		[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for
	Label Switching (MPLS) Operations and Management (OAM)",		Multi-Protocol Label Switching (MPLS) Operations and
	RFC 4378, February 2006.		Management (OAM)", RFC 4378, February 2006.
	[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol		[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
	Label Switched (MPLS) Data Plane Failures", RFC 4379,		Label Switched (MPLS) Data Plane Failures", RFC 4379,
	February 2006.		February 2006.
	[RFC4385] Bryant, S., et. al., "Pseudowire Emulation Edge-to-Edge		[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
	(PWE3) Control Word for Use over an MPLS PSN", RFC 4385,		"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
	February 2006.		Use over an MPLS PSN", RFC 4385, February 2006.
	6. Authors' Addresses		Authors' Addresses
	Loa Andersson		Loa Andersson
	Acreo		Acreo AB
			Electrum 236
			SE-146 40 Kista
			Sweden
	Email: loa@pi.se		EMail: loa@pi.se
	Stewart Bryant		Stewart Bryant
	Cisco Systems		Cisco Systems
	250, Longwater,		250, Longwater,
	Green Park,		Green Park,
	Reading, RG2 6GB, UK		Reading, RG2 6GB, UK
	Email: stbryant@cisco.com		EMail: stbryant@cisco.com
	George Swallow		George Swallow
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1414 Massachusetts Ave		1414 Massachusetts Ave
	Boxborough, MA 01719		Boxborough, MA 01719
	Email: swallow@cisco.com		EMail: swallow@cisco.com
			Full Copyright Statement
			Copyright (C) The IETF Trust (2007).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
			THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
			OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
			THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		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
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any assur-		Copies of IPR disclosures made to the IETF Secretariat and any
	ances of licenses to be made available, or the result of an attempt		assurances of licenses to be made available, or the result of an
	made to obtain a general license or permission for the use of such		attempt made to obtain a general license or permission for the use of
	proprietary rights by implementers or users of this specification can		such proprietary rights by implementers or users of this
	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 ietf-		this standard. Please address the information to the IETF at
	ipr@ietf.org.		ietf-ipr@ietf.org.
	Full Copyright Notice
	Copyright (C) The IETF Trust (2007). This document is subject to the		Acknowledgement
	rights, licenses and restrictions contained in BCP 78, and except as
	set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an		Funding for the RFC Editor function is currently provided by the
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		Internet Society.
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 50 change blocks.
	164 lines changed or deleted		187 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/