< draft-ietf-mpls-recovery-frmwrk-01.txt		draft-ietf-mpls-recovery-frmwrk-02.txt >
	IETF Draft Vishal Sharma		IETF Draft Vishal Sharma
	Multi-Protocol Label Switching Ben-Mack Crane		Multi-Protocol Label Switching Jasmine Networks, Inc.
	Expires: May 2001 Srinivas Makam		Expires: August 2001
	Ken Owens		Ben-Mack Crane
			Srinivas Makam
	Tellabs Operations, Inc.		Tellabs Operations, Inc.
			Ken Owens
			Erlang Technology, Inc.
	Changcheng Huang		Changcheng Huang
	Carleton University		Carleton University
	Fiffi Hellstrand		Fiffi Hellstrand
	Jon Weil		Jon Weil
	Loa Andersson		Loa Andersson
	Bilel Jamoussi		Bilel Jamoussi
	Nortel Networks		Nortel Networks
	Brad Cain		Brad Cain
	Mirror Image Internet		Mirror Image Internet
	Seyhan Civanlar		Seyhan Civanlar
	Coreon Networks		Coreon Networks
	Angela Chiu		Angela Chiu
	AT&T Labs		Celion Networks, Inc.
	November 2000		March 2001
	Framework for MPLS-based Recovery		Framework for MPLS-based Recovery
	<draft-ietf-mpls-recovery-frmwrk-01.txt>		<draft-ietf-mpls-recovery-frmwrk-02.txt>
	Status of this memo		Status of this memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	skipping to change at page 1, line 49 ¶		skipping to change at page 2, line 4 ¶
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	Multi-protocol label switching (MPLS) [1] integrates the label		Multi-protocol label switching (MPLS) [1] integrates the label
	swapping forwarding paradigm with network layer routing. To deliver		swapping forwarding paradigm with network layer routing. To deliver
	reliable service, MPLS requires a set of procedures to provide		reliable service, MPLS requires a set of procedures to provide
	protection of the traffic carried on different paths. This requires		protection of the traffic carried on different paths. This requires
	that the label switched routers (LSRs) support fault detection, fault		that the label switched routers (LSRs) support fault detection, fault
	notification, and fault recovery mechanisms, and that MPLS signaling		notification, and fault recovery mechanisms, and that MPLS signaling
	[2] [3] [4] [5] [6] support the configuration of recovery. With these		[2], [3], [4], [5], [6], [7] support the configuration of recovery.
	objectives in mind, this document specifies a framework for MPLS		With these objectives in mind, this document specifies a framework
	based recovery.		for MPLS based recovery.
	Table of Contents Page		Table of Contents Page
	1.0 Introduction 3		1.0 Introduction 3
	1.1 Background 3		1.1 Background 3
	1.2 Motivations for MPLS-Based Recovery 3		1.2 Motivations for MPLS-Based Recovery 3
	1.3 Objectives 4		1.3 Objectives 4
	2.0 Overview 5		2.0 Overview 5
	2.1 Recovery Models 6		2.1 Recovery Models 6
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 52 ¶
	3.4.3 Bypass Tunnels 19		3.4.3 Bypass Tunnels 19
	3.4.4 Recovery Granularity 20		3.4.4 Recovery Granularity 20
	3.4.4.1 Selective Traffic Recovery 20		3.4.4.1 Selective Traffic Recovery 20
	3.4.4.2 Bundling 20		3.4.4.2 Bundling 20
	3.4.5 Recovery Path Resource Use 20		3.4.5 Recovery Path Resource Use 20
	3.5 Fault Detection 21		3.5 Fault Detection 21
	3.6 Fault Notification 21		3.6 Fault Notification 21
	3.7 Switch Over Operation 22		3.7 Switch Over Operation 22
	3.7.1 Recovery Trigger 22		3.7.1 Recovery Trigger 22
	3.7.2 Recovery Action 22		3.7.2 Recovery Action 22
	3.8 Switch Back Operation 23		3.8 Post Recovery Operation 23
	3.8.1 Fixed Protection Counterparts 23		3.8.1 Fixed Protection Counterparts 23
	3.8.2 Dynamic Protection Counterparts 24		3.8.2 Dynamic Protection Counterparts 24
	3.8.3 Restoration and Notification 25		3.8.3 Restoration and Notification 25
	3.8.4 Reverting to Preferred Path 25		3.8.4 Reverting to Preferred Path 25
	3.9 Performance 26		3.9 Performance 26
	4.0 Recovery Requirements 26		4.0 Recovery Requirements 26
	5.0 MPLS Recovery Options 27		5.0 MPLS Recovery Options 27
	6.0 Comparison Criteria 27		6.0 Comparison Criteria 27
	7.0 Security Considerations 29		7.0 Security Considerations 29
	skipping to change at page 3, line 31 ¶		skipping to change at page 3, line 35 ¶
	1.1 Background		1.1 Background
	Network routing deployed today is focussed primarily on connectivity		Network routing deployed today is focussed primarily on connectivity
	and typically supports only one class of service, the best effort		and typically supports only one class of service, the best effort
	class. Multi-protocol label switching, on the other hand, by		class. Multi-protocol label switching, on the other hand, by
	integrating forwarding based on label-swapping of a link local label		integrating forwarding based on label-swapping of a link local label
	with network layer routing allows flexibility in the delivery of new		with network layer routing allows flexibility in the delivery of new
	routing services. MPLS allows for using such media specific		routing services. MPLS allows for using such media specific
	forwarding mechanisms as label swapping. This enables more		forwarding mechanisms as label swapping. This enables more
	sophisticated features such as quality-of-service (QoS) and traffic		sophisticated features such as quality-of-service (QoS) and traffic
	engineering [7] to be implemented more effectively. An important		engineering [8] to be implemented more effectively. An important
	component of providing QoS, however, is the ability to transport data		component of providing QoS, however, is the ability to transport data
	reliably and efficiently. Although the current routing algorithms are		reliably and efficiently. Although the current routing algorithms are
	very robust and survivable, the amount of time they take to recover		very robust and survivable, the amount of time they take to recover
	from a fault can be significant, on the order of several seconds or		from a fault can be significant, on the order of several seconds or
	minutes, causing serious disruption of service for some applications		minutes, causing serious disruption of service for some applications
	in the interim. This is unacceptable to many organizations that aim		in the interim. This is unacceptable to many organizations that aim
	to provide a highly reliable service, and thus require recovery times		to provide a highly reliable service, and thus require recovery times
	on the order of tens of milliseconds, as specified, for example, in		on the order of tens of milliseconds, as specified, for example, in
	the GR253 specification for SONET.		the GR253 specification for SONET.
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 37 ¶
	2.1 Recovery Models		2.1 Recovery Models
	There are two basic models for path recovery: rerouting and		There are two basic models for path recovery: rerouting and
	protection switching.		protection switching.
	Protection switching and rerouting, as defined below, may be used		Protection switching and rerouting, as defined below, may be used
	together. For example, protection switching to a recovery path may		together. For example, protection switching to a recovery path may
	be used for rapid restoration of connectivity while rerouting		be used for rapid restoration of connectivity while rerouting
	determines a new optimal network configuration, rearranging paths, as		determines a new optimal network configuration, rearranging paths, as
	needed, at a later time [8] [9].		needed, at a later time [9] [10].
	2.1.1 Rerouting		2.1.1 Rerouting
	Recovery by rerouting is defined as establishing new paths or path		Recovery by rerouting is defined as establishing new paths or path
	segments on demand for restoring traffic after the occurrence of a		segments on demand for restoring traffic after the occurrence of a
	fault. The new paths may be based upon fault information, network		fault. The new paths may be based upon fault information, network
	routing policies, pre-defined configurations and network topology		routing policies, pre-defined configurations and network topology
	information. Thus, upon detecting a fault, paths or path segments to		information. Thus, upon detecting a fault, paths or path segments to
	bypass the fault are established using signaling. Reroute mechanisms		bypass the fault are established using signaling. Reroute mechanisms
	are inherently slower than protection switching mechanisms, since		are inherently slower than protection switching mechanisms, since
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 15 ¶
	In terms of the principles defined in section 3, reroute recovery		In terms of the principles defined in section 3, reroute recovery
	employs paths established-on-demand with resources reserved-on-		employs paths established-on-demand with resources reserved-on-
	demand.		demand.
	2.1.2 Protection Switching		2.1.2 Protection Switching
	Protection switching recovery mechanisms pre-establish a recovery		Protection switching recovery mechanisms pre-establish a recovery
	path or path segment, based upon network routing policies, the		path or path segment, based upon network routing policies, the
	restoration requirements of the traffic on the working path, and		restoration requirements of the traffic on the working path, and
	administrative considerations. The recovery path may or may not be		administrative considerations. The recovery path may or may not be
	link and node disjoint with the working path [10]. However if the		link and node disjoint with the working path[11], [14]. However if
	recovery path shares sources of failure with the working path, the		the recovery path shares sources of failure with the working path,
	overall reliability of the construct is degraded. When a fault is		the overall reliability of the construct is degraded. When a fault is
	detected, the protected traffic is switched over to the recovery		detected, the protected traffic is switched over to the recovery
	path(s) and restored.		path(s) and restored.
	In terms of the principles in section 3, protection switching employs		In terms of the principles in section 3, protection switching employs
	pre-established recovery paths, and if resource reservation is		pre-established recovery paths, and if resource reservation is
	required on the recovery path, pre-reserved resources.		required on the recovery path, pre-reserved resources.
	2.1.2.1. Subtypes of Protection Switching		2.1.2.1. Subtypes of Protection Switching
	The resources (bandwidth, buffers, processing) on the recovery path		The resources (bandwidth, buffers, processing) on the recovery path
	may be used to carry either a copy of the working path traffic or		may be used to carry either a copy of the working path traffic or
	skipping to change at page 12, line 29 ¶		skipping to change at page 12, line 35 ¶
	VI. The network enters a semi-stable state		VI. The network enters a semi-stable state
	VII. Dynamic routing protocols converge after the fault, and a new		VII. Dynamic routing protocols converge after the fault, and a new
	working path is calculated (based, for example, on some of the		working path is calculated (based, for example, on some of the
	criteria mentioned earlier in Section 2.1.1).		criteria mentioned earlier in Section 2.1.1).
	VIII. A new working path is established between the PSL and the PML		VIII. A new working path is established between the PSL and the PML
	(assumption is that PSL and PML have not changed)		(assumption is that PSL and PML have not changed)
	IX. Traffic is switched over to the new working path.		IX. Traffic is switched over to the new working path.
	2.3 Definitions and Terminology		2.3 Definitions and Terminology
	This document assumes the terminology given in [11], and, in		This document assumes the terminology given in [1], and, in addition,
	addition, introduces the following new terms.		introduces the following new terms.
	2.3.1 General Recovery Terminology		2.3.1 General Recovery Terminology
	Rerouting		Rerouting
	A recovery mechanism in which the recovery path or path segments are		A recovery mechanism in which the recovery path or path segments are
	created dynamically after the detection of a fault on the working		created dynamically after the detection of a fault on the working
	path. In other words, a recovery mechanism in which the recovery path		path. In other words, a recovery mechanism in which the recovery path
	is not pre-established.		is not pre-established.
	skipping to change at page 15, line 40 ¶		skipping to change at page 15, line 48 ¶
	layer.		layer.
	Link Degraded (LD)		Link Degraded (LD)
	A lower layer indication to MPLS-based recovery mechanisms that the		A lower layer indication to MPLS-based recovery mechanisms that the
	link is performing below an acceptable level.		link is performing below an acceptable level.
	Fault Indication Signal (FIS)		Fault Indication Signal (FIS)
	A signal that indicates that a fault along a path has occurred. It is		A signal that indicates that a fault along a path has occurred. It is
	relayed by each intermediate LSR to its upstream or downstream		relayed by each intermediate LSR to its upstream or downstream
	neighbor, until it reaches an LSR that is setup to perform MPLS		neighbor, until it reaches an LSR that is setup to perform MPLS
	recovery.		recovery. The FIS is transmitted periodically by the node/nodes
			closest to the point of failure, for some configurable length of
			time.
	Fault Recovery Signal (FRS)		Fault Recovery Signal (FRS)
	A signal that indicates a fault along a working path has been		A signal that indicates a fault along a working path has been
	repaired. Again, like the FIS, it is relayed by each intermediate LSR		repaired. Again, like the FIS, it is relayed by each intermediate LSR
	to its upstream or downstream neighbor, until is reaches the LSR that		to its upstream or downstream neighbor, until is reaches the LSR that
	performs recovery of the original path.		performs recovery of the original path. . The FRS is transmitted
			periodically by the node/nodes closest to the point of failure, for
			some configurable length of time.
	2.4 Abbreviations		2.4 Abbreviations
	FIS: Fault Indication Signal.		FIS: Fault Indication Signal.
	FRS: Fault Recovery Signal.		FRS: Fault Recovery Signal.
	LD: Link Degraded.		LD: Link Degraded.
	LF: Link Failure.		LF: Link Failure.
	PD: Path Degraded.		PD: Path Degraded.
	PF: Path Failure.		PF: Path Failure.
	PML: Path Merge LSR.		PML: Path Merge LSR.
	skipping to change at page 20, line 10 ¶		skipping to change at page 20, line 23 ¶
	protection paths are mapped to each other. The issues of resource		protection paths are mapped to each other. The issues of resource
	reservation along these paths, and how switchover is actually		reservation along these paths, and how switchover is actually
	performed lead to the more commonly used composite terms, such as 1+1		performed lead to the more commonly used composite terms, such as 1+1
	and 1:1 protection, which were described in Section 2.1.		and 1:1 protection, which were described in Section 2.1.
	1-to-1 Protection		1-to-1 Protection
	In 1-to-1 protection the working path has a designated recovery path		In 1-to-1 protection the working path has a designated recovery path
	that is only to be used to recover that specific working path.		that is only to be used to recover that specific working path.
	ii) n-to-1 Protection		n-to-1 Protection
	In n-to-1 protection, up to n working paths are protected using only		In n-to-1 protection, up to n working paths are protected using only
	one recovery path. If the intent is to protect against any single		one recovery path. If the intent is to protect against any single
	fault on any of the working paths, the n working paths should be		fault on any of the working paths, the n working paths should be
	diversely routed between the same PSL and PML. In some cases,		diversely routed between the same PSL and PML. In some cases,
	handshaking between PSL and PML may be required to complete the		handshaking between PSL and PML may be required to complete the
	recovery, the details of which are beyond the scope of this draft.		recovery, the details of which are beyond the scope of this draft.
	n-to-m Protection		n-to-m Protection
	skipping to change at page 24, line 4 ¶		skipping to change at page 24, line 19 ¶
	with the difference that the LF is a lower layer impairment that may		with the difference that the LF is a lower layer impairment that may
	be communicated to - MPLS-based recovery mechanisms. The PD (or LD)		be communicated to - MPLS-based recovery mechanisms. The PD (or LD)
	fault, on the other hand, applies to soft defects (excessive errors		fault, on the other hand, applies to soft defects (excessive errors
	due to noise on the link, for instance). The PD (or LD) results in a		due to noise on the link, for instance). The PD (or LD) results in a
	fault declaration only when the percentage of lost packets exceeds a		fault declaration only when the percentage of lost packets exceeds a
	given threshold, which is provisioned and may be set based on the		given threshold, which is provisioned and may be set based on the
	service level agreement(s) in effect between a service provider and a		service level agreement(s) in effect between a service provider and a
	customer.		customer.
	3.7.2 Recovery Action		3.7.2 Recovery Action
	After a fault is detected or FIS is received by the PSL, the recovery		After a fault is detected or FIS is received by the PSL, the recovery
	action involves either a rerouting or protection switching operation.		action involves either a rerouting or protection switching operation.
	In both scenarios, the next hop label forwarding entry for a recovery		In both scenarios, the next hop label forwarding entry for a recovery
	path is bound to the working path.		path is bound to the working path.
	3.8 Switch-Back Operation		3.8 Post Recovery Operation
	When traffic is flowing on the recovery path decisions can be made to		When traffic is flowing on the recovery path decisions can be made to
	whether let the traffic remain on the recovery path and consider it		whether let the traffic remain on the recovery path and consider it
	as a new working path or do a switch to the old or a new working		as a new working path or do a switch to the old or a new working
	path. This switch-back operation has two styles, one where the		path. This post recovery operation has two styles, one where the
	protection counterparts, i.e. the working and recovery path, are		protection counterparts, i.e. the working and recovery path, are
	fixed or "pinned" to its route and one in which the PSL or other		fixed or "pinned" to its route and one in which the PSL or other
	network entity with real time knowledge of failure dynamically		network entity with real time knowledge of failure dynamically
	performs re-establishment or controlled rearrangement of the paths		performs re-establishment or controlled rearrangement of the paths
	comprising the protected service.		comprising the protected service.
	3.8.1 Fixed Protection Counterparts		3.8.1 Fixed Protection Counterparts
	For fixed protection counterparts the PSL will be pre-configured with		For fixed protection counterparts the PSL will be pre-configured with
	the appropriate behavior to take when the original fixed path is		the appropriate behavior to take when the original fixed path is
	skipping to change at page 25, line 33 ¶		skipping to change at page 25, line 48 ¶
	For Dynamic protection counterparts when the traffic is switched over		For Dynamic protection counterparts when the traffic is switched over
	to a recovery path, the association between the original working path		to a recovery path, the association between the original working path
	and the recovery path may no longer exist, since the original path		and the recovery path may no longer exist, since the original path
	itself may no longer exist after the fault. Instead, when the network		itself may no longer exist after the fault. Instead, when the network
	reaches a stable state following routing convergence, the recovery		reaches a stable state following routing convergence, the recovery
	path may be switched over to a different preferred path either		path may be switched over to a different preferred path either
	optimization based on the new network topology and associated		optimization based on the new network topology and associated
	information or based on pre-configured information.		information or based on pre-configured information.
	Dynamic protection counterparts assume that upon failure, the PSL or		Dynamic protection counterparts assume that upon failure, the PSL or
	other network entity will establish new working paths if a switch-		other network entity will establish new working paths if another
	back will be performed.		switch-over will be performed.
	3.8.3 Restoration and Notification		3.8.3 Restoration and Notification
	MPLS restoration deals with returning the working traffic from the		MPLS restoration deals with returning the working traffic from the
	recovery path to the original or a new working path. Reversion is		recovery path to the original or a new working path. Reversion is
	performed by the PSL either upon receiving notification, via FRS,		performed by the PSL either upon receiving notification, via FRS,
	that the working path is repaired, or upon receiving notification		that the working path is repaired, or upon receiving notification
	that a new working path is established.		that a new working path is established.
	For fixed counterparts in revertive mode, an LSR that detected the		For fixed counterparts in revertive mode, an LSR that detected the
	skipping to change at page 30, line 9 ¶		skipping to change at page 30, line 21 ¶
	IV. Percentage of coverage: dependent on a scheme and its		IV. Percentage of coverage: dependent on a scheme and its
	implementation, a certain percentage of faults may be covered. This		implementation, a certain percentage of faults may be covered. This
	may be subdivided into percentage of link faults and percentage of		may be subdivided into percentage of link faults and percentage of
	node faults.		node faults.
	V. The number of protected paths may effect how fast the total set of		V. The number of protected paths may effect how fast the total set of
	paths affected by a fault could be recovered. The ratio of protected		paths affected by a fault could be recovered. The ratio of protected
	is n/N, where n is the number of protected paths and N is the total		is n/N, where n is the number of protected paths and N is the total
	number of paths.		number of paths.
	7.0 Security Considerations		7.0 Security Considerations
	The MPLS recovery that is specified herein does not raise any		The MPLS recovery that is specified herein does not raise any
	security issues that are not already present in the MPLS		security issues that are not already present in the MPLS
	architecture.		architecture.
	8.0 Intellectual Property Considerations		8.0 Intellectual Property Considerations
	The IETF has been notified of intellectual property rights claimed in		The IETF has been notified of intellectual property rights claimed in
	regard to some or all of the specification contained in this		regard to some or all of the specification contained in this
	document. For more information consult the online list of claimed		document. For more information consult the online list of claimed
	rights.		rights.
	9.0 Acknowledgements		9.0 Acknowledgements
	We would like to thank members of the MPLS WG mailing list for their		We would like to thank members of the MPLS WG mailing list for their
	suggestions on the earlier version of this draft. In particular, Bora		suggestions on the earlier versions of this draft. In particular,
	Akyol, Dave Allan, and Neil Harrisson, whose suggestions and comments		Bora Akyol, Dave Allan, Neil Harrison, and Dave Danenberg whose
	were very helpful in revising the document.		suggestions and comments were very helpful in revising the document.
	10.0 Authors' Addresses		10.0 Authors' Addresses
	Vishal Sharma Ben Mack-Crane		Vishal Sharma Ben Mack-Crane
	Tellabs Research Center Tellabs Operations, Inc.		Jasmine Networks, Inc. Tellabs Operations, Inc.
	One Kendall Square 4951 Indiana Avenue		3061 B, Zanker Road 4951 Indiana Avenue
	Bldg. 100, Ste. 121 Lisle, IL 60532		San Jose, CA 95134 Lisle, IL 60532
	Cambridge, MA 02139-1562 Phone: 630-512-7255		Phone: 408-895-5030 Phone: 630-512-7255
	Phone: 617-577-8760 Ben.Mack-Crane@tellabs.com		vsharma@JasmineNetworks.com Ben.Mack-Crane@tellabs.com
	Vishal.Sharma@tellabs.com
	Srinivas Makam Ken Owens		Srinivas Makam Ken Owens
	Tellabs Operations, Inc. Tellabs Operations, Inc.		Tellabs Operations, Inc. Erlang Technology, Inc.
	4951 Indiana Avenue 1106 Fourth Street		Lisle, IL 60532 St. Louis, MO 63119
	Lisle, IL 60532 St. Louis, MO 63126		Phone: 630-512-7217
	Phone: 630-512-7217 Phone: 314-918-1579		Srinivas.Makam@tellabs.com keno@erlangtech.com
	Srinivas.Makam@tellabs.com Ken.Owens@tellabs.com
	Changcheng Huang Fiffi Hellstrand		Changcheng Huang Fiffi Hellstrand
	Dept. of Systems & Computer Engg. Nortel Networks		Dept. of Systems & Computer Engg. Nortel Networks
	Carleton University St Eriksgatan 115		Carleton University St Eriksgatan 115
	Minto Center, Rm. 3082 PO Box 6701		Minto Center, Rm. 3082 PO Box 6701
	1125 Colonial By Drive 113 85 Stockholm, Sweden		1125 Colonial By Drive 113 85 Stockholm, Sweden
	Ottawa, Ontario K1S 5B6, Canada Phone: +46 8 5088 3687		Ottawa, Ontario K1S 5B6, Canada Phone: +46 8 5088 3687
	Phone: 613 520-2600 x2477 Fiffi@nortelnetworks.com		Phone: 613 520-2600 x2477 Fiffi@nortelnetworks.com
	Changcheng.Huang@sce.carleton.ca		Changcheng.Huang@sce.carleton.ca
	Jon Weil Brad Cain		Jon Weil Brad Cain
	Nortel Networks Mirror Image Internet		Nortel Networks Mirror Image Internet
	Harlow Laboratories London Road 49 Dragon Ct.		Harlow Laboratories London Road 49 Dragon Ct.
	Harlow Essex CM17 9NA, UK Woburn, MA 01801, USA		Harlow Essex CM17 9NA, UK Woburn, MA 01801, USA
	Phone: +44 (0)1279 403935 bcain@mirror-image.com		Phone: +44 (0)1279 403935 bcain@mirror-image.com
	jonweil@nortelnetworks.com		jonweil@nortelnetworks.com
	Loa Andersson Bilel Jamoussi		Loa Andersson Bilel Jamoussi
	Nortel Networks Nortel Networks		Nortel Networks Nortel Networks
	St Eriksgatan 115, PO Box 6701 3 Federal Street, BL3-03		St Eriksgatan 115, PO Box 6701 3 Federal Street, BL3-03
	113 85 Stockholm, Sweden Billerica, MA 01821, USA		113 85 Stockholm, Sweden Billerica, MA 01821, USA
	Phone: +46 8 50 88 36 34 Phone:(978) 288-4506		Phone: +46 8 50 88 36 34 Phone:(978) 288-4506
	loa.andersson@nortelnetworks.com jamoussi@nortelnetworks.com		loa.andersson@nortelnetworks.com jamoussi@nortelnetworks.com
	Seyhan Civanlar Angela Chiu		Seyhan Civanlar Angela Chiu
	Coreon, Inc. AT&T Labs, Rm. 4-204		Coreon, Inc. Celion Networks, Inc.
	1200 South Avenue, Suite 103 100 Schulz Drive		1200 South Avenue, Suite 103 One Shiela Drive, Suite 2
	Staten Island, NY 10314 Red Bank, NJ 07701		Staten Island, NY 10314 Tinton Falls, NJ 07724
	Phone: (718) 889 4203 Phone: (732) 345-3441		Phone: (718) 889 4203 Phone: (732) 345-3441
	scivanlar@coreon.net alchiu@att.com		scivanlar@coreon.net angela.chiu@celion.com
	11.0 References		11.0 References
	[1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label		[1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label
	Switching Architecture", Internet Draft draft-ietf-mpls-arch-07.txt,		Switching Architecture", RFC 3031, January 2001.
	Work in Progress , July 2000.
	[2] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B.,		[2] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B.,
	"LDP Specification", Internet Draft draft-ietf-mpls-ldp-11.txt, Work in		"LDP Specification", RFC 3036, January 2001.
	Progress , August 2000.
	[3] Awduche, D. Hannan, A., and Xiao, X., "Applicability Statement for		[3] Awduche, D. Hannan, A., and Xiao, X., "Applicability Statement for
	Extensions to RSVP for LSP-Tunnels", draft-ietf-mpls-rsvp-tunnel-		Extensions to RSVP for LSP-Tunnels", draft-ietf-mpls-rsvp-tunnel-
	applicability-01.txt, work in progress, April 2000.		applicability-01.txt, work in progress, April 2000.
	[4] Jamoussi, B. et al "Constraint-Based LSP Setup using LDP", Internet		[4] Jamoussi, B. et al "Constraint-Based LSP Setup using LDP", Internet
	Draft draft-ietf-mpls-cr-ldp-04.txt, Work in Progress , July 2000.		Draft draft-ietf-mpls-cr-ldp-04.txt, Work in Progress , July 2000.
	[5] Braden, R., Zhang, L., Berson, S., Herzog, S., "Resource ReSerVation		[5] Braden, R., Zhang, L., Berson, S., Herzog, S., "Resource ReSerVation
	Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205,		Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205,
	September 1997.		September 1997.
	[6] Awduche, D. et al "Extensions to RSVP for LSP Tunnels", Internet		[6] Awduche, D. et al "Extensions to RSVP for LSP Tunnels", Internet
	Draft draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, Work in Progress, August		Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, Work in Progress, August
	2000.		2000.
	[7] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J.,		[7] Hellstrand, F., and Andersson, L., "Extensions to RSVP-TE and CR-LDP
	"Requirements for Traffic Engineering Over MPLS", RFC 2702, September		for setup of pre-established LSP Tunnels," Internet Draft, Work in
	1999.		Progress, draft-hellstrand-mpls-recovery-merge-01.txt, November 2000.
	[8] Andersson, L., Cain B., Jamoussi, B., "Requirement Framework for		[8] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J.,
	Fast Re-route with MPLS", draft-andersson-reroute-frmwrk-00.txt, work in		"Requirements for Traffic Engineering Over MPLS", RFC 2702, September
	progress, October 1999.		1999.
	[9] Goguen, R. and Swallow, G., "RSVP Label Allocation for Backup		[9] Kini, S, Lakshman, T. V., Villamizar, C., "Shared Backup Label
	Tunnels", draft-swallow-rsvp-bypass-label-00.txt, work in progress,		Switched Path Restoration, " Internet Draft, Work in Progress, draft-
	October 1999.		kini-restoration-shared-backup-00.txt, October 2000.
	[10] Makam, S., Sharma, V., Owens, K., Huang, C.,		[10] Goguen, R. and Swallow, G., "RSVP Label Allocation for Backup
	"Protection/restoration of MPLS Networks", Internet Draft draft-makam-		Tunnels", draft-swallow-rsvp-bypass-label-01.txt, work in progress,
	mpls-protection-00.txt, work in progress, October 1999.		November 2000.
	[11] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G.,		[11] Kini, S., Lakshman, T. V., Villamizar, C., "Reservation Protocol
	Viswanathan, A., "A Framework for Multiprotocol Label Switching",		with Traffic Engineering Extensions: Extension for Label Switched Path
	Internet Draft draft-ietf-mpls-framework-05.txt, Work in Progress,		Restoration," Internet Draft, Work in Progress, draft-kini-rsvp-lsp-
	September 1999.		restoration-00.txt, November 2000.
	[12] Haskin, D. and Krishnan R., "A Method for Setting an Alternative		[12] Haskin, D. and Krishnan R., "A Method for Setting an Alternative
	Label Switched Path to Handle Fast Reroute", Internet Draft draft-		Label Switched Path to Handle Fast Reroute", Internet Draft draft-
	haskin-mpls-fast-reroute-05.txt, November 2000, Work in progress.		haskin-mpls-fast-reroute-05.txt, November 2000, Work in progress.
	[13] Owens, K., Makam,V., Sharma, V., Mack-Crane, B., and Haung, C., "A		[13] Owens, K., Makam, V., Sharma, V., Mack-Crane, B., and Haung, C., "A
	Path Protection/Restoration Mechanism for MPLS Networks", Internet		Path Protection/Restoration Mechanism for MPLS Networks", Internet
	Draft, draft-chang-mpls-path-protection-02.txt, Work in Progress		Draft, draft-chang-mpls-path-protection-02.txt, Work in Progress
	November 2000.		November 2000.
End of changes. 35 change blocks.
	67 lines changed or deleted		72 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/