draft-chen-mpls-p2mp-ingress-protection-10.txt		draft-chen-mpls-p2mp-ingress-protection-11.txt
	Internet Engineering Task Force H. Chen, Ed.		Internet Engineering Task Force H. Chen, Ed.
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Intended status: Standards Track R. Torvi, Ed.		Intended status: Standards Track R. Torvi, Ed.
	Expires: June 29, 2014 Juniper Networks		Expires: August 18, 2014 Juniper Networks
	December 26, 2013		February 14, 2014
	Extensions to RSVP-TE for LSP Ingress Local Protection		Extensions to RSVP-TE for LSP Ingress Local Protection
	draft-chen-mpls-p2mp-ingress-protection-10.txt		draft-chen-mpls-p2mp-ingress-protection-11.txt
	Abstract		Abstract
	This document describes extensions to Resource Reservation Protocol -		This document describes extensions to Resource Reservation Protocol -
	Traffic Engineering (RSVP-TE) for locally protecting the ingress node		Traffic Engineering (RSVP-TE) for locally protecting the ingress node
	of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi-		of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi-
	Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network.		Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 29, 2014.		This Internet-Draft will expire on August 18, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(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
	skipping to change at page 2, line 21		skipping to change at page 2, line 21
	3. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 4		3. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 4
	3.1. Backup and Source Detect Failure . . . . . . . . . . . . . 4		3.1. Backup and Source Detect Failure . . . . . . . . . . . . . 4
	3.2. Backup Detects Failure . . . . . . . . . . . . . . . . . . 5		3.2. Backup Detects Failure . . . . . . . . . . . . . . . . . . 5
	3.3. Source Detects Failure . . . . . . . . . . . . . . . . . . 5		3.3. Source Detects Failure . . . . . . . . . . . . . . . . . . 5
	3.4. Next Hops Detect Failure . . . . . . . . . . . . . . . . . 5		3.4. Next Hops Detect Failure . . . . . . . . . . . . . . . . . 5
	3.5. Comparing Different Detection Modes . . . . . . . . . . . 6		3.5. Comparing Different Detection Modes . . . . . . . . . . . 6
	4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 6		4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 6
	4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 7		4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 7
	4.2. Forwarding State on Next Hops . . . . . . . . . . . . . . 7		4.2. Forwarding State on Next Hops . . . . . . . . . . . . . . 7
	5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7		5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7
	5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 7		5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 8
	5.1.1. Subobject: Backup Ingress IPv4/IPv6 Address . . . . . 10		5.1.1. Subobject: Backup Ingress IPv4/IPv6 Address . . . . . 10
	5.1.2. Subobject: Ingress IPv4/IPv6 Address . . . . . . . . . 11		5.1.2. Subobject: Ingress IPv4/IPv6 Address . . . . . . . . . 11
	5.1.3. Subobject: Traffic Descriptor . . . . . . . . . . . . 12		5.1.3. Subobject: Traffic Descriptor . . . . . . . . . . . . 11
	5.1.4. Subobject: Label-Routes . . . . . . . . . . . . . . . 12		5.1.4. Subobject: Label-Routes . . . . . . . . . . . . . . . 12
	6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 13		6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 13
	6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13		6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13		6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13
	6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 14		6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 13
	6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 15		6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 14
	6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 15		6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 15
	6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 16		6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 15
	6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 16		6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 16
	6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 18		6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 17
	6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 18		6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 17
	6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 20		6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 20
	6.3.3. Failure Detection . . . . . . . . . . . . . . . . . . 21		6.3.3. Failure Detection . . . . . . . . . . . . . . . . . . 21
	6.4. Merge Point Behavior . . . . . . . . . . . . . . . . . . . 22		6.4. Merge Point Behavior . . . . . . . . . . . . . . . . . . . 21
	6.5. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 22		6.5. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 22
	6.5.1. Revert to Primary Ingress . . . . . . . . . . . . . . 23		6.5.1. Revert to Primary Ingress . . . . . . . . . . . . . . 22
	6.5.2. Global Repair by Backup Ingress . . . . . . . . . . . 23		6.5.2. Global Repair by Backup Ingress . . . . . . . . . . . 23
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 24		7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 25		11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
	11.2. Informative References . . . . . . . . . . . . . . . . . . 26		11.2. Informative References . . . . . . . . . . . . . . . . . . 26
	A. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26		A. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
	1. Co-authors		1. Co-authors
	Ning So, Autumn Liu, Alia Atlas, Yimin Shen, Fengman Xu, Mehmet Toy,		Ning So, Autumn Liu, Alia Atlas, Yimin Shen, Fengman Xu, Mehmet Toy,
	skipping to change at page 3, line 30		skipping to change at page 3, line 30
	this is that the backup LSP may reserve additional network bandwidth.		this is that the backup LSP may reserve additional network bandwidth.
	This specification defines a simple extension to RSVP-TE for local		This specification defines a simple extension to RSVP-TE for local
	protection of the ingress node of a P2MP or P2P LSP.		protection of the ingress node of a P2MP or P2P LSP.
	2.1. An Example of Ingress Local Protection		2.1. An Example of Ingress Local Protection
	Figure 1 shows an example of using a backup P2MP LSP to locally		Figure 1 shows an example of using a backup P2MP LSP to locally
	protect the ingress of a primary P2MP LSP, which is from ingress R1		protect the ingress of a primary P2MP LSP, which is from ingress R1
	to three egresses: L1, L2 and L3. The backup LSP is from backup		to three egresses: L1, L2 and L3. The backup LSP is from backup
	ingress Ra to the next hops R2 and R4 of ingress R1. The backup		ingress Ra to the next hops R2 and R4 of ingress R1.
	egress must be only one logical hop away from the ingress.
	[R2]******[R3]*****[L1]		[R2]******[R3]*****[L1]
	* | **** Primary LSP		* | **** Primary LSP
	* | ---- Backup LSP		* | ---- Backup LSP
	* / .... BFD Session		* / .... BFD Session
	* / $ Link		* / $ Link
	[R1]*******[R4]****[R5]*****[L2] $		[R1]*******[R4]****[R5]*****[L2] $
	$ . / / * $		$ . / / * $
	$ . / / *		$ . / / *
	[S] . / / *		[S] . / / *
	$ . / / *		$ . / / *
	$ ./ / *		$ ./ / *
	[Ra]----[Rb] [L3]		[Ra]----[Rb] [L3]
	Figure 1: Backup P2MP LSP for Locally Protecting Ingress		Figure 1: Backup P2MP LSP for Locally Protecting Ingress
	Source S may send the traffic simultaneously to both primary ingress		Source S may send the traffic simultaneously to both primary ingress
	R1 and backup ingress Ra. R1 imports the traffic into the primary		R1 and backup ingress Ra. R1 imports the traffic into the primary
	LSP. Ra normally does not put the traffic into the backup LSP.		LSP. Ra normally does not put the traffic into the backup LSP.
	Ra must be able to detect the failure of R1 and switch the traffic		Ra should be able to detect the failure of R1 and switch the traffic
	within 10s of ms. The exact method by which Ra does so is out of		within 10s of ms. The exact method by which Ra does so is out of
	scope. Different options are discussed in this draft.		scope. Different options are discussed in this draft.
	When Ra detects the failure of R1, it imports the traffic from S into		When Ra detects the failure of R1, it imports the traffic from S into
	the backup LSP to R1's next hops R2 and R4, where the traffic is		the backup LSP to R1's next hops R2 and R4, where the traffic is
	merged into the primary LSP, and then sent to egresses L1, L2 and L3.		merged into the primary LSP, and then sent to egresses L1, L2 and L3.
			Note that the backup egress must be one logical hop away from the
			ingress. A logical hop is a direct link or a tunnel such as a GRE
			tunnel, over which RSVP-TE messages may be exchanged.
	2.2. Ingress Local Protection with FRR		2.2. Ingress Local Protection with FRR
	Through using the ingress local protection and the FRR, we can		Through using the ingress local protection and the FRR, we can
	locally protect the ingress node, all the links and the intermediate		locally protect the ingress node, all the links and the intermediate
	nodes of an LSP. The traffic switchover time is within tens of		nodes of an LSP. The traffic switchover time is within tens of
	milliseconds whenever the ingress, any of the links and the		milliseconds whenever the ingress, any of the links and the
	intermediate nodes of the LSP fails.		intermediate nodes of the LSP fails.
	The ingress node of the LSP can be locally protected through using		The ingress node of the LSP can be locally protected through using
	the ingress local protection. All the links and all the intermediate		the ingress local protection. All the links and all the intermediate
	skipping to change at page 6, line 12		skipping to change at page 6, line 14
	hops selects the traffic from the primary ingress and sends the		hops selects the traffic from the primary ingress and sends the
	traffic to the destinations of the LSP.		traffic to the destinations of the LSP.
	When each of the next hops detects the failure of the primary		When each of the next hops detects the failure of the primary
	ingress, it switches to receive the traffic from the backup ingress		ingress, it switches to receive the traffic from the backup ingress
	and then sends the traffic to the destinations.		and then sends the traffic to the destinations.
	3.5. Comparing Different Detection Modes		3.5. Comparing Different Detection Modes
	+----------+--------------+----------------+--------+-------------------+		+----------+--------------+----------------+--------+-------------------+
	|Protection|Traffic Always|Backup Ingress |Next-Hop|Incorrect Failure |		|\_Behavior|Traffic Always|Backup Ingress |Next-Hop|Incorrect Failure |
	|Mode |Sent to |Activation of |Select |Detection Cause |		| \______ |Sent to |Activation of |Select |Detection Cause |
	| |Backup Ingress|Forwarding Entry|Stream |Traffic Duplication|		|Detection\|Backup Ingress|Forwarding Entry|Stream |Traffic Duplication|
	| | | | |(Ingress does FRR) |		|Mode | | | |(Ingress does FRR) |
	+----------+--------------+----------------+--------+-------------------+		+----------+--------------+----------------+--------+-------------------+
	|Backup- | | | | |		|Backup- | | | | |
	|Source- | No | Yes | No | No |		|Source- | No | Yes | No | No |
	|Detect | | | | |		|Detect | | | | |
	+----------+--------------+----------------+--------+-------------------+		+----------+--------------+----------------+--------+-------------------+
	|Backup- | Yes | Yes | No | Yes |		|Backup- | Yes | Yes | No | Yes |
	|Detect | | | | |		|Detect | | | | |
	+----------+--------------+----------------+--------+-------------------+		+----------+--------------+----------------+--------+-------------------+
	|Source- | No | No | No | No |		|Source- | No | No | No | No |
	|Detect | | (Always Active)| | |		|Detect | | (Always Active)| | |
	skipping to change at page 6, line 41		skipping to change at page 6, line 43
	| | | | |can mitigate) |		| | | | |can mitigate) |
	+----------+--------------+----------------+--------+-------------------+		+----------+--------------+----------------+--------+-------------------+
	A primary goal of failure detection and FRR protection is to avoid		A primary goal of failure detection and FRR protection is to avoid
	traffic duplication, particularly along the P2MP. A reasonable		traffic duplication, particularly along the P2MP. A reasonable
	assumption when this ingress protection is in use is that the ingress		assumption when this ingress protection is in use is that the ingress
	is also trying to provide link and node protection. When the failure		is also trying to provide link and node protection. When the failure
	cannot be accurately identified as that of the ingress, this can lead		cannot be accurately identified as that of the ingress, this can lead
	to the ingress sending traffic on bypass to the next-next-hop(s) for		to the ingress sending traffic on bypass to the next-next-hop(s) for
	node-protection while the backup ingress is sending traffic to its		node-protection while the backup ingress is sending traffic to its
	next-hop(s) if Next-Hop-Detect mode is used. RSVP Path messages sent		next-hop(s) if Next-Hop-Detect mode is used. RSVP Path messages from
	through the bypass tunnels may help to eventually resolve this by		the bypass may help to eventually resolve this by removing the
	changing the PHOP through which traffic should be received.		forwarding entry for receiving the traffic from the next-hop.
	4. Backup Forwarding State		4. Backup Forwarding State
	Before the primary ingress fails, the backup ingress is responsible		Before the primary ingress fails, the backup ingress is responsible
	for creating the necessary backup LSPs to the next hops of the		for creating the necessary backup LSPs to the next hops of the
	ingress. These LSPs might be multiple bypass P2P LSPs that avoid the		ingress. These LSPs might be multiple bypass P2P LSPs that avoid the
	ingress. Alternately, the backup ingress could choose to use a		ingress. Alternately, the backup ingress could choose to use a
	single backup P2MP LSP as a bypass or detour to protect the primary		single backup P2MP LSP as a bypass or detour to protect the primary
	ingress of a primary P2MP LSP.		ingress of a primary P2MP LSP.
	The backup ingress may be off-path (i.e., not a next-hop of the		The backup ingress may be off-path or on-path of an LSP. When a
	primary ingress) or on-path (i.e., a next-hop of the primary		backup ingress is not any node of the LSP, we call the backup ingress
	ingress). If the backup ingress is on-path, the primary forwarding		is off-path. When a backup ingress is a next-hop of the primary
	state associated with the primary LSP SHOULD be clearly separated		ingress of the LSP, we call it is on-path. If the backup ingress is
	from the backup LSP(s) state. Specifically in Backup-Detect mode,		on-path, the primary forwarding state associated with the primary LSP
	the backup ingress will receive traffic from the primary ingress and		SHOULD be clearly separated from the backup LSP(s) state.
	from the traffic source; only the former should be forwarded until		Specifically in Backup-Detect mode, the backup ingress will receive
	failure is detected even if the backup ingress is the only next-hop.		traffic from the primary ingress and from the traffic source; only
			the former should be forwarded until failure is detected even if the
			backup ingress is the only next-hop.
	4.1. Forwarding State for Backup LSP		4.1. Forwarding State for Backup LSP
	A forwarding entry for a backup LSP is created on the backup ingress		A forwarding entry for a backup LSP is created on the backup ingress
	after the LSP is set up. Depending on the failure-detection mode		after the LSP is set up. Depending on the failure-detection mode
	(e.g., source-detect), it may be set up to forward received traffic		(e.g., source-detect), it may be used to forward received traffic or
	or simply be inactive (e.g., backup-detect) until required. In		simply be inactive (e.g., backup-detect) until required. In either
	either case, when the primary ingress fails, this forwarding entry is		case, when the primary ingress fails, this forwarding entry is used
	used to import the traffic into the backup LSP to the primary		to import the traffic into the backup LSP to the next hops of the
	ingress' next hops, where the traffic is merged into the primary LSP.		primary ingress, where the traffic is merged into the primary LSP.
	The forwarding entry for a backup LSP is a local implementation		The forwarding entry for a backup LSP is a local implementation
	issue. In one device, it may have an inactive flag. This inactive		issue. In one device, it may have an inactive flag. This inactive
	forwarding entry is not used to forward any traffic normally. When		forwarding entry is not used to forward any traffic normally. When
	the primary ingress fails, it is changed to active, and thus the		the primary ingress fails, it is changed to active, and thus the
	traffic from the source is imported into the backup LSP.		traffic from the source is imported into the backup LSP.
	4.2. Forwarding State on Next Hops		4.2. Forwarding State on Next Hops
	When Next-Hop-Detect is used, a forwarding entry for a backup LSP is		When Next-Hop-Detect is used, a forwarding entry for a backup LSP is
	skipping to change at page 8, line 15		skipping to change at page 8, line 22
	Class-Num = TBD C-Type = TBD		Class-Num = TBD C-Type = TBD
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length (bytes) | Class-Num | C-Type |		| Length (bytes) | Class-Num | C-Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Secondary LSP ID | Flags | Options | DM |		| Secondary LSP ID | Flags | Options | DM |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ (Subobjects) ~		~ (Subobjects) ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Flags		Flags
	0x01 Ingress local protection available		0x01 Ingress local protection available
	0x02 Ingress local protection in use		0x02 Ingress local protection in use
	0x04 Bandwidth protection		0x04 Bandwidth protection
	Options		Options
	0x01 Revert to Ingress		0x01 Revert to Ingress
	0x02 Force to Backup		0x02 Ingress-Proxy/Relay-Message
	0x04 P2MP Backup		0x04 P2MP Backup
	DM (Detection Mode)		DM (Detection Mode)
	0x00 Backup-Source-Detect		0x00 Backup-Source-Detect
	0x01 Backup-Detect		0x01 Backup-Detect
	0x02 Source-Detect		0x02 Source-Detect
	0x03 Next-Hop-Detect		0x03 Next-Hop-Detect
	For backward compatible, the two high-order bits of the Class-Num in		For backward compatible, the two high-order bits of the Class-Num in
	the object are set as follows:		the object are set as follows:
	skipping to change at page 9, line 31		skipping to change at page 9, line 36
	protected LSP against the primary ingress failure.		protected LSP against the primary ingress failure.
	The options are used by the primary ingress to specify the desired		The options are used by the primary ingress to specify the desired
	behavior to the backup ingress and next-hops.		behavior to the backup ingress and next-hops.
	o Revert to Ingress: The primary ingress sets this option indicating		o Revert to Ingress: The primary ingress sets this option indicating
	that the traffic for the primary LSP successfully re-signaled will		that the traffic for the primary LSP successfully re-signaled will
	be switched back to the primary ingress from the backup ingress		be switched back to the primary ingress from the backup ingress
	when the primary ingress is restored.		when the primary ingress is restored.
	o Force to Backup: If the backup ingress receives an object with		o Ingress-Proxy/Relay-Message: This option is set to one indicating
	this option set for an LSP, it should activate its backup		that Ingress-Proxy method is used. It is set to zero indicating
	forwarding state; otherwise, it should deactivate its backup		that Relay-Message method is used.
	forwarding state.
	o P2MP Backup: This option is set to ask for the backup ingress to		o P2MP Backup: This option is set to ask for the backup ingress to
	use P2MP backup LSP to protect the primary ingress. Note that one		use P2MP backup LSP to protect the primary ingress. Note that one
	spare bit of the flags in the FAST-REROUTE object can be used to		spare bit of the flags in the FAST-REROUTE object can be used to
	indicate whether P2MP or P2P backup LSP is desired for protecting		indicate whether P2MP or P2P backup LSP is desired for protecting
	an ingress and intermediate node.		an ingress and intermediate node.
	The DM (Detection Mode) is used by the primary ingress to specify a		The DM (Detection Mode) is used by the primary ingress to specify a
	desired failure detection mode.		desired failure detection mode.
	skipping to change at page 10, line 33		skipping to change at page 10, line 33
	the sub object for Backup Ingress IPv4/IPv6 Address is given below:		the sub object for Backup Ingress IPv4/IPv6 Address is given below:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved (zeros) |		| Type | Length | Reserved (zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 address |		| IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 0x01 Backup Ingress IPv4 Address		Type: TBD-1 Backup Ingress IPv4 Address
	Length: Total length of the subobject in bytes, including		Length: Total length of the subobject in bytes, including
	the Type and Length fields. The Length is always 8.		the Type and Length fields. The Length is always 8.
	Reserved: Reserved two bytes are set to zeros.		Reserved: Reserved two bytes are set to zeros.
	IPv4 address: A 32-bit unicast, host address.		IPv4 address: A 32-bit unicast, host address.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved (zeros) |		| Type | Length | Reserved (zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ IPv6 address (16 bytes) ~		~ IPv6 address (16 bytes) ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 0x02 Backup Ingress IPv6 Address		Type: TBD-2 Backup Ingress IPv6 Address
	Length: Total length of the subobject in bytes, including		Length: Total length of the subobject in bytes, including
	the Type and Length fields. The Length is always 20.		the Type and Length fields. The Length is always 20.
	Reserved: Reserved two bytes are set to zeros.		Reserved: Reserved two bytes are set to zeros.
	IPv6 address: A 128-bit unicast, host address.		IPv6 address: A 128-bit unicast, host address.
	This sub object is optional. If there is not any Backup Ingress
	Address sub object in the INGRESS_PROTECTION object of the PATH
	message to the backup ingress, the backup ingress SHOULD use the
	destination address of the message as the backup ingress address.
	5.1.2. Subobject: Ingress IPv4/IPv6 Address		5.1.2. Subobject: Ingress IPv4/IPv6 Address
	The INGRESS_PROTECTION object in a PATH message from the primary		The INGRESS_PROTECTION object in a PATH message from the primary
	ingress to the backup ingress may have an Ingress IPv4/IPv6 Address		ingress to the backup ingress may have an Ingress IPv4/IPv6 Address
	sub object containing an IPv4/IPv6 address belonging to the primary		sub object containing an IPv4/IPv6 address belonging to the primary
	ingress. The sub object has the following format:		ingress. The sub object has the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved (zeros) |		| Type | Length | Reserved (zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 address |		| IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 0x03 Ingress IPv4 Address		Type: TBD-3 Ingress IPv4 Address
	Length: Total length of the subobject in bytes, including		Length: Total length of the subobject in bytes, including
	the Type and Length fields. The Length is always 8.		the Type and Length fields. The Length is always 8.
	Reserved: Reserved two bytes are set to zeros.		Reserved: Reserved two bytes are set to zeros.
	IPv4 address: A 32-bit unicast, host address.		IPv4 address: A 32-bit unicast, host address.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved (zeros) |		| Type | Length | Reserved (zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ IPv6 address (16 bytes) ~		~ IPv6 address (16 bytes) ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 0x04 Backup Ingress IPv6 Address		Type: TBD-4 Backup Ingress IPv6 Address
	Length: Total length of the subobject in bytes, including		Length: Total length of the subobject in bytes, including
	the Type and Length fields. The Length is always 20.		the Type and Length fields. The Length is always 20.
	Reserved: Reserved two bytes are set to zeros.		Reserved: Reserved two bytes are set to zeros.
	IPv6 address: A 128-bit unicast, host address.		IPv6 address: A 128-bit unicast, host address.
	This sub object is optional. If there is not any Ingress Address sub
	object in the INGRESS_PROTECTION object of the PATH message to the
	backup ingress, the backup ingress SHOULD use the address in the
	RSVP_HOP object of the message as the ingress address.
	5.1.3. Subobject: Traffic Descriptor		5.1.3. Subobject: Traffic Descriptor
	The INGRESS_PROTECTION object in a PATH message from the primary		The INGRESS_PROTECTION object in a PATH message from the primary
	ingress to the backup ingress may have a Traffic Descriptor sub		ingress to the backup ingress may have a Traffic Descriptor sub
	object describing the traffic to be mapped to the backup LSP on the		object describing the traffic to be mapped to the backup LSP on the
	backup ingress for locally protecting the primary ingress. The sub		backup ingress for locally protecting the primary ingress. The sub
	object has the following format:		object has the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved (zeros) |		| Type | Length | Reserved (zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Traffic Element 1 |		| Traffic Element 1 |
	~ ~		~ ~
	| Traffic Element n |		| Traffic Element n |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 0x05/06/07 Interface/IPv4/6 Prefix		Type: TBD-5/TBD-6/TBD-7 Interface/IPv4/6 Prefix
	Length: Total length of the subobject in bytes, including		Length: Total length of the subobject in bytes, including
	the Type and Length fields.		the Type and Length fields.
	Reserved: Reserved two bytes are set to zeros.		Reserved: Reserved two bytes are set to zeros.
	The Traffic Descriptor sub object may contain multiple Traffic		The Traffic Descriptor sub object may contain multiple Traffic
	Elements of same type as follows.		Elements of same type as follows.
	o Interface Traffic (Type 5): Each of the Traffic Elements is a 32		o Interface Traffic (Type TBD-5): Each of the Traffic Elements is a
	bit index of an interface, from which the traffic is imported into		32 bit index of an interface, from which the traffic is imported
	the backup LSP.		into the backup LSP.
	o IPv4/6 Prefix Traffic (Type 6/7): Each of the Traffic Elements is		o IPv4/6 Prefix Traffic (Type TBD-6/TBD-7): Each of the Traffic
	an IPv4/6 prefix, containing an 8-bit prefix length followed by an		Elements is an IPv4/6 prefix, containing an 8-bit prefix length
	IPv4/6 address prefix, whose length, in bits, was specified by the		followed by an IPv4/6 address prefix, whose length, in bits, was
	prefix length, padded to a byte boundary.		specified by the prefix length, padded to a byte boundary.
	5.1.4. Subobject: Label-Routes		5.1.4. Subobject: Label-Routes
	The INGRESS_PROTECTION object in a PATH message from the primary		The INGRESS_PROTECTION object in a PATH message from the primary
	ingress to the backup ingress will have a Label-Routes sub object		ingress to the backup ingress will have a Label-Routes sub object
	containing the labels and routes that the next hops of the ingress		containing the labels and routes that the next hops of the ingress
	use. The sub object has the following format:		use. The sub object has the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved (zeros) |		| Type | Length | Reserved (zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ (Subobjects) ~		~ (Subobjects) ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 0x08 Label-Routes		Type: TBD-8 Label-Routes
	Length: Total length of the subobject in bytes, including		Length: Total length of the subobject in bytes, including
	the Type and Length fields.		the Type and Length fields.
	Reserved: Reserved two bytes are set to zeros.		Reserved: Reserved two bytes are set to zeros.
	The Subobjects in the Label-Routes are copied from the Subobjects in		The Subobjects in the Label-Routes are copied from the Subobjects in
	the RECORD_ROUTE objects contained in the RESV messages that the		the RECORD_ROUTE objects contained in the RESV messages that the
	primary ingress receives from its next hops for the protected LSP.		primary ingress receives from its next hops for the protected LSP.
	They MUST contain the first hops of the LSP, each of which is paired		They MUST contain the first hops of the LSP, each of which is paired
	with its label.		with its label.
	skipping to change at page 14, line 21		skipping to change at page 14, line 5
	and 4) less control traffic.		and 4) less control traffic.
	6.1.2. Proxy-Ingress Method		6.1.2. Proxy-Ingress Method
	Conceptually, a proxy ingress is created that starts the RSVP		Conceptually, a proxy ingress is created that starts the RSVP
	signaling. The explicit path of the LSP goes from the proxy ingress		signaling. The explicit path of the LSP goes from the proxy ingress
	to the backup ingress and then to the real ingress. The behavior and		to the backup ingress and then to the real ingress. The behavior and
	signaling for the proxy ingress is done by the real ingress; the use		signaling for the proxy ingress is done by the real ingress; the use
	of a proxy ingress address avoids problems with loop detection.		of a proxy ingress address avoids problems with loop detection.
	The backup ingress must be only one logical hop away from the
	ingress, whether that be via a direct link or a tunnel.
	[ traffic source ] *** Primary LSP		[ traffic source ] *** Primary LSP
	$ $ --- Backup LSP		$ $ --- Backup LSP
	$ $ $$ Link		$ $ $$ Link
	$ $		$ $
	[ proxy ingress ] [ backup ]		[ proxy ingress ] [ backup ]
	[ & ingress ] |		[ & ingress ] |
	* |		* |
	*****[ MP ]----|		*****[ MP ]----|
	Figure 2: Example Protected LSP with Proxy Ingress Node		Figure 2: Example Protected LSP with Proxy Ingress Node
	skipping to change at page 14, line 46		skipping to change at page 14, line 27
	associated labels. This is accomplished by having the RSVP PATH and		associated labels. This is accomplished by having the RSVP PATH and
	RESV messages go through the backup ingress, although the forwarding		RESV messages go through the backup ingress, although the forwarding
	path need not go through the backup ingress. If the backup ingress		path need not go through the backup ingress. If the backup ingress
	fails, the ingress simply removes the INGRESS-PROTECTION object and		fails, the ingress simply removes the INGRESS-PROTECTION object and
	forwards the PATH messages to the LSP's next-hop(s). If the ingress		forwards the PATH messages to the LSP's next-hop(s). If the ingress
	has its LSP configured for ingress protection, then the ingress can		has its LSP configured for ingress protection, then the ingress can
	add the backup ingress and itself to the ERO and start forwarding the		add the backup ingress and itself to the ERO and start forwarding the
	PATH messages to the backup ingress.		PATH messages to the backup ingress.
	Slightly different behavior can apply for the on-path and off-path		Slightly different behavior can apply for the on-path and off-path
	cases. In the on-path case, the backup ingress is already the only		cases. In the on-path case, the backup ingress is a next hop node
	immediate node after the ingress for the LSP. In the off-path, the		after the ingress for the LSP. In the off-path, the backup ingress
	backup ingress is not the immediate node after the ingress for all		is not any next-hop node after the ingress for all associated sub-
	associated sub-LSPs.		LSPs.
	The key advantage of this approach is that it minimizes the special		The key advantage of this approach is that it minimizes the special
	handling code requires. Because the backup ingress is on the		handling code requires. Because the backup ingress is on the
	signaling path, it can receive various notifications. It easily has		signaling path, it can receive various notifications. It easily has
	access to all the PATH messages needed for modification to be sent to		access to all the PATH messages needed for modification to be sent to
	refresh control-plane state after a failure.		refresh control-plane state after a failure.
	6.1.3. Comparing Two Methods		6.1.3. Comparing Two Methods
	+-------+-----------+------+--------+-----------------+---------+		+-------+-----------+------+--------+-----------------+---------+
	skipping to change at page 15, line 29		skipping to change at page 15, line 8
	|Relay- | No |Yes | No | No | Yes- |		|Relay- | No |Yes | No | No | Yes- |
	|Message| | | | | |		|Message| | | | | |
	+-------+-----------+------+--------+-----------------+---------+		+-------+-----------+------+--------+-----------------+---------+
	|Proxy- | Yes |Yes- | Yes | Yes | Yes |		|Proxy- | Yes |Yes- | Yes | Yes | Yes |
	|Ingress| | | | | |		|Ingress| | | | | |
	+-------+-----------+------+--------+-----------------+---------+		+-------+-----------+------+--------+-----------------+---------+
	6.2. Ingress Behavior		6.2. Ingress Behavior
	The primary ingress must be configured with four pieces of		The primary ingress must be configured with four pieces of
	information for ingress protect.		information for ingress protection.
	o Backup Ingress Address: The primary ingress must know an IP		o Backup Ingress Address: The primary ingress must know an IP
	address for it to be included in the INGRESS-PROTECTION object.		address for it to be included in the INGRESS-PROTECTION object.
	o Failure Detection Mode: The primary ingress must know what failure		o Failure Detection Mode: The primary ingress must know what failure
	detection mode is to be used: Backup-Source-Detect, Backup-Detect,		detection mode is to be used: Backup-Source-Detect, Backup-Detect,
	Source-Detect, or Next-Hop-Detect.		Source-Detect, or Next-Hop-Detect.
	o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The		o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The
	Proxy-Ingress-Id is only used in the Record Route Object for		Proxy-Ingress-Id is only used in the Record Route Object for
	skipping to change at page 16, line 18		skipping to change at page 15, line 45
	With this additional information, the primary ingress can create and		With this additional information, the primary ingress can create and
	signal the necessary RSVP extensions to support ingress protection.		signal the necessary RSVP extensions to support ingress protection.
	6.2.1. Relay-Message Method		6.2.1. Relay-Message Method
	To protect the ingress of an LSP, the ingress does the following		To protect the ingress of an LSP, the ingress does the following
	after the LSP is up.		after the LSP is up.
	1. Select a PATH message.		1. Select a PATH message.
	2. If the backup ingress is not a next hop of the primary ingress		2. If the backup ingress is off-path, then send the backup ingress a
	(i.e., off-path case), then send the backup ingress a PATH		PATH message with the content from the selected PATH message and
	message with the content from the selected PATH message and an		an INGRESS-PROTECTION object; else (the backup ingress is a next
	INGRESS-PROTECTION object; else (the backup ingress is a next
	hop, i.e., on-path case) add an INGRESS-PROTECTION object into		hop, i.e., on-path case) add an INGRESS-PROTECTION object into
	the existing PATH message to the backup ingress (i.e., the next		the existing PATH message to the backup ingress (i.e., the next
	hop). The INGRESS-PROTECTION object contains the Traffic-		hop). The INGRESS-PROTECTION object contains the Traffic-
	Descriptor sub-object, the Backup Ingress Address sub-object and		Descriptor sub-object, the Backup Ingress Address sub-object and
	the Label-Routes sub-object. The DM (Detection Mode) in the		the Label-Routes sub-object. The DM (Detection Mode) in the
	object is set to indicate the failure detection mode desired.		object is set to indicate the failure detection mode desired.
	The flags is set to indicate whether a Backup P2MP LSP is		The flags is set to indicate whether a Backup P2MP LSP is
	desired. If not yet allocated, allocate a second LSP-ID to be		desired. If not yet allocated, allocate a second LSP-ID to be
	used in the INGRESS-PROTECTION object. The Label-Routes sub-		used in the INGRESS-PROTECTION object. The Label-Routes sub-
	object contains the next-hops of the ingress and their labels.		object contains the next-hops of the ingress and their labels.
	skipping to change at page 17, line 23		skipping to change at page 16, line 46
	Include the Backup Ingress Address (IPv4 or IPv6) sub-object and		Include the Backup Ingress Address (IPv4 or IPv6) sub-object and
	the Traffic-Descriptor sub-object. Set the control-options to		the Traffic-Descriptor sub-object. Set the control-options to
	indicate the failure detection mode desired. Set or clear the		indicate the failure detection mode desired. Set or clear the
	flag indicating that a Backup P2MP LSP is desired.		flag indicating that a Backup P2MP LSP is desired.
	6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path		6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path
	message. Indicate whether one-to-one backup is desired.		message. Indicate whether one-to-one backup is desired.
	Indicate whether facility backup is desired.		Indicate whether facility backup is desired.
	7. The RSVP PATH message is sent to the backup node as normal.		7. The RSVP PATH message is sent to the backup node as normal.
	Since the backup ingress node must be only one logical hop away
	from the ingress, normal RSVP signaling can be used.
	If the ingress detects that it can't communicate with the backup		If the ingress detects that it can't communicate with the backup
	ingress, then the ingress should instead send the PATH message to the		ingress, then the ingress should instead send the PATH message to the
	next-hop indicated in the ERO computed in step 1. Once the ingress		next-hop indicated in the ERO computed in step 1. Once the ingress
	detects that it can communicate with the backup ingress, the ingress		detects that it can communicate with the backup ingress, the ingress
	SHOULD follow the steps 1-7 to obtain ingress failure protection.		SHOULD follow the steps 1-7 to obtain ingress failure protection.
	When the ingress node receives an RSVP PATH message with an INGRESS-		When the ingress node receives an RSVP PATH message with an INGRESS-
	PROTECTION object and the object specifies that node as the ingress		PROTECTION object and the object specifies that node as the ingress
	node and the PHOP as the backup ingress node, the ingress node SHOULD		node and the PHOP as the backup ingress node, the ingress node SHOULD
	skipping to change at page 17, line 46		skipping to change at page 17, line 19
	and, if it is not the Next-Hop-Detect, then the ingress node SHOULD		and, if it is not the Next-Hop-Detect, then the ingress node SHOULD
	remove the INGRESS-PROTECTION object from the PATH message before		remove the INGRESS-PROTECTION object from the PATH message before
	sending it out. Additionally, the ingress node must store that it		sending it out. Additionally, the ingress node must store that it
	will install ingress forwarding state for the LSP rather than		will install ingress forwarding state for the LSP rather than
	midpoint forwarding.		midpoint forwarding.
	When an RSVP RESV message is received by the ingress, it uses the		When an RSVP RESV message is received by the ingress, it uses the
	NHOP to determine whether the message is received from the backup		NHOP to determine whether the message is received from the backup
	ingress or from a different node. The stored associated PATH message		ingress or from a different node. The stored associated PATH message
	contains an INGRESS-PROTECTION object that identifies the backup		contains an INGRESS-PROTECTION object that identifies the backup
	ingres node. If the RESV message is not from the backup node, then		ingress node. If the RESV message is not from the backup node, then
	ingress forwarding state should be set up, and the INGRESS-PROTECTION		ingress forwarding state should be set up, and the INGRESS-PROTECTION
	object MUST be added to the RESV before it is sent to the NHOP, which		object MUST be added to the RESV before it is sent to the NHOP, which
	should be the backup node. If the RESV message is from the backup		should be the backup node. If the RESV message is from the backup
	node, then the LSP should be considered available for use.		node, then the LSP should be considered available for use.
	If the backup ingress node is on the forwarding path, then a RESV is		If the backup ingress node is on the forwarding path, then a RESV is
	received with an INGRESS-PROTECTION object and an NHOP that matches		received with an INGRESS-PROTECTION object and an NHOP that matches
	the backup ingress. In this case, the ingress node's address will		the backup ingress. In this case, the ingress node's address will
	not appear after the backup ingress in the RRO. The ingress node		not appear after the backup ingress in the RRO. The ingress node
	should set up ingress forwarding state, just as is done if the LSP		should set up ingress forwarding state, just as is done if the LSP
	weren't ingress-node protected.		weren't ingress-node protected.
	6.3. Backup Ingress Behavior		6.3. Backup Ingress Behavior
	An LER determines that the ingress local protection is requested for		An LER determines that the ingress local protection is requested for
	an LSP if the INGRESS_PROTECTION object is included in the PATH		an LSP if the INGRESS_PROTECTION object is included in the PATH
	message it receives for the LSP. The LER can further determine that		message it receives for the LSP. The LER can further determine that
	it is the backup ingress if one of its addresses is in the Backup		it is the backup ingress if one of its addresses is in the Backup
	Ingress Address sub-object of the INGRESS-PROTECTION object. In		Ingress Address sub-object of the INGRESS-PROTECTION object. The LER
	addition, the LER determines that it is off-path if it is not a next		as the backup ingress will assume full responsibility of the ingress
	hop of the primary ingress.		after the primary ingress fails. In addition, the LER determines
			that it is off-path if it is not a next hop of the primary ingress.
	6.3.1. Backup Ingress Behavior in Off-path Case		6.3.1. Backup Ingress Behavior in Off-path Case
	The backup ingress considers itself as a PLR and the primary ingress		The backup ingress considers itself as a PLR and the primary ingress
	as its next hop and provides a local protection for the primary		as its next hop and provides a local protection for the primary
	ingress. It behaves very similarly to a PLR providing fast-reroute		ingress. It behaves very similarly to a PLR providing fast-reroute
	where the primary ingress is considered as the failure-point to		where the primary ingress is considered as the failure-point to
	protect. Where not otherwise specified, the behavior given in		protect. Where not otherwise specified, the behavior given in
	[RFC4090] for a PLR should apply.		[RFC4090] for a PLR should apply.
	skipping to change at page 19, line 16		skipping to change at page 18, line 38
	protection available", "Ingress local protection in use", and		protection available", "Ingress local protection in use", and
	"bandwidth protection".		"bandwidth protection".
	If the backup ingress doesn't have a backup LSP tunnel to all the		If the backup ingress doesn't have a backup LSP tunnel to all the
	merge points, it SHOULD clear "Ingress local protection available".		merge points, it SHOULD clear "Ingress local protection available".
	[Editor Note: It is possible to indicate the number or which are		[Editor Note: It is possible to indicate the number or which are
	unprotected via a sub-object if desired.]		unprotected via a sub-object if desired.]
	When the primary ingress fails, the backup ingress redirects the		When the primary ingress fails, the backup ingress redirects the
	traffic from a source into the backup P2P LSPs or the backup P2MP LSP		traffic from a source into the backup P2P LSPs or the backup P2MP LSP
	transmitting the traffic to the primary ingress' next hops, where the		transmitting the traffic to the next hops of the primary ingress,
	traffic is merged into the protected LSP.		where the traffic is merged into the protected LSP.
	In this case, the backup ingress keeps the PATH message with the		In this case, the backup ingress keeps the PATH message with the
	INGRESS_PROTECTION object received from the primary ingress and the		INGRESS_PROTECTION object received from the primary ingress and the
	RESV message with the INGRESS_PROTECTION object to be sent to the		RESV message with the INGRESS_PROTECTION object to be sent to the
	primary ingress. The backup ingress sets the "local protection in		primary ingress. The backup ingress sets the "local protection in
	use" flag in the RESV message, indicating that the backup ingress is		use" flag in the RESV message, indicating that the backup ingress is
	actively redirecting the traffic into the backup P2P LSPs or the		actively redirecting the traffic into the backup P2P LSPs or the
	backup P2MP LSP for locally protecting the primary ingress failure.		backup P2MP LSP for locally protecting the primary ingress failure.
	Note that the RESV message with this piece of information will not be		Note that the RESV message with this piece of information will not be
End of changes. 46 change blocks.
	94 lines changed or deleted		76 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/