draft-ietf-teas-gmpls-lsp-fastreroute-05.txt		draft-ietf-teas-gmpls-lsp-fastreroute-06.txt
	TEAS Working Group M. Taillon		TEAS Working Group M. Taillon
	Internet-Draft T. Saad, Ed.		Internet-Draft T. Saad, Ed.
	Intended Status: Standards Track R. Gandhi, Ed.		Intended Status: Standards Track R. Gandhi, Ed.
	Expires: December 5, 2016 Z. Ali		Expires: April 4, 2017 Z. Ali
	Cisco Systems		Cisco Systems
	June 3, 2016		October 1, 2016
	Extensions to Resource Reservation Protocol For Fast Reroute of		Extensions to Resource Reservation Protocol For Fast Reroute of
	Traffic Engineering GMPLS LSPs		Traffic Engineering GMPLS LSPs
	draft-ietf-teas-gmpls-lsp-fastreroute-05		draft-ietf-teas-gmpls-lsp-fastreroute-06
	Abstract		Abstract
	This document defines Resource Reservation Protocol - Traffic		This document defines Resource Reservation Protocol - Traffic
	Engineering (RSVP-TE) signaling extensions to support Fast Reroute		Engineering (RSVP-TE) signaling extensions to support Fast Reroute
	(FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol		(FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol
	Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling		Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling
	extensions allow the coordination of a bidirectional bypass tunnel		extensions allow the coordination of a bidirectional bypass tunnel
	assignment protecting a common facility in both forward and reverse		assignment protecting a common facility in both forward and reverse
	directions of a co-routed bidirectional LSP. In addition, these		directions of a co-routed bidirectional LSP. In addition, these
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 14 ¶
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions Used in This Document . . . . . . . . . . . . . . 4		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4		2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4
	2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
			2.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 5
	3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 5		3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 5
	4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . 5		4. Fast Reroute for Bidirectional GMPLS LSPs . . . . . . . . . . 5
	4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 5		4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 5
	4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 5		4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 6
	4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 6		4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 6
	4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6		4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6
	4.5. Bidirectional Bypass Tunnel Assignment Co-ordination . . . 6		4.5. Bidirectional Bypass Tunnel Assignment Co-ordination . . . 7
	4.5.1. Bidirectional Bypass Tunnel Assignment Signaling		4.5.1. Bidirectional Bypass Tunnel Assignment Signaling
	Procedure . . . . . . . . . . . . . . . . . . . . . . 7		Procedure . . . . . . . . . . . . . . . . . . . . . . 7
	4.5.2. Bidirectional Bypass Tunnel Assignment Policy . . . . 8		4.5.2. Multiple Bidirectional Bypass Tunnel Assignments . . . 8
	4.5.3. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . 9		4.6. Fast Reroute Procedure After Link Failure . . . . . . . . 9
	5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 10		5. Link Protection for Bidirectional GMPLS LSPs . . . . . . . . . 10
	5.1. Behavior After Link Failure After FRR . . . . . . . . . . 10		5.1. Behavior After Link Failure . . . . . . . . . . . . . . . 10
	5.2. Revertive Behavior After Link Failure After FRR . . . . . 11		5.2. Revertive Behavior After Fast Reroute . . . . . . . . . . 11
	6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 11		6. Node Protection for Bidirectional GMPLS LSPs . . . . . . . . . 11
	6.1. Behavior After FRR and Link Failure . . . . . . . . . . . 11		6.1. Behavior After Link Failure . . . . . . . . . . . . . . . 12
	6.2. Behavior After Link Failure To Re-coroute . . . . . . . . 12		6.2. Behavior After Link Failure To Re-coroute . . . . . . . . 12
	6.3. Revertive Behavior After Link Failure . . . . . . . . . . 13		6.3. Revertive Behavior After Fast Reroute . . . . . . . . . . 13
	7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13		7. Unidirectional Link Failures . . . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 14		8. Message and Object Definitions . . . . . . . . . . . . . . . . 14
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		8.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . 15		9. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . 15		10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		11.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		11.2. FRR Bypass Assignment Error Notify Message . . . . . . . 17
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
			12.1. Normative References . . . . . . . . . . . . . . . . . . 18
			12.2. Informative References . . . . . . . . . . . . . . . . . 18
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19
			Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels are
	signaled using Generalized Multi-Protocol Label Switching (GMPLS)		Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels can be
			setup using Generalized Multi-Protocol Label Switching (GMPLS)
	signaling procedures specified in [RFC3473] for both unidirectional		signaling procedures specified in [RFC3473] for both unidirectional
	and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely		and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely
	deployed in the packet TE networks today and is desirable for TE		deployed in the packet TE networks today and is desirable for TE
	GMPLS LSPs. Using FRR methods also allows the leveraging of existing		GMPLS LSPs. Using FRR methods also allows the leveraging of the
	mechanisms for failure detection and restoration in deployed		existing mechanisms for failure detection and restoration in deployed
	networks.		networks.
	The FRR procedures defined in [RFC4090] describe the behavior of the		The FRR procedures defined in [RFC4090] describe the behavior of the
	Point of Local Repair (PLR) to reroute traffic and signaling onto the		Point of Local Repair (PLR) to reroute traffic and signaling onto the
	bypass tunnel in the event of a failure for unidirectional LSPs.		bypass tunnel in the event of a failure for protected LSPs. Those
	These procedures are applicable to unidirectional protected LSPs		procedures are applicable to the unidirectional protected LSPs
	signaled using either RSVP-TE [RFC3209] or GMPLS procedures		signaled using either RSVP-TE [RFC3209] or GMPLS procedures
	[RFC3473], but they do not address issues that arise when employing		[RFC3473]. When using the FRR procedures defined in [RFC4090] with
	FRR for bidirectional co-routed GMPLS Label Switched Paths (LSPs).		co-routed bidirectional GMPLS LSPs, it is desired that same PLR and
			Merge Point (MP) pairs are selected in each direction and both PLR
	When bidirectional bypass tunnels are used to locally protect		and MP assign the same bidirectional bypass tunnel. This document
	bidirectional co-routed GMPLS LSPs, the upstream and downstream PLRs		extends the FRR procedures defined in [RFC4090] to coordinate the
	may independently assign different bidirectional bypass tunnels in		bidirectional bypass tunnel assignment and to exchange MP labels
	the forward and reverse directions. There is no mechanism in the FRR		between upstream and downstream PLRs of the protected co-routed
	procedures defined in [RFC4090] to coordinate the bidirectional		bidirectional LSP.
	bypass tunnel selection between the downstream and upstream PLRs.
	When using FRR procedures with bidirectional co-routed GMPLS LSPs, it		When using FRR procedures with co-routed bidirectional GMPLS LSPs, it
	is possible in some cases for the RSVP signaling refreshes to stop		is possible in some cases for the RSVP signaling refreshes to stop
	reaching some nodes along the primary LSP path after the PLRs finish		reaching certain nodes along the protected LSP path after the PLRs
	rerouting signaling onto the bypass tunnels. This may occur when		finish rerouting signaling onto the bypass tunnels. This can occur
	using node protection bypass tunnels after a link failure event and		after a failure event when using node protection bypass tunnels and
	when RSVP signaling is sent in-fiber and in-band with data. This is		when RSVP signaling is sent in-band with data. As shown in Figure 2,
			this is possible even with selecting the same bidirectional bypass
			tunnels in both directions and the same PLR and MP pairs. This is
	caused by the asymmetry of paths that may be taken by the		caused by the asymmetry of paths that may be taken by the
	bidirectional LSP's signaling in the forward and reverse directions		bidirectional LSP's signaling in the forward and reverse directions
	after FRR reroute. In such cases, the RSVP soft-state timeout		due to upstream and downstream PLRs independently triggering FRR. In
	causes the protected bidirectional LSP to be destroyed, with		such cases, after FRR, the RSVP soft-state timeout causes the
	subsequent traffic loss after FRR.		protected bidirectional LSP to be torn down, with subsequent traffic
			loss.
	Protection State Coordination Protocol [RFC6378] is applicable to FRR		Protection State Coordination Protocol [RFC6378] is applicable to FRR
	[RFC4090] for local protection of bidirectional co-routed LSPs in		[RFC4090] for local protection of co-routed bidirectional LSPs in
	order to minimize traffic disruptions in both directions. However,		order to minimize traffic disruptions in both directions. However,
	this does not address the above mentioned problem of RSVP soft-state		this does not address the above mentioned problem of RSVP soft-state
	timeout in control plane.		timeout in control plane.
	This document proposes solutions to the above mentioned problems by		This document proposes a solution to the RSVP soft-state timeout
	providing mechanisms in the control plane to complement the FRR		issue by providing mechanisms in the control plane to complement the
	procedures of [RFC4090] in order to maintain the RSVP soft-state for		FRR procedures of [RFC4090]. The proposal allows to maintain the
	bidirectional co-routed protected GMPLS LSPs and achieve symmetry in		RSVP soft-state for co-routed bidirectional protected GMPLS LSPs and
	the paths followed by the traffic and signaling in the forward and		achieve co-routedness of the paths followed by the traffic and
	reverse directions after FRR. The document further extends RSVP		signaling in the forward and reverse directions after FRR.
	signaling so that the bidirectional bypass tunnel selected by the
	upstream PLR matches the one selected by the downstream PLR node for
	a bidirectional co-routed LSP.
	Procedures defined in this document apply to co-routed GMPLS signaled		Procedures defined in this document apply to GMPLS signaled PSC TE
	PSC bidirectional TE primary and FRR bypass LSPs. Unless otherwise		co-routed bidirectional protected LSPs and FRR co-routed
	specified in this document, the FRR procedures defined in [RFC4090]		bidirectional bypass tunnels. Unless otherwise specified in this
	are not modified by this document.		document, the FRR procedures defined in [RFC4090] are not modified by
			this document. FRR mechanism for associated bidirectional GMPLS LSPs
			where two unidirectional GMPLS LSPs are bound together by using
			association signaling [RFC7551] is outside the scope of this
			document.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	2.1. Key Word Definitions		2.1. Key Word Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2.2. Terminology		2.2. Terminology
	The reader is assumed to be familiar with the terminology in		The reader is assumed to be familiar with the terminology in
	[RFC2205] and [RFC3209].		[RFC2205], [RFC3209], [RFC3471], [RFC3473] and [RFC4090].
	LSR: An MPLS Label-Switch Router.		Downstream PLR: Downstream Point of Local Repair. The PLR that
			locally detects a failure in the downstream direction of the traffic
			flow and reroutes traffic in the same direction of the protected
			bidirectional LSP RSVP Path signaling. A downstream PLR has a
			corresponding downstream MP.
	LSP: An MPLS Label-Switched Path.		Downstream MP: Downstream Merge Point. The LSR where one or more
			backup tunnels rejoin the path of the protected LSP in the downstream
			direction of the traffic flow. The same LSR may be both a downstream
			MP and an upstream PLR simultaneously.
	Local Repair: Techniques used to repair LSP tunnels quickly when a		Upstream PLR: Upstream Point of Local Repair. The PLR that locally
	node or link along the LSP's path fails.		detects a failure in the upstream direction of the traffic flow and
			reroutes traffic in the opposite direction of the protected
			bidirectional LSP RSVP Path signaling. An upstream PLR has a
			corresponding upstream MP.
	PLR: Point of Local Repair. The head-end LSR of a bypass tunnel or a		Upstream MP: Upstream Merge Point. The LSR where one or more backup
	detour LSP.		tunnels rejoin the path of the protected LSP in the upstream
			direction of the traffic flow. The same LSR may be both an upstream
			MP and a downstream PLR simultaneously.
	PSC: Packet Switched Capable.		Point of Remote Repair (PRR): A downstream MP that assumes the role
			of upstream PLR upon receiving protected LSP's Path message over the
			bypass tunnel and triggers reroute of traffic and signaling in the
			upstream direction of the traffic flow using the procedures described
			in this document.
	Protected LSP: An LSP is said to be protected at a given hop if it		2.3. Acronyms and Abbreviations
	has one or multiple associated bypass tunnels originating at that
	hop.
	Bypass Tunnel: An LSP that is used to protect a set of LSPs passing		GMPLS: Generalized Multi-Protocol Label Switching
	over a common facility.
	NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A bypass tunnel that		LSP: An MPLS Label Switched Path
	bypasses a single link of the protected LSP.
	NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A bypass tunnel		LSR: An MPLS Label Switching Router
	that bypasses a single node of the protected LSP.
	MP: Merge Point. The LSR where one or more bypass tunnels rejoin the		MP: Merge Point
	path of the protected LSP downstream of the potential failure. The
	same LSR may be both an MP and a PLR simultaneously.
	Downstream PLR: A PLR that locally detects a fault and reroutes		MPLS: Multi-Protocol Label Switching
	traffic in the same direction of the protected bidirectional LSP RSVP
	Path signaling. A downstream PLR has a corresponding downstream MP.
	Upstream PLR: A PLR that locally detects a fault and reroutes traffic		PLR: Point of Local Repair
	in the opposite direction of the protected bidirectional LSP RSVP
	Path signaling. An upstream PLR has a corresponding upstream MP.
	Point of Remote Repair (PRR): An upstream PLR that triggers reroute		PSC: Packet Switched Capable
	of traffic and signaling based on procedures described in this
	document.		RSVP: Resource ReSerVation Protocol
			TE: Traffic Engineering
	3. Fast Reroute For Unidirectional GMPLS LSPs		3. Fast Reroute For Unidirectional GMPLS LSPs
	The FRR procedures defined in [RFC4090] are applicable to		The FRR procedures defined in [RFC4090] are applicable to
	unidirectional protected LSPs signaled using either RSVP-TE or GMPLS		unidirectional protected LSPs signaled using either RSVP-TE or GMPLS
	procedures and are not modified by the extensions defined in this		procedures and are not modified by the extensions defined in this
	document. These FRR procedures also apply to bidirectional		document.
	associated GMPLS LSPs where two unidirectional GMPLS LSPs are bound
	together by using association signaling [RFC7551].
	4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs		4. Fast Reroute for Bidirectional GMPLS LSPs
	This section describes signaling procedures for bidirectional bypass		This section describes signaling procedures for FRR bidirectional
	tunnel assignment for GMPLS signaled PSC bidirectional co-routed TE		bypass tunnel assignment for GMPLS signaled PSC co-routed
	LSPs.		bidirectional TE LSPs.
	4.1. Bidirectional GMPLS Bypass Tunnel Direction		4.1. Bidirectional GMPLS Bypass Tunnel Direction
	This document defines procedures where GMPLS bypass tunnels are		This document defines procedures where bidirectional GMPLS bypass
	provisioned in the same direction as the GMPLS primary LSPs. In		tunnels are signaled in the same direction as the protected GMPLS
	other words, the GMPLS bypass tunnels originate on the downstream PLR		LSPs. In other words, the bidirectional GMPLS bypass tunnels
	and terminate on the downstream MP. As the originating downstream		originate on the downstream PLR and terminate on the downstream MP.
	PLR node has the policy information about the locally provisioned		As the originating downstream PLR has the policy information about
	bypass tunnels, it always initiates the bypass tunnel assignment.		the locally provisioned bypass tunnels, it always initiates the
	The GMPLS bypass tunnels originating from the upstream PLR and		bypass tunnel assignment. The bidirectional GMPLS bypass tunnels
	terminating on the upstream MP are outside the scope of this		originating from the upstream PLR and terminating on the upstream MP
	document.		are outside the scope of this document.
	4.2. Merge Point Labels		4.2. Merge Point Labels
	To correctly reroute data traffic over a node protection bypass		To correctly reroute data traffic over a node protection bypass
	tunnel, the downstream and upstream PLRs have to know, in advance,		tunnel, the downstream and upstream PLRs have to know, in advance,
	the downstream and upstream MP labels so that data in the forward and		the downstream and upstream MP labels of the protected LSP so that
	reverse directions can be redirected through the bypass tunnel after		data in the forward and reverse directions can be redirected through
	FRR respectively.		the bypass tunnel after FRR respectively.
	[RFC4090] defines procedures for the downstream PLR to obtain the		[RFC4090] defines procedures for the downstream PLR to obtain the
	protected LSP's downstream MP label from recorded labels in the RRO		protected LSP's downstream MP label from recorded labels in the
	of the RSVP Resv message received at the downstream PLR.		RECORD_ROUTE Object (RRO) of the RSVP Resv message received at the
			downstream PLR.
	To obtain the upstream MP label, the procedures specified in		To obtain the upstream MP label, the procedures specified in
	[RFC4090] are used to record the upstream MP label in the RRO of the		[RFC4090] are used to record the upstream MP label in the RRO of the
	RSVP Path message. The upstream PLR obtains the upstream MP label		RSVP Path message of the protected LSP. The upstream PLR obtains the
	from the recorded labels in the RRO of the received RSVP Path		upstream MP label from the recorded labels in the RRO of the received
	message.		RSVP Path message.
	4.3. Merge Point Addresses		4.3. Merge Point Addresses
	To correctly assign a bidirectional bypass tunnel, the downstream and		To correctly assign a bidirectional bypass tunnel, the downstream and
	upstream PLRs have to know, in advance, the downstream and upstream		upstream PLRs have to know, in advance, the downstream and upstream
	MP addresses.		MP addresses.
	[RFC4561] defines procedures for the downstream PLR to obtain the		[RFC4561] defines procedures for the downstream PLR to obtain the
	protected LSP's downstream MP address from the recorded node-IDs in		protected LSP's downstream MP address from the recorded Node-IDs in
	the RRO of the RSVP Resv message received at the downstream PLR.		the RRO of the RSVP Resv message received at the downstream PLR.
	To obtain the upstream MP address, the procedures specified in		To obtain the upstream MP address, the procedures specified in
	[RFC4561] are used to record upstream MP node-ID in the RRO of the		[RFC4561] are used to record upstream MP Node-ID in the RRO of the
	RSVP Path message. The upstream PLR obtains the upstream MP address		RSVP Path message of the protected LSP. The upstream PLR obtains the
	from the recorded node-IDs in the RRO of the received RSVP Path		upstream MP address from the recorded Node-IDs in the RRO of the
	message.		received RSVP Path message.
	4.4. RRO IPv4/IPv6 Subobject Flags		4.4. RRO IPv4/IPv6 Subobject Flags
	RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4		RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4
	and are equally applicable to the FRR procedure for bidirectional		and are equally applicable to the FRR procedure for bidirectional
	GMPLS LSPs.		GMPLS LSPs.
	The procedures defined in [RFC4090] are used by the downstream PLR to		The procedures defined in [RFC4090] are used by the downstream PLR to
	signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP		signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP
	Resv message. Similarly, these procedures are used by the downstream		Resv message of the protected LSP. Similarly, those procedures are
	PLR to signal the IPv4/IPv6 subobject flags downstream in the RRO of		used by the downstream PLR to signal the IPv4/IPv6 subobject flags
	the RSVP Path message.		downstream in the RRO of the RSVP Path message of the protected LSP.
	4.5. Bidirectional Bypass Tunnel Assignment Co-ordination		4.5. Bidirectional Bypass Tunnel Assignment Co-ordination
	This document defines signaling procedures and a new		This document defines signaling procedures and a new
	BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object used to		BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO)
	co-ordinate the bidirectional bypass tunnel assignment between the		used to co-ordinate the bidirectional bypass tunnel assignment
	downstream and upstream PLRs.		between the downstream and upstream PLRs.
	4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure		4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure
	It is desirable to coordinate the bidirectional bypass tunnel		It is desirable to coordinate the bidirectional bypass tunnel
	selected at the downstream and upstream PLRs so that rerouted traffic		selected at the downstream and upstream PLRs so that rerouted traffic
	and signaling flow on co-routed paths after FRR. To achieve this, a		and signaling flow on co-routed paths after FRR. To achieve this, a
	new RSVP subobject is defined for RECORD_ROUTE Object (RRO) that		new RSVP subobject is defined for RRO that identifies a bidirectional
	identifies a bidirectional bypass tunnel that is assigned at a		bypass tunnel that is assigned at a downstream PLR to protect a
	downstream PLR to protect a bidirectional LSP.		bidirectional LSP.
	The BYPASS_ASSIGNMENT subobject SHOULD be added by each downstream
	PLR in the RSVP Path RECORD_ROUTE message of the GMPLS signaled
	bidirectional primary LSP to record the downstream bidirectional
	bypass tunnel assignment. This subobject is sent in the RSVP Path
	RECORD_ROUTE message every time the downstream PLR assigns or updates
	the bypass tunnel assignment. The upstream PLR (downstream MP)
	simply reflects the bypass tunnel assignment in the reverse
	direction.
	When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE		When the procedures defined in this document are in use, the
	Object:		BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in
			the RSVP Path RRO message of the GMPLS signaled bidirectional
			protected LSP to record the downstream bidirectional bypass tunnel
			assignment. This subobject is sent in the RSVP Path RRO message
			every time the downstream PLR assigns or updates the bypass tunnel
			assignment. The downstream PLR can assign a bypass tunnel when
			processing the first Path message of the protected LSP, however, it
			can not update the forwarding plane until it receives the Resv
			message containing the downstream MP label.
	o The BYPASS_ASSIGNMENT subobject MUST be added prior to the		The upstream PLR (downstream MP) simply reflects the bypass tunnel
	Node-ID subobject containing the node's address.		assignment in the reverse direction. The absence of
			BYPASS_ASSIGNMENT subobject in RRO means that the relevant node or
			interface is not protected by a bidirectional bypass tunnel. Hence,
			the upstream PLR need not assign a bypass tunnel in the reverse
			direction.
	o The Node-ID subobject MUST also be added.		When the BYPASS_ASSIGNMENT subobject is added in the RRO:
	o The IPv4 or IPv6 subobject MUST also be added.		o The IPv4 or IPv6 subobject containing Node-ID address MUST also be
			added [RFC4561]. The Node-ID address must match the source
			address of the bypass tunnel selected for this protected LSP.
	o The Label subobject MUST also be added.		o The BYPASS_ASSIGNMENT subobject MUST be added immediately after
			the Node-ID address.
	In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR		o The Label subobject MUST also be added [RFC3209].
	(downstream MP) SHOULD NOT assign a bypass tunnel in the reverse
	direction. This allows the downstream PLR to always initiate the
	bypass assignment and upstream PLR (downstream MP) to simply reflect
	the bypass assignment.
	The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT		The rules for adding an IPv4 or IPv6 Interface address subobject and
	subobject, selects a reverse bypass tunnel that terminates locally		Unnumbered Interface ID subobject as specified in [RFC3209] and
	with the matching tunnel-ID and has a source address matching the		[RFC4090] are not modified by the above procedure. The options
	node-ID sub-object received in the subobject. The RRO containing		specified in Section 6.1.3 in [RFC4990] are also applicable as long
	BYPASS_ASSIGNMENT subobject(s) is then simply forwarded downstream in		as above mentioned rules are followed when using the FRR procedures
	the RSVP Path message.		defined in this document.
	An upstream PLR (downstream MP) SHOULD examine the entire Path RRO		An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT
	and look at all BYPASS_ASSIGNMENT subobjects in order to assign a		subobjects in the Path RRO in order to assign a reverse bypass
	reverse bypass tunnel. The choice of a reverse bypass tunnel (if		tunnel. The upstream PLR that detects a BYPASS_ASSIGNMENT subobject,
	multiple bypass tunnels exist) is based on the local policy on the		selects a reverse bypass tunnel that terminates locally with the
	downstream MP and is discussed in Section 4.5.2 of this document.		destination address and tunnel-ID from the subobject, and has a
			source address matching the Node-ID address. The RRO may contain
			multiple addresses to identify a node, however, the upstream PLR
			relies on the Node-ID address preceding the BYPASS_ASSIGNMENT
			subobject for identifying the bypass tunnel. If the bypass tunnel is
			not found, the upstream PLR SHOULD send a Notify message [RFC3473]
			with Error-code - FRR Bypass Assignment Error (value: TBA1) and Sub-
			code - Bypass Tunnel Not Found (value: TBA3) to the downstream PLR.
			The RRO containing BYPASS_ASSIGNMENT subobject(s) is then simply
			forwarded downstream in the RSVP Path message.
	The bypass assignment co-ordination procedure described in this		The bypass assignment co-ordination procedure described in this
	Section can be used for both one-to-one backup described in Section		Section can be used for both facility backup described in Section 3.2
	3.1 of [RFC4090] and facility backup described in Section 3.2 of		of [RFC4090] and one-to-one backup described in Section 3.1 of
	[RFC4090].		[RFC4090]. As specified in [RFC4090], Section 4.2, the DETOUR_OBJECT
			can be used in one-to-one backup method to identify detour LSPs. In
	4.5.2. Bidirectional Bypass Tunnel Assignment Policy		one-to-one backup method, if the bypass tunnel is already in-use at
			the upstream PLR, it SHOULD send a Notify message [RFC3473] with
	In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT		Error-code - FRR Bypass Assignment Error (value: TBA1) and Sub-code -
	subobjects from multiple downstream PLRs, the selection of a bypass		One-to-one Bypass Already In-use (value: TBA4) to the downstream
	tunnel in the reverse direction can be based on local policy.		PLR.
	Examples of such a policy could be to prefer link protection over
	node protection, or to prefer the bypass tunnel to the furthest
	upstream node. When different policies are used for bypass tunnel
	assignment on the LSP path, it may result in some links in the
	reverse direction not assigned bypass protection during LSP setup as
	shown in examples below.
	As shown in Example 1, node A assigns a node protection bypass tunnel
	in the forward direction but node C does not reflect the node
	protection bypass tunnel in the reverse direction for a protected
	bidirectional GMPLS LSP A-B-C. Both nodes B and C assign a link
	protection bypass tunnel. As a result, there is no fast reroute
	protection available in the reverse direction for link A-B for this
	LSP during the LSP setup. Note that this is corrected by node C
	during the re-coroute procedure after the FRR failure on link A-B as
	specified in Section 6 of this document since GMPLS bypass tunnels
	are bidirectional.
	+------->>------+
	/ +->>-+ \
	/ / \ \
	/ / \ \
	A --->>--- B --->>---- C
	-> PATH \ /
	\ /
	+-<<-+
	Example 1: An example of different bypass assignment policy
	As shown in Example 2, nodes A and C assign a node protection bypass
	tunnel for a protected bidirectional GMPLS LSP A-B-C. Node B assigns
	a link protection bypass tunnel but node C does not reflect the
	reverse link protection bypass tunnel. As a result, there is no fast
	reroute protection available in the reverse direction for link A-B
	for this LSP during the LSP setup. Note that this is corrected by
	node C during the re-coroute procedure after the FRR failure on link
	A-B as specified in Section 6 of this document since GMPLS bypass
	tunnels are bidirectional.
	+------>>------+		4.5.2. Multiple Bidirectional Bypass Tunnel Assignments
	/ +->>-+ \
	/ / \ \
	/ / \ \
	A --->>--- B --->>---- C
	\ -> PATH /
	\ /
	\ /
	+------<<-------+
	Example 2: An example of different bypass assignment policy		The upstream PLR may receive multiple bypass tunnel assignments for a
			protected LSP from different downstream PLRs. The choice of a
			reverse bypass tunnel is based on the local policy on the upstream
			PLR. Examples of such a policy could be to prefer link protection
			over node protection, or to prefer the bypass tunnel to the furthest
			upstream node.
	4.5.3. BYPASS_ASSIGNMENT Subobject		As shown in Example 1 and Example 2, for the protected bidirectional
			GMPLS LSP R4-R5-R6, the upstream PLR R6 receives multiple bypass
			tunnel assignments, one from downstream PLR R4 for node protection
			and one from downstream PLR R5 for link protection. In Example 1, R6
			prefers the link protection bypass tunnel from downstream PLR R5
			whereas in Example 2, R6 prefers the node protection bypass tunnel
			from downstream PLR R4.
	The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP		+------->>-------+
	of the bypass tunnel being assigned by the PLR. This can be used to		/ +->>--+ \
	coordinate the bypass tunnel assignment for the protected LSP by the		/ / \ \
	downstream and upstream PLRs in the forward and reverse directions		/ / \ \
	respectively prior or after the failure occurrence.		[R4]--->>---[R5]--->>---[R6]
			PATH -> \ /
			\ /
			+-<<--+
	This subobject SHOULD be inserted into the Path RRO by the downstream		Example 1: Link protection is preferred on downstream MP
	PLR. It SHOULD NOT be inserted into an RRO by a node which is not a
	downstream PLR. It MUST NOT be changed by downstream LSRs and MUST
	NOT be added to a Resv RRO.
	The BYPASS_ASSIGNMENT subobject in RRO has the following format:		+------->>--------+
			/ +->>--+ \
			/ / \ \
			/ / \ \
			[R4]--->>---[R5]--->>---[R6]
			\ PATH -> /
			\ /
			\ /
			+-------<<--------+
	0 1 2 3		Example 2: Node protection is preferred on downstream MP
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Bypass Tunnel ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		In both examples above, the upstream PLR SHOULD send a Notify message
			[RFC3473] with Error-code - FRR Bypass Assignment Error (value: TBA1)
			and Sub-code - Bypass Assignment Cannot Be Used (value: TBA2) to the
			downstream PLR to indicate that it cannot use the bypass tunnel
			assignment. The upstream PLR can then remove the bypass assignment
			and select an alternate bypass tunnel.
	Downstream Bypass Assignment. Value is TBA by IANA.		If multiple bypass tunnel assignments are present on the upstream PLR
			R6 at the time of a failure, any resulted asymmetry gets corrected
			using the re-coroute procedure after FRR as specified in Section 6.2
			of this document.
	Length		4.6. Fast Reroute Procedure After Link Failure
			When a bidirectional bypass tunnel is used, after a link failure,
			following procedure is followed:
	The Length contains the total length of the subobject in		o The downstream PLR reroutes traffic and RSVP Path signaling over
	bytes, including the Type and Length fields. The length is		the bidirectional bypass tunnel using the procedures defined in
	always 4 bytes.		[RFC4090].
	Bypass Tunnel ID		o Upstream PLR reroutes traffic upon detecting the link failure or
			upon receiving RSVP Path message over the bidirectional bypass
			tunnel.
	The bypass tunnel identifier (16 bits).		o Upstream PLR also reroutes RSVP Resv signaling after receiving
			RSVP Path message over the bidirectional bypass tunnel.
	5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs		This procedure allows both traffic and RSVP signaling to flow on
			symmetric paths in the forward and reverse directions of a protected
			bidirectional GMPLS LSP. This is described in Section 5 for link
			protection bypass tunnels and Section 6 for node protection bypass
			tunnels.
	When a bidirectional link protection bypass tunnel is used, after a		5. Link Protection for Bidirectional GMPLS LSPs
	link failure, the downstream PLR reroutes traffic and RSVP messages
	over the bypass tunnel using the procedures defined in [RFC4090].
	Upstream PLR reroutes traffic upon detecting the link failure or upon
	receiving RSVP Path message over a bidirectional bypass tunnel.
	Upstream PLR reroutes RSVP Resv signaling upon receiving RSVP Path
	message over a bidirectional bypass tunnel. This allows both traffic
	and RSVP signaling to flow on symmetric paths in the forward and
	reverse directions of a bidirectional LSP.
	<- RESV		<- RESV
	[R1]---[R2]----[R3]------x-----[R4]----[R5]		[R1]----[R2]----[R3]-----x-----[R4]----[R5]----[R6]
	-> PATH \ /		PATH -> \ /
	+<<--------->>+		\ /
	T3		+<<----->>+
	-> PATH		T3
	RESV <-		PATH ->
			<- RESV
	Protected LSP: {R1-R2-R3-R4-R5}		Protected LSP: {R1-R2-R3-R4-R5-R6}
	R3's Bypass T3: {R3-R4}		R3's Bypass T3: {R3-R4}
	Figure 1: Flow of RSVP signaling after FRR and link failure		Figure 1: Flow of RSVP signaling after link failure and FRR
	Consider the Traffic Engineered (TE) network shown in Figure 1.		Consider the TE network shown in Figure 1. Assume every link in the
	Assume every link in the network is protected with a link protection		network is protected with a link protection bypass tunnel (e.g.
	bypass tunnel (e.g. bypass tunnel T3). For the protected		bypass tunnel T3). For the protected co-routed bidirectional LSP
	bidirectional co-routed LSP whose head-end is on node R1 and tail-end		whose head-end is on node R1 and tail-end is on node R6, each
	is on node R5, each traversed node (a potential PLR) assigns a link		traversed node (a potential PLR) assigns a link protection co-routed
	protection bidirectional co-routed bypass tunnel.		bidirectional bypass tunnel.
	5.1. Behavior After Link Failure After FRR		5.1. Behavior After Link Failure
	Consider a link R3-R4 on the protected LSP path fails. The		Consider the link R3-R4 on the protected LSP path fails. The
	downstream PLR R3 and upstream PLR R4 independently trigger fast		downstream PLR R3 and upstream PLR R4 independently trigger fast
	reroute procedures to redirect traffic onto bypass tunnels T3 in the		reroute to redirect traffic onto bypass tunnels T3 in the forward and
	forward and reverse directions. The downstream PLR R3 also reroutes		reverse directions. The downstream PLR R3 also reroutes RSVP Path
	RSVP Path state onto the bypass tunnel T3 using procedures described		messages onto the bypass tunnel T3 using the procedures described in
	in [RFC4090]. The upstream PLR R4 reroutes RSVP Resv onto the		[RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the
	reverse bypass tunnel T3 upon receiving RSVP Path message over bypass		reverse bypass tunnel T3 upon receiving RSVP Path message over bypass
	tunnel T3.		tunnel T3.
	5.2. Revertive Behavior After Link Failure After FRR		5.2. Revertive Behavior After Fast Reroute
	Revertive behavior as defined in [RFC4090], Section 6.5.2, is		Revertive behavior as defined in [RFC4090], Section 6.5.2, is
	applicable to the link protection of GMPLS bidirectional LSPs. When		applicable to the link protection of bidirectional GMPLS LSPs. When
	using the local revertive mode, when downstream MP receives Path		using the local revertive mode, after the link R3-R4 is restored,
	messages over the restored path, it starts sending Resv over the		following node behaviors apply:
	restored path and stops sending Resv over the reverse bypass tunnel.
	No additional procedure other than that specified in [RFC4090] is
	introduced for revertive behavior by this document.
	6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs		o The downstream PLR R3 starts sending the Path messages and traffic
			flow of the protected LSP over the restored link and stops sending
			them over the bypass tunnel.
	T1		o The upstream PLR R4 starts sending the Resv messages and traffic
	+<<--------->>+		flow of the protected LSP over the restored link and stops sending
			them over the bypass tunnel.
			o When upstream PLR R4 receives the protected LSP Path messages over
			the restored link, if not already done, it starts sending Resv
			messages and traffic flow of the protected LSP over the restored
			link and stops sending them over the bypass tunnel.
			6. Node Protection for Bidirectional GMPLS LSPs
			T1
			+<<------->>+
			/ \
	/ \ <- RESV		/ \ <- RESV
	[R1]---[R2]----[R3]--x--[R4]----[R5]---[R6]		[R1]----[R2]----[R3]--x--[R4]----[R5]----[R6]
	-> PATH \ /		PATH -> \ /
	+<<---------->>+		\ /
	T2		+<<------->>+
			T2
	Protected LSP: {R1-R2-R3-R4-R5-R6}		Protected LSP: {R1-R2-R3-R4-R5-R6}
	R3's Bypass T2: {R3-R5}		R3's Bypass T2: {R3-R5}
	R4's Bypass T1: {R4-R2}		R4's Bypass T1: {R4-R2}
	Figure 2: Flow of RSVP signaling after FRR and link failure		Figure 2: Flow of RSVP signaling after link failure and FRR
	Consider the Traffic Engineered (TE) network shown in Figure 2.		Consider the TE network shown in Figure 2. Assume every link in the
	Assume every link in the network is protected with a node protection		network is protected with a node protection bypass tunnel. For the
	bypass tunnel. For the protected bidirectional co-routed LSP whose		protected co-routed bidirectional LSP whose head-end is on node R1
	head-end is on node R1 and tail-end is on node R6, each traversed		and tail-end is on node R6, each traversed node (a potential PLR)
	node (a potential PLR) assigns a node protection bidirectional co-		assigns a node protection co-routed bidirectional bypass tunnel.
	routed bypass tunnel.
	The proposed solution introduces two phases to invoking FRR		The proposed solution introduces two phases to invoking FRR
	procedures by the PLR after the link failure. The first phase		procedures by the PLR after the link failure. The first phase
	comprises of FRR procedures to fast reroute data traffic onto bypass		comprises of FRR procedures to fast reroute data traffic onto bypass
	tunnels in the forward and reverse directions. The second phase		tunnels in the forward and reverse directions. The second phase
	re-coroutes the data and signaling in the forward and reverse		re-coroutes the data and signaling in the forward and reverse
	directions after the first phase.		directions after the first phase.
	6.1. Behavior After FRR and Link Failure		6.1. Behavior After Link Failure
	Consider a link R3-R4 on the protected LSP path fails. The		Consider a link R3-R4 on the protected LSP path fails. The
	downstream PLR R3 and upstream PLR R4 independently trigger fast		downstream PLR R3 and upstream PLR R4 independently trigger fast
	reroute procedures to redirect traffic onto respective bypass tunnels		reroute procedures to redirect traffic onto respective bypass tunnels
	T2 and T1 in the forward and reverse directions. The downstream PLR		T2 and T1 in the forward and reverse directions. The downstream PLR
	R3 also reroutes RSVP Path state onto the bypass tunnel T2 using		R3 also reroutes RSVP Path messages over the bypass tunnel T2 using
	procedures described in [RFC4090]. Note, at this point, node R4		the procedures described in [RFC4090]. Note, at this point, node R4
	stops receiving RSVP Path refreshes for the protected bidirectional		stops receiving RSVP Path refreshes for the protected bidirectional
	LSP while primary protected traffic continues to flow over bypass		LSP while protected traffic continues to flow over bypass tunnels.
	tunnels.		As node R4 does not receive Path messages over the bypass tunnel, it
			does not reroute RSVP Resv messages over the reverse bypass tunnel.
	6.2. Behavior After Link Failure To Re-coroute		6.2. Behavior After Link Failure To Re-coroute
	The downstream MP R5 that receives rerouted protected LSP RSVP Path		The downstream MP R5 that receives rerouted protected LSP RSVP Path
	message through the bypass tunnel, in addition to the regular MP		message through the bypass tunnel, in addition to the regular MP
	processing defined in [RFC4090], gets promoted to a Point of Remote		processing defined in [RFC4090], gets promoted to a Point of Remote
	Repair (PRR) role and performs the following actions to re-coroute		Repair (PRR) role and performs the following actions to re-coroute
	signaling and data traffic over the same path in both directions:		signaling and data traffic over the same path in the reverse
			direction:
	o Finds the bypass tunnel in the reverse direction that terminates		o Finds the bypass tunnel in the reverse direction that terminates
	on the downstream PLR R3. Note: the downstream PLR R3's address		on the downstream PLR R3. Note: the downstream PLR R3's address
	can be extracted from the "IPV4 tunnel sender address" in the		can be extracted from the "IPV4 tunnel sender address" in the
	SENDER_TEMPLATE Object of the primary LSP (see [RFC4090], Section		SENDER_TEMPLATE Object of the protected LSP (see [RFC4090],
	6.1.1).		Section 6.1.1).
	o If reverse bypass tunnel is found and the primary LSP traffic is		o If reverse bypass tunnel is found and the protected LSP traffic is
	not already rerouted over the found bypass tunnel T2, the PRR R5		not already rerouted over the found bypass tunnel T2, the PRR R5
	activates FRR reroute procedures to direct traffic over the found		activates FRR reroute procedures to direct traffic over the found
	bypass tunnel T2 in the reverse direction. In addition, the PRR		bypass tunnel T2 in the reverse direction. In addition, the PRR
	R5 also reroutes RSVP Resv over the bypass tunnel T2 in the		R5 also reroutes RSVP Resv over the bypass tunnel T2 in the
	reverse direction.		reverse direction.
	o If reverse bypass tunnel is not found, the PRR R5 immediately		o If reverse bypass tunnel is not found, the PRR R5 immediately
	tears down the primary LSP.		tears down the protected LSP.
	<- RESV		<- RESV
	[R1]---[R2]----[R3]--X--[R4]----[R5]---[R6]		[R1]----[R2]----[R3]--X--[R4]----[R5]----[R6]
	PATH -> \ /		PATH -> \ /
	+<<-------->>+		\ /
	Bypass Tunnel T2		+<<------->>+
	traffic + signaling		Bypass Tunnel T2
			traffic + signaling
	Protected LSP: {R1-R2-R3-R4-R5-R6}		Protected LSP: {R1-R2-R3-R4-R5-R6}
	R3's Bypass T2: {R3-R5}		R3's Bypass T2: {R3-R5}
	Figure 3: Flow of RSVP signaling after FRR and re-corouted		Figure 3: Flow of RSVP signaling after FRR and re-coroute
	Figure 3 describes the path taken by the traffic and signaling after		Figure 3 describes the path taken by the traffic and signaling after
	completing re-coroute of data and signaling in the forward and		completing re-coroute of data and signaling in the forward and
	reverse paths described earlier. Node R4 will stop receiving the		reverse paths described above. Node R4 will stop receiving the Path
	Path and Resv messages and it will timeout the RSVP soft-state,		and Resv messages and it will timeout the RSVP soft-state, however,
	however, this will not cause the LSP to be torn down. RSVP signaling		this will not cause the LSP to be torn down. RSVP signaling at node
	at node R2 is not affected by the FRR and re-corouting.		R2 is not affected by the FRR and re-corouting.
	If the link failure is unidirectional in the direction of R4 to R3,
	node R3 will stop receiving the RSVP Resv messages from node R4 and
	this will cause RSVP soft-state to timeout on node R3. However,
	unidirectional link failure in the opposite direction will not result
	in RSVP soft-state timeout as node R5 will trigger the re-coroute
	procedure after receiving RSVP Path message over the bypass tunnel
	from node R3.
	If downstream MP R5 receives multiple RSVP Path messages through		If downstream MP R5 receives multiple RSVP Path messages through
	multiple bypass tunnels (e.g. as a result of multiple failures), the		multiple bypass tunnels (e.g. as a result of multiple failures), the
	PRR SHOULD identify a bypass tunnel that terminates on the farthest		PRR SHOULD identify a bypass tunnel that terminates on the farthest
	downstream PLR along the protected LSP path (closest to the primary		downstream PLR along the protected LSP path (closest to the protected
	bidirectional LSP head-end) and activate the reroute procedures		bidirectional LSP head-end) and activate the reroute procedures
	mentioned above.		mentioned above.
	The downstream MP MAY optionally support re-corouting in data plane		The downstream MP (upstream PLR) MAY optionally support re-corouting
	as follows. If the downstream MP is pre-configured with		in data plane as follows. If the downstream MP is pre-configured
	bidirectional bypass tunnel, as soon as the MP node receives the		with bidirectional bypass tunnel, as soon as the downstream MP
	primary LSP packets on this bypass tunnel, it MAY switch the upstream		receives the protected LSP packets on this bypass tunnel, it MAY
	traffic on to this bypass tunnel. In order to identify the primary		switch the upstream traffic on to this bypass tunnel. In order to
	LSP packets through this bypass tunnel, Penultimate Hop Popping (PHP)		identify the protected LSP packets through this bypass tunnel,
	of the bypass tunnel MUST be disabled. The signaling procedure		Penultimate Hop Popping (PHP) of the bypass tunnel MUST be disabled.
	described above in this Section will still apply, and MP checks		The signaling procedure described above in this Section will still
	whether the primary LSP traffic and signaling is already rerouted		apply, and downstream MP checks whether the protected LSP traffic and
	over the found bypass tunnel, if not, perform the above signaling		signaling is already rerouted over the found bypass tunnel, if not,
	procedure.		perform the above signaling procedure.
	6.3. Revertive Behavior After Link Failure		6.3. Revertive Behavior After Fast Reroute
	Revertive behavior as defined in [RFC4090], Section 6.5.2, is		Revertive behavior as defined in [RFC4090], Section 6.5.2, is
	applicable to node protection of GMPLS bidirectional LSPs. When		applicable to the node protection of bidirectional GMPLS LSPs. When
	using the local revertive mode, when downstream MP (R4) (before		using the local revertive mode, after the link R3-R4 is restored,
	re-corouting) and PRR (R5) (after re-corouting) receive Path messages		following node behaviors apply:
	over the restored path, they start sending Resv over the restored
	path and stop sending Resv over the reverse bypass tunnel. No
	additional procedure other than that specified in [RFC4090] is
	introduced for revertive behavior by this document.
	7. Compatibility		o The downstream PLR R3 starts sending the Path messages and traffic
			flow of the protected LSP over the restored link and stops sending
			them over the bypass tunnel.
			o The upstream PLR R4 starts sending the Resv messages and traffic
			flow of the protected LSP over the restored link towards
			downstream PLR R3 and forwarding the Path messages towards PRR R5
			and stops sending them over the bypass tunnel.
			o When upstream PLR R4 receives the protected LSP Path messages over
			the restored link, if not already done, it starts sending Resv
			messages and traffic flow over the restored link towards
			downstream PLR R3 and forwarding the Path messages towards PRR R5
			and stops sending them over the bypass tunnel.
			o When PRR R5 receives the protected LSP Path messages over the
			restored path, it starts sending Resv messages and traffic flow
			over the restored path and stops sending them over the bypass
			tunnel.
			7. Unidirectional Link Failures
			Unidirectional link failures may result in the traffic flowing on
			asymmetric paths in the forward and reverse directions. In addition,
			unidirectional link failures may cause RSVP soft-state timeout in the
			control-plane in some cases. As an example, if the unidirectional
			link failure is in the upstream direction (from R4 to R3 in Figures 1
			and 2), the downstream PLR (node R3) can stop receiving the Resv
			messages of the protected LSP from the upstream PLR (node R4 in
			Figures 1 and 2) and this can cause RSVP soft-state timeout to occur
			on the downstream PLR (node R3).
			A unidirectional link failure in the downstream direction (from R3 to
			R4 in Figure 1 and 2), does not cause RSVP soft-state timeout when
			using the FRR procedures defined in this document, since the upstream
			PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the
			re-coroute procedure (defined in Section 6.2 of this document) after
			receiving RSVP Path messages of the protected LSP over the bypass
			tunnel from the downstream PLR (node R3 in Figures 1 and 2).
			8. Message and Object Definitions
			8.1. BYPASS_ASSIGNMENT Subobject
			The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP
			of the bypass tunnel being assigned by the PLR. This can be used to
			coordinate the bypass tunnel assignment for the protected LSP by the
			downstream and upstream PLRs in the forward and reverse directions
			respectively prior or after the failure occurrence.
			This subobject SHOULD be inserted into the Path RRO by the downstream
			PLR. It SHOULD NOT be inserted into an RRO by a node which is not a
			downstream PLR. It MUST NOT be changed by downstream LSRs and MUST
			NOT be added to a Resv RRO.
			The BYPASS_ASSIGNMENT subobject in RRO has the following format:
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type:TBA | Length | Bypass Tunnel ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv4 Bypass Destination Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type:TBA | Length | Bypass Tunnel ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| IPv6 Bypass Destination Address |
			+ (16 bytes) +
			| |
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject
			Type
			Downstream Bypass Assignment. Value is TBA by IANA.
			Length
			The Length contains the total length of the subobject in
			bytes, including the Type and Length fields. The length is 8 bytes
			with IPv4 address and 20 bytes with IPv6 object.
			Bypass Tunnel ID
			The bypass tunnel identifier (16 bits).
			Bypass Destination Address
			The bypass tunnel IPv4 or IPv6 destination address.
			8.2. FRR Bypass Assignment Error Notify Message
			New Error-code - FRR Bypass Assignment Error (value: TBA1) and its
			sub-codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205]
			in this document, that is carried by the Notify message (Type 21)
			defined in [RFC3473] Section 4.3. This Error is sent by the upstream
			PLR to the downstream PLR to notify a bypass assignment error. In
			the Notify message, the IP destination address is set to the node
			address of the downstream PLR that had initiated the bypass
			assignment. In the ERROR_SPEC Object, IP address is set to the node
			address of the upstream PLR that detected the bypass assignment
			error. This Error MUST NOT be sent in a Path Error message. This
			Error does not cause protected LSP to be torn down.
			9. Compatibility
	New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE		New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE
	Object in this document. Per [RFC2205], nodes not supporting this		Object in this document that is carried in the RSVP Path message.
	subobject will ignore the subobject but forward it without		Per [RFC3209], nodes not supporting this subobject will ignore the
	modification.		subobject but forward it without modification. As described in
			Section 8, this subobject is not carried in the RSVP Resv message. A
			new Notify message for FRR Bypass Assignment Error is defined in this
			document. Nodes not supporting this message will ignore it but
			forward it without modification.
	8. Security Considerations		10. Security Considerations
	This document introduces a new BYPASS_ASSIGNMENT subobject for the		This document introduces a new BYPASS_ASSIGNMENT subobject for the
	RECORD_ROUTE Object that is carried in an RSVP signaling message.		RECORD_ROUTE Object that is carried in an RSVP signaling message.
	Thus in the event of the interception of a signaling message, more		Thus in the event of the interception of a signaling message, more
	information about LSP's fast reroute protection can be deduced than		information about LSP's fast reroute protection can be deduced than
	was previously the case. This is judged to be a very minor security		was previously the case. This is judged to be a very minor security
	risk as this information is already available by other means.		risk as this information is already available by other means.
	Otherwise, this document introduces no additional security		Otherwise, this document introduces no additional security
	considerations. For general discussion on MPLS and GMPLS related		considerations. For general discussion on MPLS and GMPLS related
	security issues, see the MPLS/GMPLS security framework [RFC5920].		security issues, see the MPLS/GMPLS security framework [RFC5920].
	9. IANA Considerations		11. IANA Considerations
			11.1. BYPASS_ASSIGNMENT Subobject
	IANA manages the "RSVP PARAMETERS" registry located at		IANA manages the "RSVP PARAMETERS" registry located at
	<http://www.iana.org/assignments/rsvp-parameters>. IANA is requested		<http://www.iana.org/assignments/rsvp-parameters>. IANA is requested
	to assign a value for the new BYPASS_ASSIGNMENT subobject in the		to assign a value for the new BYPASS_ASSIGNMENT subobject in the
	"Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry.		"Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry.
	This document introduces a new subobject for RECORD_ROUTE Object:		This document introduces a new subobject for RECORD_ROUTE Object:
	+--------+-------------------+---------+---------+---------------+		+--------+-------------------+---------+---------+---------------+
	| Value | Description | Carried | Carried | Reference |		| Type | Description | Carried | Carried | Reference |
	| | | in Path | in Resv | |		| | | in Path | in Resv | |
	+--------+-------------------+---------+---------+---------------+		+--------+-------------------+---------+---------+---------------+
	| TBA By | BYPASS_ASSIGNMENT | Yes | No | This document |		| TBA By | BYPASS_ASSIGNMENT | Yes | No | This document |
	| IANA | subobject | | | |		| IANA | IPv4 subobject | | | |
			+--------+-------------------+---------+---------+---------------+
			| TBA By | BYPASS_ASSIGNMENT | Yes | No | This document |
			| IANA | IPv6 subobject | | | |
	+--------+-------------------+---------+---------+---------------+		+--------+-------------------+---------+---------+---------------+
	10. References		11.2. FRR Bypass Assignment Error Notify Message
	10.1. Normative References		IANA maintains the "Resource Reservation Protocol (RSVP) Parameters"
			registry (see <http://www.iana.org/assignments/rsvp-parameters>).
			The "Error Codes and Globally-Defined Error Value Sub-Codes"
			subregistry is included in this registry.
			This registry has been extended for the new Error-code and Sub-codes
			defined in this document as follows:
			o Error-code TBA1: FRR Bypass Assignment Error
			o Sub-code TBA2: Bypass Assignment Cannot Be Used
			o Sub-code TBA3: Bypass Tunnel Not Found
			o Sub-code TBA4: One-to-one Bypass Already In-use
			12. References
			12.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, September 1997.		Functional Specification", RFC 2205, September 1997.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	skipping to change at page 15, line 33 ¶		skipping to change at page 18, line 33 ¶
	January 2003.		January 2003.
	[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast		[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
	Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,		Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
	May 2005.		May 2005.
	[RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition		[RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition
	of a Record Route Object (RRO) Node-Id Sub-Object", RFC		of a Record Route Object (RRO) Node-Id Sub-Object", RFC
	4561, June 2006.		4561, June 2006.
	[RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE		12.2. Informative References
	Extensions for Associated Bidirectional LSPs", RFC 7551,
	May 2015.
	10.2. Informative References		[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
			Switching (GMPLS) Signaling Functional Description", RFC
			3471, January 2003.
			[RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of
			Addresses in Generalized Multiprotocol Label Switching
			(GMPLS) Networks", RFC 4990, September 2007.
	[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS		[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
	Networks", RFC 5920, July 2010.		Networks", RFC 5920, July 2010.
	[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and		[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
	A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear		A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
	Protection", RFC 6378, October 2011.		Protection", RFC 6378, October 2011.
			[RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE
			Extensions for Associated Bidirectional LSPs", RFC 7551,
			May 2015.
	Acknowledgements		Acknowledgements
	Authors would like to thank George Swallow for his detailed and		Authors would like to thank George Swallow for his detailed and
	useful comments and suggestions. Authors would also like to thank		useful comments and suggestions. Authors would also like to thank
	Nobo Akiya, Loa Andersson, Matt Hartley and Gregory Mirsky for		Nobo Akiya, Loa Andersson, Matt Hartley and Gregory Mirsky for
	reviewing this document.		reviewing this document. A special thanks to Adrian Farrel for his
			thorough review of this document.
	Contributors		Contributors
	Frederic Jounay		Frederic Jounay
	Orange CH		Orange CH
	EMail: frederic.jounay@orange.ch		EMail: frederic.jounay@salt.ch
	Manav Bhatia Ionos Networks Banglore India		Manav Bhatia
			Nokia
			Banglore, India
	EMail: manav@ionosnetworks.com		EMail: manav.bhatia@nokia.com
	Lizhong Jin Shanghai, China		Lizhong Jin
			Shanghai, China
	EMail: lizho.jin@gmail.com		EMail: lizho.jin@gmail.com
	Authors' Addresses		Authors' Addresses
	Mike Taillon		Mike Taillon
	Cisco Systems, Inc.		Cisco Systems, Inc.
	EMail: mtaillon@cisco.com		EMail: mtaillon@cisco.com
End of changes. 115 change blocks.
	364 lines changed or deleted		525 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/