draft-ietf-mpls-atm-04.txt		rfc3035.txt
	Network Working Group Bruce Davie
	Internet Draft Jeremy Lawrence
	Expiration Date: December 2000 Keith McCloghrie
	Yakov Rekhter
	Eric Rosen
	George Swallow
	Cisco Systems, Inc.
	Paul Doolan		Network Working Group B. Davie
			Request for Comments: 3035 J. Lawrence
			Category: Standards Track K. McCloghrie
			E. Rosen
			G. Swallow
			Cisco Systems, Inc.
			Y. Rekhter
			Juniper Networks
			P. Doolan
	Ennovate Networks, Inc.		Ennovate Networks, Inc.
			January 2001
	June 2000
	MPLS using LDP and ATM VC Switching		MPLS using LDP and ATM VC Switching
	draft-ietf-mpls-atm-04.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document specifies an Internet standards track protocol for the
	all provisions of Section 10 of RFC2026.		Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
	Internet-Drafts are working documents of the Internet Engineering		Official Protocol Standards" (STD 1) for the standardization state
	Task Force (IETF), its areas, and its working groups. Note that		and status of this protocol. Distribution of this memo is unlimited.
	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.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2001). All Rights Reserved.
	Abstract		Abstract
	The MPLS Architecture [1] discusses a way in which ATM switches may		The Multiprotocol Label Switching (MPLS) Architecture [1] discusses a
	be used as Label Switching Routers. The ATM switches run network		way in which Asynchronous Transfer Mode (ATM) switches may be used as
	layer routing algorithms (such as OSPF, IS-IS, etc.), and their data		Label Switching Routers. The ATM switches run network layer routing
	forwarding is based on the results of these routing algorithms. No		algorithms (such as Open Shortest Path First (OSPF), Intermediate
			System to Intermediate System (IS-IS), etc.), and their data
			forwarding is based on the results of these routing algorithms. No
	ATM-specific routing or addressing is needed. ATM switches used in		ATM-specific routing or addressing is needed. ATM switches used in
	this way are known as ATM-LSRs.		this way are known as ATM-LSRs (Label Switching Routers).
	This document extends and clarifies the relevant portions of [1] and		This document extends and clarifies the relevant portions of [1] and
	[2] by specifying in more detail the procedures which to be used when		[2] by specifying in more detail the procedures which to be used when
	distributing labels to or from ATM-LSRs, when those labels represent		distributing labels to or from ATM-LSRs, when those labels represent
	Forwarding Equivalence Classes (FECs, see [1]) for which the routes		Forwarding Equivalence Classes (FECs, see [1]) for which the routes
	are determined on a hop-by-hop basis by network layer routing		are determined on a hop-by-hop basis by network layer routing
	algorithms.		algorithms.
	This document also specifies the MPLS encapsulation to be used when		This document also specifies the MPLS encapsulation to be used when
	sending labeled packets to or from ATM-LSRs, and in that respect is a		sending labeled packets to or from ATM-LSRs, and in that respect is a
	companion document to [3].		companion document to [3].
	Contents		Table of Contents
	1 Introduction ........................................... 3		1 Introduction ........................................... 2
	2 Specification of Requirements .......................... 4		2 Specification of Requirements .......................... 3
	3 Definitions ............................................ 4		3 Definitions ............................................ 3
	4 Special Characteristics of ATM Switches ................ 5		4 Special Characteristics of ATM Switches ................ 4
	5 Label Switching Control Component for ATM .............. 6		5 Label Switching Control Component for ATM .............. 5
	6 Hybrid Switches (Ships in the Night) ................... 7		6 Hybrid Switches (Ships in the Night) ................... 5
	7 Use of VPI/VCIs ....................................... 7		7 Use of VPI/VCIs ....................................... 5
	7.1 Direct Connections ..................................... 8		7.1 Direct Connections ..................................... 6
	7.2 Connections via an ATM VP .............................. 8		7.2 Connections via an ATM VP .............................. 7
	7.3 Connections via an ATM SVC ............................. 9		7.3 Connections via an ATM SVC ............................. 7
	8 Label Distribution and Maintenance Procedures .......... 9		8 Label Distribution and Maintenance Procedures .......... 7
	8.1 Edge LSR Behavior ...................................... 9		8.1 Edge LSR Behavior ...................................... 8
	8.2 Conventional ATM Switches (non-VC-merge) ............... 10		8.2 Conventional ATM Switches (non-VC-merge) ............... 9
	8.3 VC-merge-capable ATM Switches .......................... 13		8.3 VC-merge-capable ATM Switches .......................... 11
	9 Encapsulation .......................................... 14		9 Encapsulation .......................................... 12
	10 TTL Manipulation ....................................... 15		10 TTL Manipulation ....................................... 13
	11 Optional Loop Detection: Distributing Path Vectors ..... 16		11 Optional Loop Detection: Distributing Path Vectors ..... 15
	11.1 When to Send Path Vectors Downstream ................... 16		11.1 When to Send Path Vectors Downstream ................... 15
	11.2 When to Send Path Vectors Upstream ..................... 17		11.2 When to Send Path Vectors Upstream ..................... 16
	12 Security Considerations ................................ 18		12 Security Considerations ................................ 17
	13 Intellectual Property Considerations ................... 19		13 Intellectual Property Considerations ................... 17
	14 References ............................................. 19		14 References ............................................. 18
	15 Acknowledgments ........................................ 20		15 Acknowledgments ........................................ 18
	16 Authors' Addresses ..................................... 20		16 Authors' Addresses ..................................... 18
	17 Full Copyright Statement ............................... 21		17 Full Copyright Statement ............................... 20
	1. Introduction		1. Introduction
	The MPLS Architecture [1] discusses the way in which ATM switches may		The MPLS Architecture [1] discusses the way in which ATM switches may
	be used as Label Switching Routers. The ATM switches run network		be used as Label Switching Routers. The ATM switches run network
	layer routing algorithms (such as OSPF, IS-IS, etc.), and their data		layer routing algorithms (such as OSPF, IS-IS, etc.), and their data
	forwarding is based on the results of these routing algorithms. No		forwarding is based on the results of these routing algorithms. No
	ATM-specific routing or addressing is needed. ATM switches used in		ATM-specific routing or addressing is needed. ATM switches used in
	this way are known as ATM-LSRs.		this way are known as ATM-LSRs.
	skipping to change at page 4, line 12		skipping to change at page 3, line 8
	the routes are determined on a hop-by-hop basis by network layer		the routes are determined on a hop-by-hop basis by network layer
	routing algorithms. The label distribution technique described here		routing algorithms. The label distribution technique described here
	is referred to in [1] as "downstream-on-demand". This label		is referred to in [1] as "downstream-on-demand". This label
	distribution technique MUST be used by ATM-LSRs that are not capable		distribution technique MUST be used by ATM-LSRs that are not capable
	of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs		of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs
	that are capable of VC merge.		that are capable of VC merge.
	This document does NOT specify the label distribution techniques to		This document does NOT specify the label distribution techniques to
	be used in the following cases:		be used in the following cases:
	- the routes are explicitly chosen before label distribution		- the routes are explicitly chosen before label distribution
	begins, instead of being chosen on a hop-by-hop basis as label		begins, instead of being chosen on a hop-by-hop basis as label
	distribution proceeds,		distribution proceeds,
	- the routes are intended to diverge in any way from the routes		- the routes are intended to diverge in any way from the routes
	chosen by the conventional hop-by-hop routing at any time,		chosen by the conventional hop-by-hop routing at any time,
	- the labels represent FECs that consist of multicast packets,		- the labels represent FECs that consist of multicast packets,
	- the LSRs use "VP merge".		- the LSRs use "VP merge".
	Further statements made in this document about ATM-LSR label		Further statements made in this document about ATM-LSR label
	distribution do not necessarily apply in these cases.		distribution do not necessarily apply in these cases.
	This document also specifies the MPLS encapsulation to be used when		This document also specifies the MPLS encapsulation to be used when
	sending labeled packets to or from ATM-LSRs, and in that respect is a		sending labeled packets to or from ATM-LSRs, and in that respect is a
	companion document to [3]. The specified encapsulation is to be used		companion document to [3]. The specified encapsulation is to be used
	for multicast or explicitly routed labeled packets as well.		for multicast or explicitly routed labeled packets as well.
	This document uses terminology from [1].		This document uses terminology from [1].
	skipping to change at page 4, line 45		skipping to change at page 3, line 41
	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.		document are to be interpreted as described in RFC 2119.
	3. Definitions		3. Definitions
	A Label Switching Router (LSR) is a device which implements the label		A Label Switching Router (LSR) is a device which implements the label
	switching control and forwarding components described in [1].		switching control and forwarding components described in [1].
	A label switching controlled ATM (LC-ATM) interface is an ATM		A label switching controlled ATM (LC-ATM) interface is an ATM
	interface controlled by the label switching control component. When a		interface controlled by the label switching control component. When
	packet traversing such an interface is received, it is treated as a		a packet traversing such an interface is received, it is treated as a
	labeled packet. The packet's top label is inferred either from the		labeled packet. The packet's top label is inferred either from the
	contents of the VCI field or the combined contents of the VPI and VCI		contents of the VCI field or the combined contents of the VPI and VCI
	fields. Any two LDP peers which are connected via an LC-ATM		fields. Any two LDP peers which are connected via an LC-ATM
	interface will use LDP negotiations to determine which of these cases		interface will use LDP negotiations to determine which of these cases
	is applicable to that interface.		is applicable to that interface.
	An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards		An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards
	cells between these interfaces, using labels carried in the VCI or		cells between these interfaces, using labels carried in the VCI or
	VPI/VCI field, without reassembling the cells into frames before		VPI/VCI field, without reassembling the cells into frames before
	forwarding.		forwarding.
	A frame-based LSR is a LSR which forwards complete frames between its		A frame-based LSR is a LSR which forwards complete frames between its
	interfaces. Note that such a LSR may have zero, one or more LC-ATM		interfaces. Note that such a LSR may have zero, one or more LC-ATM
	interfaces.		interfaces.
	Sometimes a single box may behave as an ATM-LSR with respect to		Sometimes a single box may behave as an ATM-LSR with respect to
	certain pairs of interfaces, but may behave as a frame-based LSR with		certain pairs of interfaces, but may behave as a frame-based LSR with
	respect to other pairs. For example, an ATM switch with an ethernet		respect to other pairs. For example, an ATM switch with an ethernet
	interface may function as an ATM-LSR when forwarding cells between		interface may function as an ATM-LSR when forwarding cells between
	its LC-ATM interfaces, but may function as a frame-based LSR when		its LC-ATM interfaces, but may function as a frame-based LSR when
	forwarding frames from its ethernet to one of its LC-ATM interfaces.		forwarding frames from its ethernet to one of its LC-ATM interfaces.
	In such cases, one can consider the two functions (ATM-LSR and		In such cases, one can consider the two functions (ATM-LSR and
	frame-based LSR) as being coresident in a single box.		frame-based LSR) as being coresident in a single box.
	skipping to change at page 5, line 47		skipping to change at page 4, line 40
	VC-merge is the process by which a switch receives cells on several		VC-merge is the process by which a switch receives cells on several
	incoming VCIs and transmits them on a single outgoing VCI without		incoming VCIs and transmits them on a single outgoing VCI without
	causing the cells of different AAL5 PDUs to become interleaved.		causing the cells of different AAL5 PDUs to become interleaved.
	4. Special Characteristics of ATM Switches		4. Special Characteristics of ATM Switches
	While the MPLS architecture permits considerable flexibility in LSR		While the MPLS architecture permits considerable flexibility in LSR
	implementation, an ATM-LSR is constrained by the capabilities of the		implementation, an ATM-LSR is constrained by the capabilities of the
	(possibly pre-existing) hardware and the restrictions on such matters		(possibly pre-existing) hardware and the restrictions on such matters
	as cell format imposed by ATM standards. Because of these		as cell format imposed by ATM standards. Because of these
	constraints, some special procedures are required for ATM-LSRs.		constraints, some special procedures are required for ATM-LSRs.
	Some of the key features of ATM switches that affect their behavior		Some of the key features of ATM switches that affect their behavior
	as LSRs are:		as LSRs are:
	- the label swapping function is performed on fields (the VCI		- the label swapping function is performed on fields (the VCI
	and/or VPI) in the cell header; this dictates the size and		and/or VPI) in the cell header; this dictates the size and
	placement of the label(s) in a packet.		placement of the label(s) in a packet.
	- multipoint-to-point and multipoint-to-multipoint VCs are		- multipoint-to-point and multipoint-to-multipoint VCs are
	generally not supported. This means that most switches cannot		generally not supported. This means that most switches cannot
	support 'VC-merge' as defined above.		support 'VC-merge' as defined above.
	- there is generally no capability to perform a 'TTL-decrement'		- there is generally no capability to perform a 'TTL-decrement'
	function as is performed on IP headers in routers.		function as is performed on IP headers in routers.
	This document describes ways of applying label switching to ATM		This document describes ways of applying label switching to ATM
	switches which work within these constraints.		switches which work within these constraints.
	5. Label Switching Control Component for ATM		5. Label Switching Control Component for ATM
	To support label switching an ATM switch MUST implement the control		To support label switching an ATM switch MUST implement the control
	component of label switching. This consists primarily of label		component of label switching. This consists primarily of label
	allocation, distribution, and maintenance procedures. Label binding		allocation, distribution, and maintenance procedures. Label binding
	information is communicated by several mechanisms, notably the Label		information is communicated by several mechanisms, notably the Label
	Distribution Protocol (LDP) [2]. This document imposes certain		Distribution Protocol (LDP) [2]. This document imposes certain
	requirements on the LDP.		requirements on the LDP.
	This document considers only the case where the label switching		This document considers only the case where the label switching
	control component uses information learned directly from network		control component uses information learned directly from network
	layer routing protocols. It is presupposed that the switch		layer routing protocols. It is presupposed that the switch
	participates as a peer in these protocols (e.g., OSPF, IS-IS).		participates as a peer in these protocols (e.g., OSPF, IS-IS).
	In some cases, LSRs make use of other protocols (e.g. RSVP, PIM, BGP)		In some cases, LSRs make use of other protocols (e.g., RSVP, PIM,
	to distribute label bindings. In these cases, an ATM-LSR would need		BGP) to distribute label bindings. In these cases, an ATM-LSR would
	to participate in these protocols. However, these are not explicitly		need to participate in these protocols. However, these are not
	considered in this document.		explicitly considered in this document.
	Support of label switching on an ATM switch does NOT require the		Support of label switching on an ATM switch does NOT require the
	switch to support the ATM control component defined by the ITU and		switch to support the ATM control component defined by the ITU and
	ATM Forum (e.g., UNI, PNNI). An ATM-LSR may OPTIONALLY respond to OAM		ATM Forum (e.g., UNI, PNNI). An ATM-LSR may OPTIONALLY respond to
	cells.		OAM cells.
	6. Hybrid Switches (Ships in the Night)		6. Hybrid Switches (Ships in the Night)
	The existence of the label switching control component on an ATM		The existence of the label switching control component on an ATM
	switch does not preclude the ability to support the ATM control		switch does not preclude the ability to support the ATM control
	component defined by the ITU and ATM Forum on the same switch and the		component defined by the ITU and ATM Forum on the same switch and the
	same interfaces. The two control components, label switching and the		same interfaces. The two control components, label switching and the
	ITU/ATM Forum defined, would operate independently.		ITU/ATM Forum defined, would operate independently.
	Definition of how such a device operates is beyond the scope of this		Definition of how such a device operates is beyond the scope of this
	skipping to change at page 9, line 27		skipping to change at page 7, line 51
	received packet would then be inferred (via a one-to-one mapping)		received packet would then be inferred (via a one-to-one mapping)
	from the virtual circuit on which the packet arrived. There would		from the virtual circuit on which the packet arrived. There would
	not be a default VPI or VCI value for the non-MPLS connection.		not be a default VPI or VCI value for the non-MPLS connection.
	8. Label Distribution and Maintenance Procedures		8. Label Distribution and Maintenance Procedures
	This document discusses the use of "downstream-on-demand" label		This document discusses the use of "downstream-on-demand" label
	distribution (see [1]) by ATM-LSRs. These label distribution		distribution (see [1]) by ATM-LSRs. These label distribution
	procedures MUST be used by ATM-LSRs that do not support VC-merge, and		procedures MUST be used by ATM-LSRs that do not support VC-merge, and
	MAY also be used by ATM-LSRs that do support VC-merge. The		MAY also be used by ATM-LSRs that do support VC-merge. The
	procedures differ somewhat in the two cases, however. We therefore		procedures differ somewhat in the two cases, however. We therefore
	describe the two scenarios in turn. We begin by describing the		describe the two scenarios in turn. We begin by describing the
	behavior of members of the Edge Set of an ATM-LSR domain; these "Edge		behavior of members of the Edge Set of an ATM-LSR domain; these "Edge
	LSRs" are not themselves ATM-LSRs, and their behavior is the same		LSRs" are not themselves ATM-LSRs, and their behavior is the same
	whether the domain contains VC-merge capable LSRs or not.		whether the domain contains VC-merge capable LSRs or not.
	8.1. Edge LSR Behavior		8.1. Edge LSR Behavior
	Consider a member of the Edge Set of an ATM-LSR domain. Assume that,		Consider a member of the Edge Set of an ATM-LSR domain. Assume that,
	as a result of its routing calculations, it selects an ATM-LSR as the		as a result of its routing calculations, it selects an ATM-LSR as the
	next hop of a certain FEC, and that the next hop is reachable via a		next hop of a certain FEC, and that the next hop is reachable via a
	LC-ATM interface. The Edge LSR uses LDP to request a label binding		LC-ATM interface. The Edge LSR uses LDP to request a label binding
	for that FEC from the next hop. The hop count field in the request		for that FEC from the next hop. The hop count field in the request
	is set to 1 (but see the next paragraph). Once the Edge LSR receives		is set to 1 (but see the next paragraph). Once the Edge LSR receives
	the label binding information, it may use MPLS forwarding procedures		the label binding information, it may use MPLS forwarding procedures
	to transmit packets in the specified FEC, using the specified label		to transmit packets in the specified FEC, using the specified label
	as an outgoing label. (Or using the VPI/VCI that corresponds to the		as an outgoing label. (Or using the VPI/VCI that corresponds to the
	specified VCID as the outgoing label, if the VCID technique of [4] is		specified VCID as the outgoing label, if the VCID technique of [4] is
	being used.)		being used.)
	Note: if the Edge LSR's previous hop is using downstream-on-demand		Note: if the Edge LSR's previous hop is using downstream-on-demand
	label distribution to request a label from the Edge LSR for a		label distribution to request a label from the Edge LSR for a
	particular FEC, and if the Edge LSR is not merging the LSP from that		particular FEC, and if the Edge LSR is not merging the LSP from that
	previous hop with any other LSP, and if the request from the previous		previous hop with any other LSP, and if the request from the previous
	hop has a hop count of h, then the hop count in the request issued by		hop has a hop count of h, then the hop count in the request issued by
	the Edge LSR should not be set to 1, but rather to h+1.		the Edge LSR should not be set to 1, but rather to h+1.
	The binding received by the edge LSR may contain a hop count, which		The binding received by the edge LSR may contain a hop count, which
	represents the number of hops a packet will take to cross the ATM-LSR		represents the number of hops a packet will take to cross the ATM-LSR
	domain when using this label. If there is a hop count associated with		domain when using this label. If there is a hop count associated
	the binding, the ATM-LSR SHOULD adjust a data packet's TTL by this		with the binding, the ATM-LSR SHOULD adjust a data packet's TTL by
	amount before transmitting the packet. In any event, it MUST adjust		this amount before transmitting the packet. In any event, it MUST
	a data packet's TTL by at least one before transmitting it. The		adjust a data packet's TTL by at least one before transmitting it.
	procedures for doing so (in the case of IP packets) are specified in		The procedures for doing so (in the case of IP packets) are specified
	section 10. The procedures for encapsulating the packets are		in section 10. The procedures for encapsulating the packets are
	specified in section 9.		specified in section 9.
	When a member of the Edge Set of the ATM-LSR domain receives a label		When a member of the Edge Set of the ATM-LSR domain receives a label
	binding request from an ATM-LSR, it allocates a label, and returns		binding request from an ATM-LSR, it allocates a label, and returns
	(via LDP) a binding containing the allocated label back to the peer		(via LDP) a binding containing the allocated label back to the peer
	that originated the request. It sets the hop count in the binding to		that originated the request. It sets the hop count in the binding to
	1.		1.
	When a routing calculation causes an Edge LSR to change the next hop		When a routing calculation causes an Edge LSR to change the next hop
	for a particular FEC, and the former next hop was in the ATM-LSR		for a particular FEC, and the former next hop was in the ATM-LSR
	domain, the Edge LSR SHOULD notify the former next hop (via LDP) that		domain, the Edge LSR SHOULD notify the former next hop (via LDP) that
	the label binding associated with the FEC is no longer needed.		the label binding associated with the FEC is no longer needed.
	8.2. Conventional ATM Switches (non-VC-merge)		8.2. Conventional ATM Switches (non-VC-merge)
	When an ATM-LSR receives (via LDP) a label binding request for a		When an ATM-LSR receives (via LDP) a label binding request for a
	certain FEC from a peer connected to the ATM-LSR over a LC-ATM		certain FEC from a peer connected to the ATM-LSR over a LC-ATM
	interface, the ATM-LSR takes the following actions:		interface, the ATM-LSR takes the following actions:
	- it allocates a label,		- it allocates a label,
	- it requests (via LDP) a label binding from the next hop for that		- it requests (via LDP) a label binding from the next hop for
	FEC;		that FEC;
	- it returns (via LDP) a binding containing the allocated incoming		- it returns (via LDP) a binding containing the allocated
	label back to the peer that originated the request.		incoming label back to the peer that originated the request.
	For purposes of this procedure, we define a maximum hop count value		For purposes of this procedure, we define a maximum hop count value
	MAXHOP. MAXHOP has a default value of 255, but may be configured to		MAXHOP. MAXHOP has a default value of 255, but may be configured to
	a different value.		a different value.
	The hop count field in the request that the ATM-LSR sends (to the		The hop count field in the request that the ATM-LSR sends (to the
	next hop LSR) MUST be set to one more than the hop count field in the		next hop LSR) MUST be set to one more than the hop count field in the
	request that it received from the upstream LSR. If the resulting hop		request that it received from the upstream LSR. If the resulting hop
	count exceeds MAXHOP, the request MUST NOT be sent to the next hop,		count exceeds MAXHOP, the request MUST NOT be sent to the next hop,
	and the ATM-LSR MUST notify the upstream neighbor that its binding		and the ATM-LSR MUST notify the upstream neighbor that its binding
	skipping to change at page 11, line 27		skipping to change at page 9, line 49
	from downstream and MUST include the result in the binding it returns		from downstream and MUST include the result in the binding it returns
	upstream. However, if the hop count exceeds MAXHOP, a label binding		upstream. However, if the hop count exceeds MAXHOP, a label binding
	MUST NOT be passed upstream. Rather, the upstream LDP peer MUST be		MUST NOT be passed upstream. Rather, the upstream LDP peer MUST be
	informed that the requested label binding cannot be satisfied. If		informed that the requested label binding cannot be satisfied. If
	the hop count received from downstream is 0, the hop count passed		the hop count received from downstream is 0, the hop count passed
	upstream should also be 0; this indicates that the actual hop count		upstream should also be 0; this indicates that the actual hop count
	is unknown.		is unknown.
	Alternatively, the ATM-LSR MAY return the binding upstream without		Alternatively, the ATM-LSR MAY return the binding upstream without
	waiting for a binding from downstream ("independent" control, as		waiting for a binding from downstream ("independent" control, as
	defined in [1] and [2]). In this case, it specifies a hop count of 0		defined in [1] and [2]). In this case, it specifies a hop count of 0
	in the binding, indicating that the true hop count is unknown. The		in the binding, indicating that the true hop count is unknown. The
	correct value for hop count will be returned later, as described		correct value for hop count will be returned later, as described
	below.		below.
	Note that an ATM-LSR, or a member of the edge set of an ATM-LSR		Note that an ATM-LSR, or a member of the edge set of an ATM-LSR
	domain, may receive multiple binding requests for the same FEC from		domain, may receive multiple binding requests for the same FEC from
	the same ATM-LSR. It MUST generate a new binding for each request		the same ATM-LSR. It MUST generate a new binding for each request
	(assuming adequate resources to do so), and retain any existing		(assuming adequate resources to do so), and retain any existing
	binding(s). For each request received, an ATM-LSR MUST also generate		binding(s). For each request received, an ATM-LSR MUST also generate
	a new binding request toward the next hop for the FEC.		a new binding request toward the next hop for the FEC.
	When a routing calculation causes an ATM-LSR to change the next hop		When a routing calculation causes an ATM-LSR to change the next hop
	for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that		for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that
	the label binding associated with the FEC is no longer needed.		the label binding associated with the FEC is no longer needed.
	When a LSR receives a notification that a particular label binding is		When a LSR receives a notification that a particular label binding is
	no longer needed, the LSR MAY deallocate the label associated with		no longer needed, the LSR MAY deallocate the label associated with
	the binding, and destroy the binding. In the case where an ATM-LSR		the binding, and destroy the binding. In the case where an ATM-LSR
	receives such notification and destroys the binding, it MUST notify		receives such notification and destroys the binding, it MUST notify
	the next hop for the FEC that the label binding is no longer needed.		the next hop for the FEC that the label binding is no longer needed.
	If a LSR does not destroy the binding, it may re-use the binding only		If a LSR does not destroy the binding, it may re-use the binding only
	if it receives a request for the same FEC with the same hop count as		if it receives a request for the same FEC with the same hop count as
	the request that originally caused the binding to be created.		the request that originally caused the binding to be created.
	When a route changes, the label bindings are re-established from the		When a route changes, the label bindings are re-established from the
	point where the route diverges from the previous route. LSRs		point where the route diverges from the previous route. LSRs
	upstream of that point are (with one exception, noted below)		upstream of that point are (with one exception, noted below)
	oblivious to the change.		oblivious to the change.
	Whenever a LSR changes its next hop for a particular FEC, if the new		Whenever a LSR changes its next hop for a particular FEC, if the new
	next hop is reachable via an LC-ATM interface, then for each label		next hop is reachable via an LC-ATM interface, then for each label
	that it has bound to that FEC, and distributed upstream, it MUST		that it has bound to that FEC, and distributed upstream, it MUST
	request a new label binding from the new next hop.		request a new label binding from the new next hop.
	When an ATM-LSR receives a label binding for a particular FEC from a		When an ATM-LSR receives a label binding for a particular FEC from a
	downstream neighbor, it may already have provided a corresponding		downstream neighbor, it may already have provided a corresponding
	label binding for this FEC to an upstream neighbor, either because it		label binding for this FEC to an upstream neighbor, either because it
	is using independent control, or because the new binding from		is using independent control, or because the new binding from
	downstream is the result of a routing change. In this case, unless		downstream is the result of a routing change. In this case, unless
	the hop count is 0, it MUST extract the hop count from the new		the hop count is 0, it MUST extract the hop count from the new
	binding and increment it by one. If the new hop count is different		binding and increment it by one. If the new hop count is different
	from that which was previously conveyed to the upstream neighbor		from that which was previously conveyed to the upstream neighbor
	(including the case where the upstream neighbor was given the value		(including the case where the upstream neighbor was given the value
	'unknown') the ATM-LSR MUST notify the upstream neighbor of the		'unknown') the ATM-LSR MUST notify the upstream neighbor of the
	change. Each ATM-LSR in turn MUST increment the hop count and pass it		change. Each ATM-LSR in turn MUST increment the hop count and pass
	upstream until it reaches the ingress Edge LSR. If at any point the		it upstream until it reaches the ingress Edge LSR. If at any point
	value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw the		the value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw
	binding from the upstream neighbor. A hop count of 0 MUST be passed		the binding from the upstream neighbor. A hop count of 0 MUST be
	upstream unchanged.		passed upstream unchanged.
	Whenever an ATM-LSR originates a label binding request to its next		Whenever an ATM-LSR originates a label binding request to its next
	hop LSR as a result of receiving a label binding request from another		hop LSR as a result of receiving a label binding request from another
	(upstream) LSR, and the request to the next hop LSR is not satisfied,		(upstream) LSR, and the request to the next hop LSR is not satisfied,
	the ATM-LSR SHOULD destroy the binding created in response to the		the ATM-LSR SHOULD destroy the binding created in response to the
	received request, and notify the requester (via LDP).		received request, and notify the requester (via LDP).
	If an ATM-LSR receives a binding request containing a hop count that		If an ATM-LSR receives a binding request containing a hop count that
	exceeds MAXHOP, it MUST not establish a binding, and it MUST return		exceeds MAXHOP, it MUST not establish a binding, and it MUST return
	an error to the requester.		an error to the requester.
	When a LSR determines that it has lost its LDP session with another		When a LSR determines that it has lost its LDP session with another
	LSR, the following actions are taken. Any binding information		LSR, the following actions are taken. Any binding information
	learned via this connection MUST be discarded. For any label		learned via this connection MUST be discarded. For any label
	bindings that were created as a result of receiving label binding		bindings that were created as a result of receiving label binding
	requests from the peer, the LSR MAY destroy these bindings (and		requests from the peer, the LSR MAY destroy these bindings (and
	deallocate labels associated with these binding).		deallocate labels associated with these binding).
	An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding		An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding
	requests from its neighbors. That is, if it receives a request for a		requests from its neighbors. That is, if it receives a request for a
	binding to a particular FEC and the LSR making that request is,		binding to a particular FEC and the LSR making that request is,
	according to this ATM-LSR, the next hop for that FEC, it should not		according to this ATM-LSR, the next hop for that FEC, it should not
	return a binding for that route.		return a binding for that route.
	It is expected that non-merging ATM-LSRs would generally use		It is expected that non-merging ATM-LSRs would generally use
	"conservative label retention mode" [1].		"conservative label retention mode" [1].
	8.3. VC-merge-capable ATM Switches		8.3. VC-merge-capable ATM Switches
	Relatively minor changes are needed to accommodate ATM-LSRs which		Relatively minor changes are needed to accommodate ATM-LSRs which
	support VC-merge. The primary difference is that a VC-merge-capable		support VC-merge. The primary difference is that a VC-merge-capable
	ATM-LSR needs only one outgoing label per FEC, even if multiple		ATM-LSR needs only one outgoing label per FEC, even if multiple
	requests for label bindings to that FEC are received from upstream		requests for label bindings to that FEC are received from upstream
	neighbors.		neighbors.
	When a VC-merge-capable ATM-LSR receives a binding request from an		When a VC-merge-capable ATM-LSR receives a binding request from an
	upstream LSR for a certain FEC, and it does not already have an		upstream LSR for a certain FEC, and it does not already have an
	outgoing label binding for that FEC (or an outstanding request for		outgoing label binding for that FEC (or an outstanding request for
	such a label binding), it MUST issue a bind request to its next hop		such a label binding), it MUST issue a bind request to its next hop
	just as it would do if it were not merge-capable. If, however, it		just as it would do if it were not merge-capable. If, however, it
	already has an outgoing label binding for that FEC, it does not need		already has an outgoing label binding for that FEC, it does not need
	to issue a downstream binding request. Instead, it may simply		to issue a downstream binding request. Instead, it may simply
	allocate an incoming label, and return that label in a binding to the		allocate an incoming label, and return that label in a binding to the
	upstream requester. When packets with that label as top label are		upstream requester. When packets with that label as top label are
	received from the requester, the top label value will be replaced		received from the requester, the top label value will be replaced
	with the existing outgoing label value that corresponds to the same		with the existing outgoing label value that corresponds to the same
	FEC.		FEC.
	If the ATM-LSR does not have an outgoing label binding for the FEC,		If the ATM-LSR does not have an outgoing label binding for the FEC,
	but does have an outstanding request for one, it need not issue		but does have an outstanding request for one, it need not issue
	another request.		another request.
	skipping to change at page 14, line 12		skipping to change at page 12, line 36
	causes it to select a new next hop for one of its FECs, it MAY		causes it to select a new next hop for one of its FECs, it MAY
	optionally release the binding for that route from the former next		optionally release the binding for that route from the former next
	hop. If it doesn't already have a corresponding binding for the new		hop. If it doesn't already have a corresponding binding for the new
	next hop, it must request one. (The choice between conservative and		next hop, it must request one. (The choice between conservative and
	liberal label retention mode [1] is an implementation option.)		liberal label retention mode [1] is an implementation option.)
	If a new binding is obtained, which contains a hop count that differs		If a new binding is obtained, which contains a hop count that differs
	from that which was received in the old binding, then the ATM-LSR		from that which was received in the old binding, then the ATM-LSR
	must take the new hop count, increment it by one, and notify any		must take the new hop count, increment it by one, and notify any
	upstream neighbors who have label bindings for this FEC of the new		upstream neighbors who have label bindings for this FEC of the new
	value. Just as with conventional ATM-LSRs, this enables the new hop		value. Just as with conventional ATM-LSRs, this enables the new hop
	count to propagate back towards the ingress of the ATM-LSR domain. If		count to propagate back towards the ingress of the ATM-LSR domain.
	at any point the hop count exceeds MAXHOP, then the label bindings		If at any point the hop count exceeds MAXHOP, then the label bindings
	for this route must be withdrawn from all upstream neighbors to whom		for this route must be withdrawn from all upstream neighbors to whom
	a binding was previously provided. This ensures that any loops caused		a binding was previously provided. This ensures that any loops
	by routing transients will be detected and broken.		caused by routing transients will be detected and broken.
	9. Encapsulation		9. Encapsulation
	The procedures described in this section affect only the Edge LSRs of		The procedures described in this section affect only the Edge LSRs of
	the ATM-LSR domain. The ATM-LSRs themselves do not modify the		the ATM-LSR domain. The ATM-LSRs themselves do not modify the
	encapsulation in any way.		encapsulation in any way.
	Labeled packets MUST be transmitted using the null encapsulation of		Labeled packets MUST be transmitted using the null encapsulation of
	Section 6.1 of RFC 2684 [5].		Section 6.1 of RFC 2684 [5].
	skipping to change at page 15, line 5		skipping to change at page 13, line 27
	Note that if a packet has a label stack with only one entry, this		Note that if a packet has a label stack with only one entry, this
	requires it to have a single-entry shim (4 bytes), even though the		requires it to have a single-entry shim (4 bytes), even though the
	actual label value is encoded into the VPI/VCI field. This is done		actual label value is encoded into the VPI/VCI field. This is done
	to ensure that the packet always has a shim. Otherwise, there would		to ensure that the packet always has a shim. Otherwise, there would
	be no way to determine whether it had one or not, i.e., no way to		be no way to determine whether it had one or not, i.e., no way to
	determine whether there are additional label stack entries.		determine whether there are additional label stack entries.
	The only ways to eliminate this extra overhead are:		The only ways to eliminate this extra overhead are:
	- through apriori knowledge that packets have only a single label		- through apriori knowledge that packets have only a single label
	(e.g., perhaps the network only supports one level of label)		(e.g., perhaps the network only supports one level of label)
	- by using two VCs per FEC, one for those packets which have only a		- by using two VCs per FEC, one for those packets which have only
	single label, and one for those packets which have more than one		a single label, and one for those packets which have more than
	label		one label
	The second technique would require that there be some way of		The second technique would require that there be some way of
	signalling via LDP that the VC is carrying only packets with a single		signalling via LDP that the VC is carrying only packets with a single
	label, and is not carrying a shim. When supporting VC merge, one		label, and is not carrying a shim. When supporting VC merge, one
	would also have to take care not to merge a VC on which the shim is		would also have to take care not to merge a VC on which the shim is
	not used into a VC on which it is used, or vice versa.		not used into a VC on which it is used, or vice versa.
	While either of these techniques is permitted, it is doubtful that		While either of these techniques is permitted, it is doubtful that
	they have any practical utility. Note that if the shim header is not		they have any practical utility. Note that if the shim header is not
	present, the outgoing TTL is carried in the TTL field of the network		present, the outgoing TTL is carried in the TTL field of the network
	layer header.		layer header.
	10. TTL Manipulation		10. TTL Manipulation
	skipping to change at page 15, line 48		skipping to change at page 14, line 24
	used when the packet is forwarded, the "outgoing TTL" is set to the		used when the packet is forwarded, the "outgoing TTL" is set to the
	larger of (a) 0 or (b) the difference between the incoming TTL and		larger of (a) 0 or (b) the difference between the incoming TTL and
	the hop count. If a hop count has not been associated with the label		the hop count. If a hop count has not been associated with the label
	binding that is used when the packet is forwarded, the "outgoing TTL"		binding that is used when the packet is forwarded, the "outgoing TTL"
	is set to the larger of (a) 0 or (b) one less than the incoming TTL.		is set to the larger of (a) 0 or (b) one less than the incoming TTL.
	If this causes the outgoing TTL to become zero, the packet MUST NOT		If this causes the outgoing TTL to become zero, the packet MUST NOT
	be transmitted as a labeled packet using the specified label. The		be transmitted as a labeled packet using the specified label. The
	packet can be treated in one of two ways:		packet can be treated in one of two ways:
	- it may be treated as having expired; this may cause an ICMP		- it may be treated as having expired; this may cause an ICMP
	message to be transmitted;		message to be transmitted;
	- the packet may be forwarded, as an unlabeled packet, with a TTL		- the packet may be forwarded, as an unlabeled packet, with a TTL
	that is 1 less than the incoming TTL; such forwarding would need		that is 1 less than the incoming TTL; such forwarding would
	to be done over a non-MPLS connection.		need to be done over a non-MPLS connection.
	Of course, if the incoming TTL is 1, only the first of these two		Of course, if the incoming TTL is 1, only the first of these two
	options is applicable.		options is applicable.
	If the packet is forwarded as a labeled packet, the outgoing TTL is		If the packet is forwarded as a labeled packet, the outgoing TTL is
	carried as specified in section 9.		carried as specified in section 9.
	When an Edge LSR receives a labeled packet over an LC-ATM interface,		When an Edge LSR receives a labeled packet over an LC-ATM interface,
	it obtains the incoming TTL from the top label stack entry of the		it obtains the incoming TTL from the top label stack entry of the
	generic encapsulation, or, if that encapsulation is not present, from		generic encapsulation, or, if that encapsulation is not present, from
	skipping to change at page 16, line 44		skipping to change at page 15, line 22
	loops are detected by the hop count mechanism previously described.		loops are detected by the hop count mechanism previously described.
	If this option is enabled, loops will be detected more quickly, but		If this option is enabled, loops will be detected more quickly, but
	at a higher cost in overhead.		at a higher cost in overhead.
	11.1. When to Send Path Vectors Downstream		11.1. When to Send Path Vectors Downstream
	Suppose an LSR R sends a request for a label binding, for a		Suppose an LSR R sends a request for a label binding, for a
	particular LSP, to its next hop. Then if R does not support VC-		particular LSP, to its next hop. Then if R does not support VC-
	merging, and R is configured to use the LDPV procedure:		merging, and R is configured to use the LDPV procedure:
	- If R is sending the request because it is an ingress node for		- If R is sending the request because it is an ingress node for
	that LSP, or because it has acquired a new next hop, then R MUST		that LSP, or because it has acquired a new next hop, then R
	include a path vector object with the request, and the path		MUST include a path vector object with the request, and the
	vector object MUST contain only R's own address.		path vector object MUST contain only R's own address.
	- If R is sending the request as a result of having received a		- If R is sending the request as a result of having received a
	request from an upstream LSR, then:		request from an upstream LSR, then:
	* if the received request has a path vector object, R MUST add		* if the received request has a path vector object, R MUST add
	its own address to the received path vector object, and MUST		its own address to the received path vector object, and MUST
	pass the resulting path vector object to its next hop along		pass the resulting path vector object to its next hop along
	with the label binding request;		with the label binding request;
	* if the received request does not have a path vector object, R		* if the received request does not have a path vector object,
	MUST include a path vector object with the request it sends,		R MUST include a path vector object with the request it
	and the path vector object MUST contain only R's own address.		sends, and the path vector object MUST contain only R's own
			address.
	An LSR which supports VC-merge SHOULD NOT include a path vector		An LSR which supports VC-merge SHOULD NOT include a path vector
	object in the requests that it sends to its next hop.		object in the requests that it sends to its next hop.
	If an LSR receives a label binding request whose path vector object		If an LSR receives a label binding request whose path vector object
	contains the address of the node itself, the LSR concludes that the		contains the address of the node itself, the LSR concludes that the
	label binding requests have traveled in a loop. The LSR MUST act as		label binding requests have traveled in a loop. The LSR MUST act as
	it would in the case where the hop count exceeds MAXHOP (see section		it would in the case where the hop count exceeds MAXHOP (see section
	8.2).		8.2).
	This procedure detects the case where the request messages loop		This procedure detects the case where the request messages loop
	though a sequence of non-merging ATM-LSRs.		though a sequence of non-merging ATM-LSRs.
	11.2. When to Send Path Vectors Upstream		11.2. When to Send Path Vectors Upstream
	As specified in section 8, there are circumstances in which an LSR R		As specified in section 8, there are circumstances in which an LSR R
	must inform its upstream neighbors, via a label binding response		must inform its upstream neighbors, via a label binding response
	message, of a change in hop count for a particular LSP. If the		message, of a change in hop count for a particular LSP. If the
	following conditions all hold:		following conditions all hold:
	- R is configured for the LDPV procedure,		- R is configured for the LDPV procedure,
	- R supports VC-merge,		- R supports VC-merge,
	- R is not the egress for that LSP, and		- R is not the egress for that LSP, and
	- R is not informing its neighbors of a decrease in the hop count,		- R is not informing its neighbors of a decrease in the hop
			count,
	then R MUST include a path vector object in the response message.		then R MUST include a path vector object in the response message.
	If the change in hop count is a result of R's having been informed by		If the change in hop count is a result of R's having been informed by
	its next hop, S, of a change in hop count, and the message from S to		its next hop, S, of a change in hop count, and the message from S to
	R included a path vector object, then if the above conditions hold, R		R included a path vector object, then if the above conditions hold, R
	MUST add itself to this object and pass the result upstream.		MUST add itself to this object and pass the result upstream.
	Otherwise, if the above conditions hold, R MUST create a new object		Otherwise, if the above conditions hold, R MUST create a new object
	with only its own address.		with only its own address.
	skipping to change at page 19, line 34		skipping to change at page 18, line 13
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	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 which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	14. References		14. References
	[1] Rosen E., Viswanathan, A., Callon R., "Multi-Protocol Label		[1] Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol Label
	Switching Architecture", Work in Progress, August 1999.		Switching Architecture", RFC 3031, January 2001.
	[2] Andersson L., Doolan P., Feldman N., Fredette A., Thomas R., "LDP		[2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas,
	Specification", Work in Progress, June 2000.		"LDP Specification", RFC 3036, January 2001.
	[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G.,		[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G.,
	Li, T., Conta, A., "MPLS Label Stack Encoding", Work in Progress,		Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
	September 1999.		January 2001.
	[4] Nagami, K., Demizu N., Esaki H., Doolan P., "VCID Notification		[4] Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID Notification
	over ATM link", Work in Progress, July 1999.		over ATM Link for LDP", RFC 3038, January 2001.
	[5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM		[5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM
	Adaptation Layer 5", RFC 2684, September 1999		Adaptation Layer 5", RFC 2684, September 1999.
	15. Acknowledgments		15. Acknowledgments
	Significant contributions to this work have been made by Anthony		Significant contributions to this work have been made by Anthony
	Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan		Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan
	Littlewood and Dan Tappan. We thank Alex Conta for his comments.		Littlewood and Dan Tappan. We thank Alex Conta for his comments.
	16. Authors' Addresses		16. Authors' Addresses
	Bruce Davie		Bruce Davie
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA, 01824		Chelmsford, MA, 01824
	E-mail: bsd@cisco.com		EMail: bsd@cisco.com
	Paul Doolan		Paul Doolan
	Ennovate Networks Inc.		Ennovate Networks Inc.
	330 Codman Hill Rd		60 Codman Hill Rd
	Boxborough, MA 01719		Boxborough, MA 01719
	E-mail: pdoolan@ennovatenetworks.com		EMail: pdoolan@ennovatenetworks.com
	Jeremy Lawrence		Jeremy Lawrence
	Cisco Systems, Inc.		Cisco Systems, Inc.
	99 Walker St.		99 Walker St.
	North Sydney, NSW, Australia		North Sydney, NSW, Australia
	E-mail: jlawrenc@cisco.com		EMail: jlawrenc@cisco.com
	Keith McCloghrie		Keith McCloghrie
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA, 95134		San Jose, CA, 95134
	E-mail: kzm@cisco.com		EMail: kzm@cisco.com
	Yakov Rekhter		Yakov Rekhter
	Cisco Systems, Inc.		Juniper Networks
	170 Tasman Drive		1194 N. Mathilda Avenue
	San Jose, CA, 95134		Sunnyvale, CA 94089
			EMail: yakov@juniper.net
	E-mail: yakov@cisco.com
	Eric Rosen		Eric Rosen
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA, 01824		Chelmsford, MA, 01824
	E-mail: erosen@cisco.com		EMail: erosen@cisco.com
	George Swallow		George Swallow
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA, 01824		Chelmsford, MA, 01824
	E-mail: swallow@cisco.com		EMail: swallow@cisco.com
	17. Full Copyright Statement		17. Full Copyright Statement
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2001). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implmentation may be prepared, copied, published and		or assist in its implementation may be prepared, copied, published
	distributed, in whole or in part, without restriction of any kind,		and distributed, in whole or in part, without restriction of any
	provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
			This document and the information contained herein is provided on an
			"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIMS 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.
			Acknowledgement
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 76 change blocks.
	180 lines changed or deleted		169 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/