draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt		draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt
	Internet Draft Ping Pan, Ed (Ciena Corp)		Internet Draft Ping Pan, Ed (Ciena Corp)
	Expires: May 2003 Der-Hwa Gan (Juniper Networks)		Expires: Aug 2003 Der-Hwa Gan (Juniper Networks)
	George Swallow (Cisco Systems)		George Swallow (Cisco Systems)
	Jean Philippe Vasseur (Cisco Systems)		Jean Philippe Vasseur (Cisco Systems)
	Dave Cooper (Global Crossing)		Dave Cooper (Global Crossing)
	Alia Atlas, Ed (Avici Systems)		Alia Atlas, Ed (Avici Systems)
	Markus Jork (Avici Systems)		Markus Jork (Avici Systems)
	Fast Reroute Extensions to RSVP-TE for LSP Tunnels		Fast Reroute Extensions to RSVP-TE for LSP Tunnels
	draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt		draft-ietf-mpls-rsvp-lsp-fastreroute-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		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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
	This document defines extensions to and describes the use of RSVP		This document defines extensions to and describes the use of RSVP to
	[RSVP, RSVP-TE] to establish backup LSP tunnels for local repair of		establish backup label-switched path (LSP) tunnels for local repair
	LSP tunnels. These mechanisms enable the re-direction of traffic		of LSP tunnels. These mechanisms enable the re-direction of traffic
	onto backup LSP tunnels in 10s of milliseconds in the event of a		onto backup LSP tunnels in 10s of milliseconds in the event of a
	failure.		failure.
	Two methods are defined here. The one-to-one backup method creates		Two methods are defined here. The one-to-one backup method creates
	detour LSPs for each protected LSP at each potential point of local		detour LSPs for each protected LSP at each potential point of local
	repair. The facility backup method creates a bypass tunnel to		repair. The facility backup method creates a bypass tunnel to
	protect a potential failure point; by taking advantage of MPLS label		protect a potential failure point; by taking advantage of MPLS label
	stacking, this bypass tunnel can protect a set of protected LSPs that		stacking, this bypass tunnel can protect a set of protected LSPs that
	have similar backup constraints. Both methods can be used to protect		have similar backup constraints. Both methods can be used to protect
	links and nodes during network failure. The described behavior and		links and nodes during network failure. The described behavior and
	extensions to RSVP allow LERs and LSRs to implement either or both		extensions to RSVP allow nodes to implement either or both methods
	methods and to interoperate in a mixed network.		and to interoperate in a mixed network.
	Contents		Contents
	1 Introduction ............................................. 4		1 Introduction ............................................. 4
	2 Terminology ............................................... 4		2 Terminology ............................................... 4
	3 Local Repair Techniques ................................... 6		3 Local Repair Techniques ................................... 6
	3.1 One-to-one Backup ....................................... 6		3.1 One-to-one Backup .................................... 6
	3.2 Facility Backup ......................................... 7		3.2 Facility Backup ...................................... 7
	4 RSVP Extensions ........................................... 8		4 RSVP Extensions ........................................... 8
	4.1 FAST_REROUTE Object ..................................... 8		4.1 FAST_REROUTE Object .................................... 8
	4.2 DETOUR Object ........................................... 11		4.2 DETOUR Object .......................................... 11
	4.3 SESSION_ATTRIBUTE Flags ................................. 12		4.3 SESSION_ATTRIBUTE Flags ................................ 12
	4.4 RRO IPv4/IPv6 Sub-Object Flags .......................... 13		4.4 RRO IPv4/IPv6 Sub-Object Flags ......................... 13
	5 Head-End Behavior ......................................... 14		5 Head-End Behavior ......................................... 14
	6 Point of Local Repair Behavior ............................ 15		6 Point of Local Repair Behavior ............................ 15
	6.1 Signaling a Backup Path ................................. 16		6.1 Signaling a Backup Path ................................ 16
	6.1.1 Backup Path Identification: Sender-Template Specific ... 17		6.1.1 Backup Path Identification: Sender-Template Specific . 17
	6.1.2 Backup Path Identification: Path-Specific ............. 18		6.1.2 Backup Path Identification: Path-Specific ........... 18
	6.2 Procedures for Backup Path Computation .................. 18		6.2 Procedures for Backup Path Computation ................. 18
	6.3 Signaling Backups for One-To-One Protection ............. 20		6.3 Signaling Backups for One-To-One Protection ............ 20
	6.3.1 Make-Before-Break with Detour LSPs .................... 21		6.3.1 Make-Before-Break with Detour LSPs .................. 21
	6.3.2 Message Handling ...................................... 21		6.3.2 Message Handling .................................... 21
	6.3.3 Local Reroute of Traffic Onto Detour LSP .............. 22		6.3.3 Local Reroute of Traffic Onto Detour LSP ............ 22
	6.4 Signaling for Facility Protection ....................... 23		6.4 Signaling for Facility Protection ...................... 23
	6.4.1 Discovering Downstream Labels ......................... 23		6.4.1 Discovering Downstream Labels ....................... 23
	6.4.2 Procedures for the PLR before Local Repair ............ 23		6.4.2 Procedures for the PLR before Local Repair .......... 23
	6.4.3 Procedures for the PLR during Local Repair ............ 23		6.4.3 Procedures for the PLR during Local Repair .......... 23
	6.4.4 Processing backup tunnel's ERO ........................ 24		6.4.4 Processing backup tunnel's ERO ...................... 24
	6.5 PLR Procedures During Local Repair ...................... 25		6.5 PLR Procedures During Local Repair ..................... 25
	6.5.1 Notification of local repair .......................... 25		6.5.1 Notification of local repair ........................ 25
	6.5.2 Revertive Behavior .................................... 26		6.5.2 Revertive Behavior .................................. 26
	7 Merge Node Behavior ....................................... 27		7 Merge Node Behavior ....................................... 27
	7.1 Handling Backup Path Messages Before Failure ............ 27		7.1 Handling Backup Path Messages Before Failure ........... 27
	7.1.1 Merging Backup Paths using the Sender-Template		7.1.1 Merging Backup Paths using the Sender-Template
	Specific Method ....................................... 28		Specific Method ..................................... 28
	7.1.2 Merging Detours using Path-Specific Method ............ 28		7.1.2 Merging Detours using Path-Specific Method .......... 28
	7.1.2.1 An Example on Path Message Merging .................. 29		7.1.2.1 An Example on Path Message Merging ............... 29
	7.1.3 Message Handling for Merged Detours ................... 30		7.1.3 Message Handling for Merged Detours ................. 30
	7.2 Handling Failures ....................................... 30		7.2 Handling Failures ...................................... 30
	8 Behavior of all LSRs ...................................... 31		8 Behavior of all LSRs ...................................... 31
	8.1 Merging Detours in Path-Specific Method ................. 31		8.1 Merging Detours in Path-Specific Method ................ 31
	9 Security Considerations ................................... 32		9 Security Considerations ................................... 32
	10 IANA Guidelines ........................................... 32		10 IANA Guidelines ........................................... 32
	11 Intellectual Property Considerations ...................... 32		11 Intellectual Property Considerations ...................... 32
	12 Full Copyright Statement .................................. 32		12 Full Copyright Statement .................................. 32
	13 Acknowledgments ........................................... 33		13 Acknowledgments ........................................... 33
	14 References ................................................ 33		14 Normative References ...................................... 33
	15 Author Information ........................................ 33		15 Author Information ........................................ 33
	1. Introduction		1. Introduction
	This document extends RSVP [RSVP] to establish backup LSP tunnels		This document extends RSVP [RSVP] to establish backup LSP tunnels
	for the local repair of LSP tunnels. This technique is presented		for the local repair of LSP tunnels. This technique is presented
	to meet the needs of real-time applications, such as voice over IP,		to meet the needs of real-time applications, such as voice over IP,
	for which it is highly desirable to be able to re-direct user		for which it is highly desirable to be able to re-direct user
	traffic onto backup LSP tunnels in 10s of milliseconds. This		traffic onto backup LSP tunnels in 10s of milliseconds. This
	timing requirement can be satisfied by computing and signaling		timing requirement can be satisfied by computing and signaling
	skipping to change at page 4, line 40		skipping to change at page 4, line 40
	protection are described. In Section 5, the behavior of an LER		protection are described. In Section 5, the behavior of an LER
	which wishes to request local protection for an LSP is presented.		which wishes to request local protection for an LSP is presented.
	The behavior of a potential point of local repair (PLR) is given in		The behavior of a potential point of local repair (PLR) is given in
	Section 6; this describes how to determine the appropriate strategy		Section 6; this describes how to determine the appropriate strategy
	to use for protecting an LSP and how to implement each of the		to use for protecting an LSP and how to implement each of the
	strategies. The behavior of a merge node, the LSR where a		strategies. The behavior of a merge node, the LSR where a
	protected LSP and its backup LSP rejoin, is described in Section 7.		protected LSP and its backup LSP rejoin, is described in Section 7.
	Finally, the required behavior of other nodes in the network is		Finally, the required behavior of other nodes in the network is
	discussed in Section 8.		discussed in Section 8.
			For the techniques discussed in this document to function properly,
			there are three assumptions which must be made. First, an LSR
			which is on the path of a protected LSP SHOULD always assume that
			it is a merge point; this is necessary because the facility backup
			method does not signal backups through a bypass tunnel before
			failure. Second, if the one-to-one backup method is used and a
			DETOUR object is included, the LSRs in the traffic-engineered
			network should support the DETOUR object; this is necessary so that
			the Path message containing the DETOUR object is not rejected.
			Third, understanding of the DETOUR object is required to support
			the path-specific method which requires that LSRs in the
			traffic-engineered network be capable of merging detours.
	2. Terminology		2. Terminology
	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 RFC2119 [RFC-WORDS].		document are to be interpreted as described in RFC2119 [RFC-WORDS].
	The reader is assumed to be familiar with the terminology in [RSVP]		The reader is assumed to be familiar with the terminology in [RSVP]
	and [RSVP-TE].		and [RSVP-TE].
	LSR - Label Switch Router		LSR - Label Switch Router
	skipping to change at page 12, line 15		skipping to change at page 12, line 19
	is preferred. This field is mandatory, and is used by		is preferred. This field is mandatory, and is used by
	the MP for merging rules discussed below.		the MP for merging rules discussed below.
	There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in		There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in
	a DETOUR object. If detour merging is desired, after each merging		a DETOUR object. If detour merging is desired, after each merging
	operation, the Detour Merge Point should combine all the merged		operation, the Detour Merge Point should combine all the merged
	detours in the subsequent Path messages.		detours in the subsequent Path messages.
	The high-order bit of the C-Class is zero; LSRs that do not support		The high-order bit of the C-Class is zero; LSRs that do not support
	the DETOUR objects MUST reject any Path message containing a DETOUR		the DETOUR objects MUST reject any Path message containing a DETOUR
	object and send a PathErr to notify the PLR.		object and send a PathErr to notify the PLR. This PathErr SHOULD
			be generated as specified in [RSVP] for unknown objects with a
			class-num of the form "0bbbbbbb".
	4.3. SESSION_ATTRIBUTE Flags		4.3. SESSION_ATTRIBUTE Flags
	To explicitly request bandwidth and node protection, two new flags		To explicitly request bandwidth and node protection, two new flags
	are defined in the SESSION_ATTRIBUTE object.		are defined in the SESSION_ATTRIBUTE object.
	For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has		For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has
	the following flags defined:		the following flags defined:
	Local protection desired: 0x01		Local protection desired: 0x01
	skipping to change at page 14, line 41		skipping to change at page 14, line 45
	SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the		SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the
	PATH message or both. It is recommended that the "local protection		PATH message or both. It is recommended that the "local protection
	desired" flag in the SESSION_ATTRIBUTE object always be set. If a		desired" flag in the SESSION_ATTRIBUTE object always be set. If a
	head-end LSR signals a FAST_REROUTE object, it MUST be stored for		head-end LSR signals a FAST_REROUTE object, it MUST be stored for
	Path refreshes.		Path refreshes.
	The head-end LSR of a protected LSP MUST set the "label recording		The head-end LSR of a protected LSP MUST set the "label recording
	desired" flag in the SESSION_ATTRIBUTE object. This facilitates		desired" flag in the SESSION_ATTRIBUTE object. This facilitates
	the use of the facility backup technique. If node protection is		the use of the facility backup technique. If node protection is
	desired, the head-end LSR should set the "node protection desired"		desired, the head-end LSR should set the "node protection desired"
	flag in the SESSION_ATTRIBUTE object; if only link protection is		flag in the SESSION_ATTRIBUTE object; otherwise this flag should be
	desired, this flag should be cleared. Similarly, if a guarantee of		cleared. Similarly, if a guarantee of bandwidth protection is
	bandwidth protection is desired, then the "bandwidth protection		desired, then the "bandwidth protection desired" flag in the
	desired" flag in the SESSION_ATTRIBUTE object should be set;		SESSION_ATTRIBUTE object should be set; otherwise, this flag should
	otherwise, this flag should be cleared.		be cleared.
	If the head-end LSR determines that control of the backup paths for		If the head-end LSR determines that control of the backup paths for
	the protected LSP is desired, then the LSR should include the		the protected LSP is desired, then the LSR should include the
	FAST_REROUTE object. The attribute filters, bandwidth, hop-limit		FAST_REROUTE object. The attribute filters, bandwidth, hop-limit
	and priorities will be used by the PLRs when determining the backup		and priorities will be used by the PLRs when determining the backup
	paths.		paths.
	If the head-end LSR desires that the protected LSP be protected via		If the head-end LSR desires that the protected LSP be protected via
	the one-to-one backup technique, then head-end LSR should include a		the one-to-one backup technique, then head-end LSR should include a
	FAST_REROUTE object and set the "one-to-one backup desired" flag.		FAST_REROUTE object and set the "one-to-one backup desired" flag.
	skipping to change at page 15, line 48		skipping to change at page 16, line 4
	A PLR MUST consider an LSP as having asked for local protection if		A PLR MUST consider an LSP as having asked for local protection if
	the "local protection desired" flag is set in the SESSION_ATTRIBUTE		the "local protection desired" flag is set in the SESSION_ATTRIBUTE
	object and/or the FAST_REROUTE object is included. If the		object and/or the FAST_REROUTE object is included. If the
	FAST_REROUTE object is included, a PLR SHOULD consider providing		FAST_REROUTE object is included, a PLR SHOULD consider providing
	one-to-one protection if the "one-to-one desired" is set and SHOULD		one-to-one protection if the "one-to-one desired" is set and SHOULD
	consider providing facility backup if the "facility backup desired"		consider providing facility backup if the "facility backup desired"
	flag is set when determining whether to provide local protection		flag is set when determining whether to provide local protection
	and which technique to use to provide that local protection. If		and which technique to use to provide that local protection. If
	the "node protection desired" flag is set, the PLR SHOULD try to		the "node protection desired" flag is set, the PLR SHOULD try to
	provide node protection; if this is not feasible, the PLR SHOULD		provide node protection; if this is not feasible, the PLR SHOULD
	then try to provide link protection.		then try to provide link protection. If the "bandwidth protection
			guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth
			guarantee; if this is not feasible, the PLR SHOULD then try to
			provide a backup without a guarantee of the full bandwidth.
	The following treatment for the RRO IPv4 or IPv6 sub-object's flags		The following treatment for the RRO IPv4 or IPv6 sub-object's flags
	must be followed if an RRO is included in the protected LSP's RESV		must be followed if an RRO is included in the protected LSP's RESV
	message. Based on this additional information the head-end may		message. Based on this additional information the head-end may
	take appropriate actions.		take appropriate actions.
	- Until a PLR has a backup path available, the PLR MUST clear the		- Until a PLR has a backup path available, the PLR MUST clear the
	relevant four flags in the corresponding RRO IPv4 or IPv6		relevant four flags in the corresponding RRO IPv4 or IPv6
	sub-object.		sub-object.
	skipping to change at page 18, line 4		skipping to change at page 18, line 9
	backup path must inherit its LSP ID from the associated protected		backup path must inherit its LSP ID from the associated protected
	LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE		LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE
	objects which could be varied between a backup path and a protected		objects which could be varied between a backup path and a protected
	LSP is the "IPv4 (or IPv6) tunnel sender address" in the		LSP is the "IPv4 (or IPv6) tunnel sender address" in the
	SENDER_TEMPLATE.		SENDER_TEMPLATE.
	There are two different methods to uniquely identify a backup		There are two different methods to uniquely identify a backup
	path. These are described below.		path. These are described below.
	6.1.1. Backup Path Identification: Sender-Template-Specific		6.1.1. Backup Path Identification: Sender-Template-Specific
	In this approach, the SESSION object and the LSP_ID are copied from		In this approach, the SESSION object and the LSP_ID are copied from
	the protected LSP. The "IPv4 tunnel sender address" is set to an		the protected LSP. The "IPv4 tunnel sender address" is set to an
	address of the PLR. If the head-end of a tunnel is also acting as		address of the PLR. If the head-end of a tunnel is also acting as
	the PLR, it must choose an IP address different from the one used		the PLR, it MUST choose an IP address different from the one used
	in the SENDER_TEMPLATE of the original LSP tunnel.		in the SENDER_TEMPLATE of the original LSP tunnel.
	When using the sender-template-specific approach, the protected		When using the sender-template-specific approach, the protected
	LSPs and the backup paths SHOULD use the Shared Explicit (SE)		LSPs and the backup paths SHOULD use the Shared Explicit (SE)
	style. This allows bandwidth sharing between multiple backup		style. This allows bandwidth sharing between multiple backup
	paths. The backup paths and the protected LSP MAY be merged by the		paths. The backup paths and the protected LSP MAY be merged by the
	Detour Merge Points, when the ERO from the MP to the egress is the		Detour Merge Points, when the ERO from the MP to the egress is the
	same on each LSP to be merged, as specified in [RSVP-TE].		same on each LSP to be merged, as specified in [RSVP-TE].
	6.1.2. Backup Path Identification: Path-Specific		6.1.2. Backup Path Identification: Path-Specific
	skipping to change at page 18, line 34		skipping to change at page 18, line 40
	Thus, the backup paths use the same SESSION and SENDER_TEMPLATE		Thus, the backup paths use the same SESSION and SENDER_TEMPLATE
	objects as the ones used in the protected LSP. The presence of		objects as the ones used in the protected LSP. The presence of
	DETOUR object in Path messages signifies a backup path; the		DETOUR object in Path messages signifies a backup path; the
	presence of FAST_REROUTE object and/or the "local protection		presence of FAST_REROUTE object and/or the "local protection
	requested" flag in the SESSION_ATTRIBUTE object indicates a		requested" flag in the SESSION_ATTRIBUTE object indicates a
	protected LSP.		protected LSP.
	In the path-message-specific approach, when an LSR receives		In the path-message-specific approach, when an LSR receives
	multiple Path messages which have the same SESSION and		multiple Path messages which have the same SESSION and
	SENDER_TEMPLATE objects and also have the same next-hop, that LSR		SENDER_TEMPLATE objects and also have the same next-hop, that LSR
	must merge the Path messages. Without this behavior, the multiple		MUST merge the Path messages. Without this behavior, the multiple
	RESV messages received back would not be distinguishable as to		RESV messages received back would not be distinguishable as to
	which backup path each belongs to. This merging behavior does		which backup path each belongs to. This merging behavior does
	reduce the total number of RSVP states inside the network at the		reduce the total number of RSVP states inside the network at the
	expense of merging LSPs with different EROs.		expense of merging LSPs with different EROs.
	6.2 Procedures for Backup Path Computation		6.2 Procedures for Backup Path Computation
	Before a PLR can create a detour or a bypass tunnel, the desired		Before a PLR can create a detour or a bypass tunnel, the desired
	explicit route must be determined. This can be done using a CSPF.		explicit route must be determined. This can be done using a CSPF.
	skipping to change at page 20, line 15		skipping to change at page 20, line 20
	would be used twice in the event of a failure.		would be used twice in the event of a failure.
	- The backup LSP cannot traverse the downstream node and/or link		- The backup LSP cannot traverse the downstream node and/or link
	whose failure is being protected against. Note that if the		whose failure is being protected against. Note that if the
	PLR is the penultimate hop, node protection is not possible		PLR is the penultimate hop, node protection is not possible
	and only the downstream link can be avoided. The backup path		and only the downstream link can be avoided. The backup path
	may be computed to be SRLG disjoint from the downstream node		may be computed to be SRLG disjoint from the downstream node
	and/or link being avoided.		and/or link being avoided.
	- The backup path must satisfy the resource requirements of the		- The backup path must satisfy the resource requirements of the
	protected LSP. This SHOULD consider the link attribute		protected LSP. This includes the link attribute filters,
	filters, bandwidth, and hop limits determined from the		bandwidth, and hop limits determined from the FAST_REROUTE
	FAST_REROUTE object and SESSION_ATTRIBUTE object.		object and SESSION_ATTRIBUTE object.
	If such computation succeeds, the PLR should attempt to establish a		If such computation succeeds, the PLR should attempt to establish a
	backup path. The PLR may schedule a re-computation at a later time		backup path. The PLR may schedule a re-computation at a later time
	to discover better paths that may have emerged. If for any reason,		to discover better paths that may have emerged. If for any reason,
	the PLR is unable to bring up a backup path, it must schedule a		the PLR is unable to bring up a backup path, it must schedule a
	retry at a later time.		retry at a later time.
	6.3 Signaling Backups for One-To-One Protection		6.3 Signaling Backups for One-To-One Protection
	Once a PLR has decided to locally protect an LSP with one-to-one		Once a PLR has decided to locally protect an LSP with one-to-one
	skipping to change at page 20, line 49		skipping to change at page 21, line 7
	DETOUR object MAY be added to the PATH message.		DETOUR object MAY be added to the PATH message.
	- If the path-specific method is to be used, then the PLR MUST add		- If the path-specific method is to be used, then the PLR MUST add
	a DETOUR object to the PATH message.		a DETOUR object to the PATH message.
	- The SESSION_ATTRIBUTE flags "Local protection desired",		- The SESSION_ATTRIBUTE flags "Local protection desired",
	"Bandwidth protection desired" and "Node protection desired" MUST		"Bandwidth protection desired" and "Node protection desired" MUST
	be cleared. The "Label recording desired" flag MAY be modified.		be cleared. The "Label recording desired" flag MAY be modified.
	If the Path Message contained a FAST_REROUTE object, and the ERO		If the Path Message contained a FAST_REROUTE object, and the ERO
	is not completely strict, the Include-any, Exclude-any, and		is not completely strict, the Include-any, Exclude-any, and
	Include-all fields of the FAST_REROUTE object should be copied to		Include-all fields of the FAST_REROUTE object SHOULD be copied to
	the corresponding fields of the SESSION_ATTRIBUTE object.		the corresponding fields of the SESSION_ATTRIBUTE object.
	- If the protected LSP's Path message contained a FAST_REROUTE		- If the protected LSP's Path message contained a FAST_REROUTE
	object, this MUST be removed from the detour LSP's PATH message.		object, this MUST be removed from the detour LSP's PATH message.
	- The PLR must generate an EXPLICIT_ROUTE object toward the egress.		- The PLR MUST generate an EXPLICIT_ROUTE object toward the egress.
	First, the PLR must remove all sub-objects preceding the first		First, the PLR must remove all sub-objects preceding the first
	address belonging to the Merge Point. Then the PLR should add		address belonging to the Merge Point. Then the PLR SHOULD add
	sub-objects corresponding to the desired backup path between the		sub-objects corresponding to the desired backup path between the
	PLR and the MP.		PLR and the MP.
	- The SENDER_TSPEC object should contain the bandwidth information		- The SENDER_TSPEC object SHOULD contain the bandwidth information
	from the received FAST_REROUTE object, if included in the		from the received FAST_REROUTE object, if included in the
	protected LSP's PATH message.		protected LSP's PATH message.
	- The RSVP_HOP object containing one of the PLR's IP address.		- The RSVP_HOP object containing one of the PLR's IP address.
	- The detour LSPs MUST use the same reservation style as the		- The detour LSPs MUST use the same reservation style as the
	protected LSP. This must be correctly reflected in the		protected LSP. This must be correctly reflected in the
	SESSION_ATTRIBUTE object.		SESSION_ATTRIBUTE object.
	Detour LSPs are regular LSPs in operation. Once a detour path is		Detour LSPs are regular LSPs in operation. Once a detour path is
	skipping to change at page 23, line 38		skipping to change at page 23, line 45
	When MPs use per-interface-label spaces, the PLR must send Path		When MPs use per-interface-label spaces, the PLR must send Path
	messages (for each protected LSP using a bypass tunnel) via that		messages (for each protected LSP using a bypass tunnel) via that
	bypass tunnel prior to the failure in order to discover the		bypass tunnel prior to the failure in order to discover the
	appropriate MP label. The signaling procedures for this are in		appropriate MP label. The signaling procedures for this are in
	Section 6.4.3 below.		Section 6.4.3 below.
	6.4.2. Procedures for the PLR before Local Repair		6.4.2. Procedures for the PLR before Local Repair
	A PLR which determines to use facility-backup to protect a given		A PLR which determines to use facility-backup to protect a given
	LSP SHOULD select a bypass tunnel to use taking into account		LSP should select a bypass tunnel to use taking into account
	whether node protection is to be provided, what bandwidth was		whether node protection is to be provided, what bandwidth was
	requested and whether a bandwidth guarantee is desired, and what		requested and whether a bandwidth guarantee is desired, and what
	link attribute filters were specified in the FAST_REROUTE object.		link attribute filters were specified in the FAST_REROUTE object.
	The selection of a bypass tunnel for a protected LSP is performed		The selection of a bypass tunnel for a protected LSP is performed
	by the PLR when the LSP is first setup.		by the PLR when the LSP is first setup.
	6.4.3. Procedures for the PLR during Local Repair		6.4.3. Procedures for the PLR during Local Repair
	When the PLR detects a link or/and node failure condition, it needs		When the PLR detects a link or/and node failure condition, it needs
	to reroute the data traffic onto the bypass tunnel and to start		to reroute the data traffic onto the bypass tunnel and to start
	sending the control traffic for the protected LSP onto the bypass		sending the control traffic for the protected LSP onto the bypass
	tunnel.		tunnel.
	skipping to change at page 24, line 20		skipping to change at page 24, line 29
	- The SESSION is unchanged.		- The SESSION is unchanged.
	- The SESSION_ATTRIBUTE is unchanged except as follows:		- The SESSION_ATTRIBUTE is unchanged except as follows:
	The "Local protection desired", "Bandwidth protection desired",		The "Local protection desired", "Bandwidth protection desired",
	and "Node protection desired" flags SHOULD be cleared.		and "Node protection desired" flags SHOULD be cleared.
	The "Label recording desired" MAY be modified.		The "Label recording desired" MAY be modified.
	- The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE		- The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE
	is set to an address belonging to the PLR.		is set to an address belonging to the PLR.
	- The RSVP_HOP object must contain an IP source address		- The RSVP_HOP object MUST contain an IP source address
	belonging to the PLR. Consequently, the MP will send messages		belonging to the PLR. Consequently, the MP will send messages
	back to the PLR using as a destination that IP address.		back to the PLR using as a destination that IP address.
	- The PLR must generate an EXPLICIT_ROUTE object toward the		- The PLR MUST generate an EXPLICIT_ROUTE object toward the
	egress. Detailed ERO processing is described below.		egress. Detailed ERO processing is described below.
	- The RRO object may need to be updated, as described in Section		- The RRO object may need to be updated, as described in Section
	6.5.		6.5.
	The PLR sends Path, PathTear, and ResvConf messages via the backup		The PLR sends Path, PathTear, and ResvConf messages via the backup
	tunnel. The MP sends Resv, ResvTear, and PathErr messages by		tunnel. The MP sends Resv, ResvTear, and PathErr messages by
	directly addressing them to the address in the RSVP_HOP object		directly addressing them to the address in the RSVP_HOP object
	contents as specified in [RSVP].		contents as specified in [RSVP].
	If it is necessary to signal the backup prior to failure to		If it is necessary to signal the backup prior to failure to
	determine the MP label to use, then the same Path message is sent.		determine the MP label to use, then the same Path message is sent.
	In this case, the PLR should continue to send Path messages for the		In this case, the PLR SHOULD continue to send Path messages for the
	protected LSP along the normal route. PathTear messages should be		protected LSP along the normal route. PathTear messages should be
	duplicated, with one sent along the normal route and one sent thru		duplicated, with one sent along the normal route and one sent thru
	the bypass tunnel. The MP should duplicate the Resv and ResvTear		the bypass tunnel. The MP should duplicate the Resv and ResvTear
	messages and sent them to both the PLR and the LSR indicated by the		messages and sent them to both the PLR and the LSR indicated by the
	protected LSP's RSVP_HOP object.		protected LSP's RSVP_HOP object.
	6.4.4. Processing backup tunnel's ERO		6.4.4. Processing backup tunnel's ERO
	Procedures for ERO processing are described in [RSVP-TE]. This		Procedures for ERO processing are described in [RSVP-TE]. This
	section describes additional ERO update procedures for Path messages		section describes additional ERO update procedures for Path messages
	skipping to change at page 25, line 14		skipping to change at page 25, line 22
	unmodified ERO might contain the IP address of a bypassed node (in		unmodified ERO might contain the IP address of a bypassed node (in
	the case of a NNHOP Backup Tunnel), or of an interface which is		the case of a NNHOP Backup Tunnel), or of an interface which is
	currently down (in the case of a NHOP Backup Tunnel). For this		currently down (in the case of a NHOP Backup Tunnel). For this
	reason, the PLR invoke the following ERO procedures before sending a		reason, the PLR invoke the following ERO procedures before sending a
	Path message via a bypass tunnel.		Path message via a bypass tunnel.
	Sub-objects belonging to abstract nodes which precede the Merge Point		Sub-objects belonging to abstract nodes which precede the Merge Point
	are removed, along with the first sub-object belonging to the MP. A		are removed, along with the first sub-object belonging to the MP. A
	sub-object identifying the Backup Tunnel destination is then added.		sub-object identifying the Backup Tunnel destination is then added.
	More specifically, the PLR must:		More specifically, the PLR MUST:
	- remove all the sub-objects proceeding the first address belonging		- remove all the sub-objects proceeding the first address belonging
	to the MP.		to the MP.
	- replace this first MP address with an IP address of the MP.		- replace this first MP address with an IP address of the MP.
	(Note that this could be same address that was just removed.)		(Note that this could be same address that was just removed.)
	6.5. PLR Procedures During Local Repair		6.5. PLR Procedures During Local Repair
	In addition to the technique specific signaling and packet		In addition to the technique specific signaling and packet
	treatment, there is common signaling which should be followed.		treatment, there is common signaling which should be followed.
	During fast reroute, for each protected LSP containing an RRO		During fast reroute, for each protected LSP containing an RRO
	object, the PLR obtains the RRO from the protected LSP's stored		object, the PLR obtains the RRO from the protected LSP's stored
	RESV and updates it by inserting an IPv4 sub-object with the IPv4		RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted
	address of the outbound interface address the traffic is forwarded		into the RRO by setting the "Local protection in use" and "Local
	onto.		Protection Available" flags.
	The PLR MUST update the IPv4 or IPv6 sub-object it
	inserted into the RRO by setting the "Local protection in use" and
	"Local Protection Available" flags.
	6.5.1. Notification of local repair		6.5.1. Notification of local repair
	In many situations, the route used during a Local Repair will be less		In many situations, the route used during a Local Repair will be less
	than optimal. The purpose of Local Repair is to keep high priority		than optimal. The purpose of Local Repair is to keep high priority
	and loss sensitive traffic flowing while a more optimal re-routing of		and loss sensitive traffic flowing while a more optimal re-routing of
	the tunnel can be effected by the head-end of the tunnel. Thus the		the tunnel can be effected by the head-end of the tunnel. Thus the
	head-end needs to know of the failure so it may re-signal an LSP		head-end needs to know of the failure so it may re-signal an LSP
	which is optimal.		which is optimal.
	skipping to change at page 28, line 27		skipping to change at page 28, line 30
	7.1.1. Merginging Backup Paths using the Sender-Template Specific Method		7.1.1. Merginging Backup Paths using the Sender-Template Specific Method
	An LSR may receive multiple Path messages for one or more backup		An LSR may receive multiple Path messages for one or more backup
	LSPs and, possibly, the protected LSP. Each of these Path messages		LSPs and, possibly, the protected LSP. Each of these Path messages
	will have a different SENDER_TEMPLATE. The protected LSP can be		will have a different SENDER_TEMPLATE. The protected LSP can be
	recognized because it will either include the FAST_REROUTE object,		recognized because it will either include the FAST_REROUTE object,
	have the "local protection desired" flag set in the		have the "local protection desired" flag set in the
	SESSION_ATTRIBUTE object or both.		SESSION_ATTRIBUTE object or both.
	If the outgoing interface and next-hop LSR are the same, then the		If the outgoing interface and next-hop LSR are the same, then the
	Path messages are eligible for merging. As specified in [RSVP],		Path messages are eligible for merging. Similar to that specified
	only those Path messages whose ERO from that LSR to the egress is		in [RSVP-TE] for merging of RESV messages, only those Path messages
	the same can be merged. If merging occurs and one of the Path		whose ERO from that LSR to the egress is the same can be merged.
	messages merged was for the protected LSP, then the final Path		If merging occurs and one of the Path messages merged was for the
	message to be sent MUST be that of the protected LSP. This merges		protected LSP, then the final Path message to be sent MUST be that
	the backup LSPs into the protected LSP at that LSR. Once the final		of the protected LSP. This merges the backup LSPs into the
	Path message has been identified, the MP MUST start to refresh it		protected LSP at that LSR. Once the final Path message has been
	downstream periodically.		identified, the MP MUST start to refresh it downstream
			periodically.
	If merging occurs and all the Path messages were for backup LSPs,		If merging occurs and all the Path messages were for backup LSPs,
	then the DETOUR object, if any, should be altered as specified in		then the DETOUR object, if any, should be altered as specified in
	Section 8.1		Section 8.1
	7.1.2. Merging Detours using the Path-Specific Method		7.1.2. Merging Detours using the Path-Specific Method
	An LSR (that is, an MP) may receive multiple Path messages from		An LSR (that is, an MP) may receive multiple Path messages from
	different interfaces with identical SESSION and SENDER_TEMPLATE		different interfaces with identical SESSION and SENDER_TEMPLATE
	objects. In this case, Path state merging is REQUIRED.		objects. In this case, Path state merging is REQUIRED.
	The merging rule is the following:		The merging rule is the following:
	For all Path messages that do not have either a FAST_REROUTE or a		For all Path messages that do not have either a FAST_REROUTE or a
	DETOUR object, or the MP is the egress of the LSP, no merging is		DETOUR object, or the MP is the egress of the LSP, no merging is
	required. The messages are processed according to [RSVP-TE].		required. The messages are processed according to [RSVP-TE].
	Otherwise, the MP MUST record the Path state as well as their		Otherwise, the MP MUST record the Path state as well as their
	incoming interface. If the Path messages do not share outgoing		incoming interface. If the Path messages do not share outgoing
	interface and next-hop LSR, the MP must consider them as independent		interface and next-hop LSR, the MP MUST consider them as independent
	LSPs, and must not merge them.		LSPs, and MUST NOT merge them.
	For all the Path messages that share the same outgoing interface and		For all the Path messages that share the same outgoing interface and
	next-hop LSR, the MP runs the following procedure to select one of		next-hop LSR, the MP runs the following procedure to select one of
	them as the Path message to forward downstream.		them as the Path message to forward downstream.
	1. Eliminate from consideration those that traverse nodes that		1. Eliminate from consideration those that traverse nodes that
	other Path messages want to avoid.		other Path messages want to avoid.
	2. If one LSP is originated from this node, this must be		2. If one LSP is originated from this node, this must be
	the final LSP. Quit.		the final LSP. Quit.
	skipping to change at page 30, line 31		skipping to change at page 30, line 38
	7.1.3. Message Handling for Merged Detours		7.1.3. Message Handling for Merged Detours
	When an LSR receives a ResvTear for an LSP, the LSR must determine		When an LSR receives a ResvTear for an LSP, the LSR must determine
	whether it has an alternate associated LSP. For instance, if the		whether it has an alternate associated LSP. For instance, if the
	ResvTear was received for a protected LSP, but an associated backup		ResvTear was received for a protected LSP, but an associated backup
	LSP has not received a ResvTear, then the LSR has an alternate		LSP has not received a ResvTear, then the LSR has an alternate
	associated LSP. If the LSR does not have an alternate associated		associated LSP. If the LSR does not have an alternate associated
	LSP, then the MP MUST propogate the ResvTear toward the LSP's		LSP, then the MP MUST propogate the ResvTear toward the LSP's
	ingress and, for each backup LSP merged into that LSP at this LSR,		ingress and, for each backup LSP merged into that LSP at this LSR,
	the ResvTear should also be propogated along the backup LSP.		the ResvTear SHOULD also be propogated along the backup LSP.
	The MP may receive PathTear messages for some of the merging LSPs.		The MP may receive PathTear messages for some of the merging LSPs.
	No PathTear message should be propagated downstream until the MP		PathTear messages SHOULD NOT be propagated downstream until the MP
	has received PathTear messages for each of the merged LSPs.		has received PathTear messages for each of the merged LSPs.
	However, the fact that one or more of the merged LSPs has been torn		However, the fact that one or more of the merged LSPs has been torn
	down should be reflected in the downstream message, such as by		down should be reflected in the downstream message, such as by
	changing the DETOUR object, if any.		changing the DETOUR object, if any.
	7.2. Handling Failures		7.2. Handling Failures
	When a downstream LSR detects a local link failure, for any		When a downstream LSR detects a local link failure, for any
	protected LSPs routed over the failed link, Path and Resv state		protected LSPs routed over the failed link, Path and Resv state
	MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be		MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be
	skipping to change at page 33, line 22		skipping to change at page 33, line 28
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	13. Acknowledgments		13. Acknowledgments
	We would like to acknowledge input and helpful comments from Rob		We would like to acknowledge input and helpful comments from Rob
	Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially,		Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially,
	we thank those, who have been involved in interoperability testing		we thank those, who have been involved in interoperability testing
	and field trails, and provided invaluable ideas and suggestions.		and field trails, and provided invaluable ideas and suggestions.
	They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan,		They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan,
	and Richard Southern.		Richard Southern, and Bijan Jabbari.
	14. References		14. Normative References
	[RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)		[RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
	-- version 1 functional specification," RFC2205, September 1997.		-- version 1 functional specification," RFC2205, September 1997.
	[RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP		[RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
	tunnels", RFC3029, December 2001.		tunnels", RFC3029, December 2001.
	[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate		[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF,
	draft-katz-yeung-ospf-traffic-05.txt, June 2001.
	[ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
	ietf-isis-tr affic-03.txt, June 2001.
	[RSVP-REFRESH] L. Berger, et al, "RSVP Refresh Overhead Reduction
	Extensions", RFC2961.
	[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an		[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 2434.		IANA Considerations Section in RFCs", RFC 2434.
	15. Author Information		15. Author Information
	Ping Pan		Ping Pan
	CIENA Corp.		CIENA Corp.
	10480 Ridgeview Court		10480 Ridgeview Court
	Cupertino, CA 95014		Cupertino, CA 95014
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/