draft-ietf-mpls-rsvp-ingress-protection-01.txt		draft-ietf-mpls-rsvp-ingress-protection-02.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: January 4, 2015 Juniper Networks		Expires: April 29, 2015 Juniper Networks
	July 3, 2014		October 26, 2014
	Extensions to RSVP-TE for LSP Ingress Local Protection		Extensions to RSVP-TE for LSP Ingress Local Protection
	draft-ietf-mpls-rsvp-ingress-protection-01.txt		draft-ietf-mpls-rsvp-ingress-protection-02.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 January 4, 2015.		This Internet-Draft will expire on April 29, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	skipping to change at page 2, line 14		skipping to change at page 2, line 14
	Table of Contents		Table of Contents
	1. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. An Example of Ingress Local Protection . . . . . . . . . . 3		2.1. An Example of Ingress Local Protection . . . . . . . . . . 3
	2.2. Ingress Local Protection with FRR . . . . . . . . . . . . 4		2.2. Ingress Local Protection with FRR . . . . . . . . . . . . 4
	3. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 4		3. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 4
	3.1. Source Detects Failure . . . . . . . . . . . . . . . . . . 4		3.1. Source Detects Failure . . . . . . . . . . . . . . . . . . 4
	3.2. Backup and Source Detect Failure . . . . . . . . . . . . . 5		3.2. Backup and Source Detect Failure . . . . . . . . . . . . . 5
	3.3. Comparing Different Detection Modes . . . . . . . . . . . 5
	4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 5		4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 5
	4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 6		4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 5
	5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6		5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6
	5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 6		5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 6
	5.1.1. Subobject: Backup Ingress IPv4/IPv6 Address . . . . . 8		5.1.1. Subobject: Backup Ingress IPv4/IPv6 Address . . . . . 7
	5.1.2. Subobject: Ingress IPv4/IPv6 Address . . . . . . . . . 9		5.1.2. Subobject: Ingress IPv4/IPv6 Address . . . . . . . . . 8
	5.1.3. Subobject: Traffic Descriptor . . . . . . . . . . . . 9		5.1.3. Subobject: Traffic Descriptor . . . . . . . . . . . . 8
	5.1.4. Subobject: Label-Routes . . . . . . . . . . . . . . . 10		5.1.4. Subobject: Label-Routes . . . . . . . . . . . . . . . 9
	6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 11		6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 9
	6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11		6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 11		6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 9
	6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 11		6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 10
	6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 12		6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 11
	6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 13		6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 11
	6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13		6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 12
	6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 14		6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 12
	6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 15		6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 13
	6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 15		6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 14
	6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 17		6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 16
	6.3.3. Failure Detection . . . . . . . . . . . . . . . . . . 18		6.3.3. Failure Detection and Refresh PATH Messages . . . . . 17
	6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 19		6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 17
	6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 19		6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 18
	6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 19		6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 21		11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	11.2. Informative References . . . . . . . . . . . . . . . . . . 22		11.2. Informative References . . . . . . . . . . . . . . . . . . 21
	A. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22		A. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
	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, Tarek Saad, Fengman Xu,
	Lei Liu		Mehmet Toy, Lei Liu
	2. Introduction		2. Introduction
	For MPLS LSPs it is important to have a fast-reroute method for		For MPLS LSPs it is important to have a fast-reroute method for
	protecting its ingress node as well as transit nodes. This is not		protecting its ingress node as well as transit nodes. This is not
	covered either in the fast-reroute method defined in [RFC4090] or in		covered either in the fast-reroute method defined in [RFC4090] or in
	the P2MP fast-reroute extensions to fast-reroute in [RFC4875].		the P2MP fast-reroute extensions to fast-reroute in [RFC4875].
	An alternate approach to local protection (fast-reroute) is to use		An alternate approach to local protection (fast-reroute) is to use
	global protection and set up a second backup LSP (whether P2MP or		global protection and set up a second backup LSP (whether P2MP or
	skipping to change at page 3, line 48		skipping to change at page 3, line 48
	: $ $ / / * $		: $ $ / / * $
	: $ $ / / *		: $ $ / / *
	[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
	In normal operations, source S sends the traffic to primary ingress		In normal operations, source S sends the traffic to primary ingress
	R1. R1 imports the traffic into the primary LSP to egresses L1, L2		R1. R1 imports the traffic into the primary LSP.
	and L3.
	When source S detects the failure of R1, it switches the traffic to		When source S detects the failure of R1, it switches the traffic to
	backup ingress Ra, which imports the traffic from S into the backup		backup ingress Ra, which imports the traffic from S into the backup
	LSP to R1's next hops R2 and R4, where the traffic is merged into the		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.		primary LSP, and then sent to egresses L1, L2 and L3.
	Source S should be able to detect the failure of R1 and switch the		Source S should be able to detect the failure of R1 and switch the
	traffic within 10s of ms. The exact method by which S does so is out		traffic within 10s of ms.
	of scope.
	Note that the backup ingress must be one logical hop away from the		Note that the backup ingress must be one logical hop away from the
	ingress. A logical hop is a direct link or a tunnel such as a GRE		ingress. A logical hop is a direct link or a tunnel such as a GRE
	tunnel, over which RSVP-TE messages may be exchanged.		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, all the links and the transit nodes of
	nodes of an LSP. The traffic switchover time is within tens of		an LSP. The traffic switchover time is within 10s of ms whenever the
	milliseconds whenever the ingress, any of the links and the		ingress, any of the links and the transit 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 transit
	nodes of the LSP can be locally protected through using the FRR.		nodes of the LSP can be locally protected through using the FRR.
	3. Ingress Failure Detection		3. Ingress Failure Detection
	Exactly how the failure of the ingress (e.g. R1 in Figure 1) is		Exactly how to detect the failure of the ingress is out of scope.
	detected is out of scope for this document. However, it is necessary		However, it is necessary to discuss different modes for detecting the
	to discuss different modes for detecting the failure because they		failure because they determine what is the required behavior for the
	determine what must be signaled and what is the required behavior for		source and backup ingress.
	the traffic source and backup ingress.
	3.1. Source Detects Failure		3.1. Source Detects Failure
	Source Detects Failure or Source-Detect for short means that the		Source Detects Failure or Source-Detect for short means that the
	source is responsible for fast detecting the failure of the primary		source is responsible for fast detecting the failure of the primary
	ingress of an LSP. The backup ingress is ready to import the traffic		ingress of an LSP. The backup ingress is ready to import the traffic
	from the source into the backup LSP after the backup LSP is up.		from the source into the backup LSP after the backup LSP is up.
	In normal operations, the source sends the traffic to the primary		In normal operations, the source sends the traffic to the primary
	ingress. When the source detects the failure of the primary ingress,		ingress. When the source detects the failure of the primary ingress,
	skipping to change at page 5, line 18		skipping to change at page 5, line 14
	through the backup LSP as needed.		through the backup LSP as needed.
	After the primary ingress fails, it will not be reachable after		After the primary ingress fails, it will not be reachable after
	routing convergence. Thus checking whether the primary ingress		routing convergence. Thus checking whether the primary ingress
	(address) is reachable is a possible method.		(address) is reachable is a possible method.
	3.2. Backup and Source Detect Failure		3.2. Backup and Source Detect Failure
	Backup and Source Detect Failure or Backup-Source-Detect for short		Backup and Source Detect Failure or Backup-Source-Detect for short
	means that both the backup ingress and the source are concurrently		means that both the backup ingress and the source are concurrently
	responsible for fast detecting the failures of the primary ingress.		responsible for fast detecting the failure of the primary ingress.
	In normal operations, the source sends the traffic to the primary		In normal operations, the source sends the traffic to the primary
	ingress. It switches the traffic to the backup ingress when it		ingress. It switches the traffic to the backup ingress when it
	detects the failure of the primary ingress.		detects the failure of the primary ingress.
	The backup ingress does not import any traffic from the source into		The backup ingress does not import any traffic from the source into
	the backup LSP in normal operations. When it detects the failure of		the backup LSP in normal operations. When it detects the failure of
	the primary ingress, it imports the traffic from the source into the		the primary ingress, it imports the traffic from the source into the
	backup LSP to the next hops of the primary ingress, where the traffic		backup LSP to the next hops of the primary ingress, where the traffic
	is merged into the primary LSP.		is merged into the primary LSP.
	Note that the source may locally distinguish between the failure of
	the primary ingress and that of the link between the source and the
	primary ingress. When the source detects the failure of the link, it
	may continue to send the traffic to the primary ingress via another
	link between the source and the primary ingress if there is one.
	3.3. Comparing Different Detection Modes
	The source-detect is preferred. It is simpler than the backup-		The source-detect is preferred. It is simpler than the backup-
	source-detect, which needs both the source and the backup ingress		source-detect, which needs both the source and the backup ingress
	detect the ingress failaure quickly.		detect the ingress failure quickly.
	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. These LSPs might be multiple		for creating the necessary backup LSPs. These LSPs might be multiple
	bypass P2P LSPs that avoid the ingress. Alternately, the backup		bypass P2P LSPs that avoid the ingress. Alternately, the backup
	ingress could choose to use a single backup P2MP LSP as a bypass or		ingress could choose to use a single backup P2MP LSP as a bypass or
	detour to protect the primary ingress of a primary P2MP LSP.		detour to protect the primary ingress of a primary P2MP LSP.
	The backup ingress may be off-path or on-path of an LSP. When a		The backup ingress may be off-path or on-path of an LSP. If a backup
	backup ingress is not any node of the LSP, we call the backup ingress		ingress is not any node of the LSP, we call it is off-path. If a
	is off-path. When a backup ingress is a next-hop of the primary		backup ingress is a next-hop of the primary ingress of the LSP, we
	ingress of the LSP, we call it is on-path. If the backup ingress is		call it is on-path. If it is on-path, the primary forwarding state
	on-path, the primary forwarding state associated with the primary LSP		associated with the primary LSP SHOULD be clearly separated from the
	SHOULD be clearly separated from the backup LSP(s) state.		backup LSP(s) state.
	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 used to forward received traffic or		(e.g., source-detect), it may be used to forward received traffic or
	simply be inactive (e.g., backup-source-detect) until required. In		simply be inactive (e.g., backup-source-detect) until required. In
	either case, when the primary ingress fails, this entry is used to		either case, when the primary ingress fails, this entry is used to
	import the traffic into the backup LSP to the next hops of the		import the traffic into the backup LSP to the next hops of the
	primary ingress, where the traffic is merged into the primary LSP.		primary ingress, where the traffic is merged into the primary LSP.
	skipping to change at page 6, line 40		skipping to change at page 6, line 28
	5.1. INGRESS_PROTECTION Object		5.1. INGRESS_PROTECTION Object
	The INGRESS_PROTECTION object with the FAST_REROUTE object in a PATH		The INGRESS_PROTECTION object with the FAST_REROUTE object in a PATH
	message is used to control the backup for protecting the primary		message is used to control the backup for protecting the primary
	ingress of a primary LSP. The primary ingress MUST insert this		ingress of a primary LSP. The primary ingress MUST insert this
	object into the PATH message to be sent to the backup ingress for		object into the PATH message to be sent to the backup ingress for
	protecting the primary ingress. It has the following format:		protecting the primary ingress. It has the following format:
	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 |		| Secondary LSP ID | Flags | Options |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ (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 Ingress-Proxy/Relay-Message		0x02 P2MP Backup
	0x04 P2MP Backup
	The Secondary LSP ID in the object is an LSP ID that the primary		The Secondary LSP ID in the object is an LSP ID that the primary
	ingress has allocated for a protected LSP tunnel. The backup ingress		ingress has allocated for a protected LSP tunnel. The backup ingress
	will use this LSP ID to set up a new LSP from the backup ingress to		may use this LSP ID to set up a new LSP from the backup ingress to
	the destinations of the protected LSP tunnel. This allows the new		the destinations of the protected LSP tunnel. This allows the new
	LSP to share resources with the old one.		LSP to share resources with the old one.
	The flags are used to communicate status information from the backup		The flags are used to communicate status information from the backup
	ingress to the primary ingress.		ingress to the primary ingress.
	o Ingress local protection available: The backup ingress sets this		o Ingress local protection available: The backup ingress sets this
	flag after backup LSPs are up and ready for locally protecting the		flag after backup LSPs are up and ready for locally protecting the
	primary ingress. The backup ingress sends this to the primary		primary ingress. The backup ingress sends this to the primary
	ingress to indicate that the primary ingress is locally protected.		ingress to indicate that the primary ingress is locally protected.
	skipping to change at page 7, line 38		skipping to change at page 7, line 25
	o Ingress local protection in use: The backup ingress sets this flag		o Ingress local protection in use: The backup ingress sets this flag
	when it detects a failure in the primary ingress. The backup		when it detects a failure in the primary ingress. The backup
	ingress keeps it and does not send it to the primary ingress since		ingress keeps it and does not send it to the primary ingress since
	the primary ingress is down.		the primary ingress is down.
	o Bandwidth protection: The backup ingress sets this flag if the		o Bandwidth protection: The backup ingress sets this flag if the
	backup LSPs guarantee to provide desired bandwidth for the		backup LSPs guarantee to provide desired bandwidth for the
	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.
	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 Ingress-Proxy/Relay-Message: This option is set to one indicating
	that Ingress-Proxy method is used. It is set to zero indicating
	that Relay-Message method is used.
	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 transit node.
	The INGRESS_PROTECTION object may contain some of the sub objects		The INGRESS_PROTECTION object may contain some sub objects below.
	described below.
	5.1.1. Subobject: Backup Ingress IPv4/IPv6 Address		5.1.1. Subobject: Backup Ingress IPv4/IPv6 Address
	When the primary ingress of a protected LSP sends a PATH message with		When the primary ingress of a protected LSP sends a PATH message with
	an INGRESS_PROTECTION object to the backup ingress, the object may		an INGRESS_PROTECTION object to the backup ingress, the object may
	have a Backup Ingress IPv4/IPv6 Address sub object containing an		have a Backup Ingress IPv4/IPv6 Address sub object containing an
	IPv4/IPv6 address belonging to the backup ingress. The formats of		IPv4/IPv6 address belonging to the backup ingress. The Type of the
	the sub object for Backup Ingress IPv4/IPv6 Address is given below:		sub object is TBD-1/TBD-2 for Backup Ingress IPv4/IPv6 Address. The
			body of the sub object is given below:
	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 | Length | Reserved (zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: TBD-1 Backup Ingress IPv4 Address
	Length: Total length of the subobject in bytes, including
	the Type and Length fields. The Length is always 8.
	Reserved: Reserved two bytes are set to zeros.
	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) |		| IPv4/IPv6 address (4/16 bytres) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ IPv6 address (16 bytes) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: TBD-2 Backup Ingress IPv6 Address		IPv4/IPv6 address: A 32/128-bit unicast, host address.
	Length: Total length of the subobject in bytes, including
	the Type and Length fields. The Length is always 20.
	Reserved: Reserved two bytes are set to zeros.
	IPv6 address: A 128-bit unicast, host address.
	5.1.2. Subobject: Ingress IPv4/IPv6 Address		5.1.2. Subobject: Ingress IPv4/IPv6 Address
	The INGRESS_PROTECTION object may have an Ingress IPv4/IPv6 Address		The INGRESS_PROTECTION object 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 Type of the sub object is TBD-3/TBD-4 for Ingress IPv4/
			IPv6 Address. The sub object has the following body:
	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 | Length | Reserved (zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: TBD-3 Ingress IPv4 Address
	Length: Total length of the subobject in bytes, including
	the Type and Length fields. The Length is always 8.
	Reserved: Reserved two bytes are set to zeros.
	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) |		| IPv4/IPv6 address (4/16 bytres) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ IPv6 address (16 bytes) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: TBD-4 Backup Ingress IPv6 Address		IPv4/IPv6 address: A 32/128-bit unicast, host address.
	Length: Total length of the subobject in bytes, including
	the Type and Length fields. The Length is always 20.
	Reserved: Reserved two bytes are set to zeros.
	IPv6 address: A 128-bit unicast, host address.
	5.1.3. Subobject: Traffic Descriptor		5.1.3. Subobject: Traffic Descriptor
	The INGRESS_PROTECTION object may have a Traffic Descriptor sub		The INGRESS_PROTECTION object 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 Type
	object has the following format:		of the sub object is TBD-5/TBD-6/TBD-7 for Interface/IPv4/6 Prefix
			respectively. The sub object has the following body:
	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 | Length | Reserved (zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Traffic Element 1 |
	~ ~
	| Traffic Element n |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: TBD-5/TBD-6/TBD-7 Interface/IPv4/6 Prefix		0 1 2 3
	Length: Total length of the subobject in bytes, including		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
	the Type and Length fields.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Reserved: Reserved two bytes are set to zeros.		| Traffic Element 1 |
			~ ~
			| Traffic Element n |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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 TBD-5): Each of the Traffic Elements is a		o Interface Traffic (Type TBD-5): Each of the Traffic Elements is a
	32 bit index of an interface, from which the traffic is imported		32 bit index of an interface, from which the traffic is imported
	into the backup LSP.		into the backup LSP.
	o IPv4/6 Prefix Traffic (Type TBD-6/TBD-7): Each of the Traffic		o IPv4/6 Prefix Traffic (Type TBD-6/TBD-7): Each of the Traffic
	Elements is an IPv4/6 prefix, containing an 8-bit prefix length		Elements is an IPv4/6 prefix, containing an 8-bit prefix length
	followed by an IPv4/6 address prefix, whose length, in bits, was		followed by an IPv4/6 address prefix, whose length, in bits, was
	specified by the 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 Type of the sub object is TBD-8. The sub object has the
			following body:
	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 | Length | Reserved (zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ (Subobjects) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: TBD-8 Label-Routes		0 1 2 3
	Length: Total length of the subobject in bytes, including		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
	the Type and Length fields.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Reserved: Reserved two bytes are set to zeros.		~ Subobjects ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Subobjects in the Label-Routes are copied from the Subobjects in		The Subobjects in the Label-Routes are copied from those in the
	the RECORD_ROUTE objects contained in the RESV messages that the		RECORD_ROUTE objects in the RESV messages that the primary ingress
	primary ingress receives from its next hops for the protected LSP.		receives from its next hops for the primary LSP. They MUST contain
	They MUST contain the first hops of the LSP, each of which is paired		the first hops of the LSP, each of which is paired with its label.
	with its label.
	6. Behavior of Ingress Protection		6. Behavior of Ingress Protection
	6.1. Overview		6.1. Overview
	There are four parts of ingress protection: 1) setting up the		There are four parts of ingress protection: 1) setting up the
	necessary backup LSP forwarding state; 2) identifying the failure and		necessary backup LSP forwarding state; 2) identifying the failure and
	providing the fast repair (as discussed in Sections 2 and 3); 3)		providing the fast repair (as discussed in Sections 3 and 4); 3)
	maintaining the RSVP-TE control plane state until a global repair can		maintaining the RSVP-TE control plane state until a global repair can
	be done; and 4) performing the global repair(see Section 5.5).		be done; and 4) performing the global repair(see Section 6.4).
	There are two different proposed signaling approaches to obtain		There are two different proposed signaling approaches to obtain
	ingress protection. They both use the same new INGRESS-PROTECTION		ingress protection. They both use the same new INGRESS_PROTECTION
	object. The object is sent in both PATH and RESV messages.		object. The object is sent in both PATH and RESV messages.
	6.1.1. Relay-Message Method		6.1.1. Relay-Message Method
	The primary ingress relays the information for ingress protection of		The primary ingress relays the information for ingress protection of
	an LSP to the backup ingress via PATH messages. Once the LSP is		an LSP to the backup ingress via PATH messages. Once the LSP is
	created, the ingress of the LSP sends the backup ingress a PATH		created, the ingress of the LSP sends the backup ingress a PATH
	message with an INGRESS-PROTECTION object with Label-Routes		message with an INGRESS_PROTECTION object with Label-Routes
	subobject, which is populated with the next-hops and labels. This		subobject, which is populated with the next-hops and labels. This
	provides sufficient information for the backup ingress to create the		provides sufficient information for the backup ingress to create the
	appropriate forwarding state and backup LSP(s).		appropriate forwarding state and backup LSP(s).
	The ingress also sends the backup ingress all the other PATH messages		The ingress also sends the backup ingress all the other PATH messages
	for the LSP with an empty INGRESS-PROTECTION object. Thus, the		for the LSP with an empty INGRESS_PROTECTION object. Thus, the
	backup ingress has access to all the PATH messages needed for		backup ingress has access to all the PATH messages needed for
	modification to be sent to refresh control-plane state after a		modification to refresh control-plane state after a failure.
	failure.
	The advantages of this method include: 1) the primary LSP is		The advantages of this method include: 1) the primary LSP is
	independent of the backup ingress; 2) simple; 3) less configuration;		independent of the backup ingress; 2) simple; 3) less configuration;
	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
	skipping to change at page 12, line 20		skipping to change at page 10, line 42
	[ & ingress ] |		[ & ingress ] |
	* |		* |
	*****[ MP ]----|		*****[ MP ]----|
	Figure 2: Example Protected LSP with Proxy Ingress Node		Figure 2: Example Protected LSP with Proxy Ingress Node
	The backup ingress must know the merge points or next-hops and their		The backup ingress must know the merge points or next-hops and their
	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 a next hop node		cases. In the on-path case, the backup ingress is a next hop node
	after the ingress for the LSP. In the off-path, the backup ingress		after the ingress for the LSP. In the off-path, the backup ingress
	is not any next-hop node after the ingress for all associated sub-		is not any next-hop node after the ingress for all associated sub-
	LSPs.		LSPs.
	skipping to change at page 13, line 11		skipping to change at page 11, line 35
	|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 two or three pieces of		The primary ingress must be configured with two or three pieces of
	information for ingress protection.		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 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
	recording the proxy-ingress. If no proxy-ingress-id is specified,		recording the proxy-ingress. If no proxy-ingress-id is specified,
	then a local interface address that will not otherwise be included		then a local interface address that will not otherwise be included
	in the Record Route Object can be used. A similar technique is		in the Record Route Object can be used. A similar technique is
	used in [RFC4090 Sec 6.1.1].		used in [RFC4090 Sec 6.1.1].
	o Application Traffic Identifier: The primary ingress and backup		o Application Traffic Identifier: The primary ingress and backup
	ingress must both know what application traffic should be directed		ingress must both know what application traffic should be directed
	skipping to change at page 13, line 41		skipping to change at page 12, line 18
	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 off-path, then send the backup ingress a		2. If the backup ingress is off-path, then send it a PATH message
	PATH message with the content from the selected PATH message and		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 object contains the Traffic-Descriptor sub-object, the
	Descriptor sub-object, the Backup Ingress Address sub-object and		Backup Ingress Address sub-object and the Label-Routes sub-
	the Label-Routes sub-object. The flags is set to indicate		object. The flags is set to indicate whether a Backup P2MP LSP
	whether a Backup P2MP LSP is desired. If not yet allocated,		is desired. A second LSP-ID is allocated (if it is not allocated
	allocate a second LSP-ID to be used in the INGRESS-PROTECTION		yet) and used in the object. The Label-Routes sub-object
	object. The Label-Routes sub-object contains the next-hops of		contains the next-hops of the ingress and their labels.
	the ingress and their labels.
	3. For each of the other PATH messages, if the node to which the		3. For each of the other PATH messages, send the backup ingress a
	message is sent is not the backup ingress, then send the backup		PATH message with the content copied from the message and an
	ingress a PATH message with the content copied from the message		empty INGRESS_PROTECTION object, which is an object without any
	to the node and an empty INGRESS-PROTECTION object; else send the		Traffic-Descriptor sub-object.
	node the message with an empty INGRESS-PROTECTION object.
	6.2.2. Proxy-Ingress Method		6.2.2. Proxy-Ingress Method
	The primary ingress is responsible for starting the RSVP signaling		The primary ingress is responsible for starting the RSVP signaling
	for the proxy-ingress node. To do this, the following is done for		for the proxy-ingress node. To do this, the following is done for
	the RSVP PATH message.		the RSVP PATH message.
	1. Compute the EROs for the LSP as normal for the ingress.		1. Compute the EROs for the LSP as normal for the ingress.
	2. If the selected backup ingress node is not the first node on the		2. If the selected backup ingress node is not the first node on the
	path (for all sub-LSPs), then insert at the beginning of the ERO		path (for all sub-LSPs), then insert at the beginning of the ERO
	first the backup ingress node and then the ingress node.		first the backup ingress node and then the ingress node.
	3. In the PATH RRO, instead of recording the ingress node's address,		3. In the PATH RRO, instead of recording the ingress node's address,
	replace it with the Proxy-Ingress-Id.		replace it with the Proxy-Ingress-Id.
	4. Leave the HOP object populated as usual with information for the		4. Leave the HOP object populated as usual with information for the
	ingress-node.		ingress-node.
	5. Add the INGRESS-PROTECTION object to the PATH message. Allocate		5. Add the INGRESS_PROTECTION object to the PATH message. Allocate
	a second LSP-ID to be used in the INGRESS-PROTECTION object.		a second LSP-ID to be used in the INGRESS-PROTECTION object.
	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 or clear the flag		the Traffic-Descriptor sub-object. Set or clear the flag
	indicating that a Backup P2MP LSP is desired.		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.
	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
	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
	ingress 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. The LER		Ingress Address sub-object of the INGRESS_PROTECTION object. The LER
	as the backup ingress will assume full responsibility of the ingress		as the backup ingress will assume full responsibility of the ingress
	after the primary ingress fails. In addition, the LER determines		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.		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.
	The backup ingress SHOULD follow the control-options specified in the		The backup ingress SHOULD follow the control-options specified in the
	INGRESS-PROTECTION object and the flags and specifications in the		INGRESS_PROTECTION object and the flags and specifications in the
	FAST-REROUTE object. This applies to providing a P2MP backup if the		FAST-REROUTE object. This applies to providing a P2MP backup if the
	"P2MP backup" is set, a one-to-one backup if "one-to-one desired" is		"P2MP backup" is set, a one-to-one backup if "one-to-one desired" is
	set, facility backup if the "facility backup desired" is set, and		set, facility backup if the "facility backup desired" is set, and
	backup paths that support the desired bandwidth, and administrative-		backup paths that support the desired bandwidth, and administrative-
	colors that are requested.		colors that are requested.
	If multiple INGRESS-PROTECTION objects have been received via		If multiple non empty INGRESS_PROTECTION objects have been received
	multiple PATH messages for the same LSP, then the most recent one		via multiple PATH messages for the same LSP, then the most recent one
	that specified a Traffic-Descriptor sub-object MUST be the one used.		MUST be the one used.
	The backup ingress creates the appropriate forwarding state for the		The backup ingress creates the appropriate forwarding state for the
	backup LSP tunnel(s) to the merge point(s).		backup LSP tunnel(s) to the merge point(s).
	When the backup ingress sends a RESV message to the primary ingress,		When the backup ingress sends a RESV message to the primary ingress,
	it should add an INGRESS-PROTECTION object into the message. It		it should add an INGRESS_PROTECTION object into the message. It
	SHOULD set or clear the flags in the object to report "Ingress local		SHOULD set or clear the flags in the object to report "Ingress local
	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
	skipping to change at page 16, line 50		skipping to change at page 15, line 26
	occur, then the standard RSVP soft-state removal SHOULD occur. The		occur, then the standard RSVP soft-state removal SHOULD occur. The
	backup ingress SHALL remove the state for the PATH message from the		backup ingress SHALL remove the state for the PATH message from the
	primary ingress, and tear down the one-to-one backup LSPs for		primary ingress, and tear down the one-to-one backup LSPs for
	protecting the primary ingress if one-to-one backup is used or unbind		protecting the primary ingress if one-to-one backup is used or unbind
	the facility backup LSPs if facility backup is used.		the facility backup LSPs if facility backup is used.
	When the backup ingress receives a PATH message from the primary		When the backup ingress receives a PATH message from the primary
	ingress for locally protecting the primary ingress of a protected		ingress for locally protecting the primary ingress of a protected
	LSP, it checks to see if any critical information has been changed.		LSP, it checks to see if any critical information has been changed.
	If the next hops of the primary ingress are changed, the backup		If the next hops of the primary ingress are changed, the backup
	ingress SHALL update its backup LSP(s).		ingress SHALL update its backup LSP(s) accordingly.
	6.3.1.1. Relay-Message Method		6.3.1.1. Relay-Message Method
	When the backup ingress receives a PATH message with the INGRESS-		When the backup ingress receives a PATH message with an non empty
	PROTECTION object, it examines the object to learn what traffic		INGRESS_PROTECTION object, it examines the object to learn what
	associated with the LSP. It determines the next-hops to be merged to		traffic associated with the LSP. It determines the next-hops to be
	by examining the Label-Routes sub-object in the object. If the		merged to by examining the Label-Routes sub-object in the object.
	Traffic-Descriptor sub-object isn't included, this object is
	considered "empty".
	The backup ingress stores the PATH message received from the primary		The backup ingress stores the PATH message received from the primary
	ingress, but does NOT forward it.		ingress, but does NOT forward it.
	The backup ingress MUST respond with a RESV to the PATH message		The backup ingress MUST respond with a RESV to the PATH message
	received from the primary ingress. If the INGRESS-PROTECTION object		received from the primary ingress. If the INGRESS_PROTECTION object
	is not "empty", the backup ingress SHALL send the RESV message with		is not "empty", the backup ingress SHALL send the RESV message with
	the state indicating protection is available after the backup LSP(s)		the state indicating protection is available after the backup LSP(s)
	are successfully established.		are successfully established.
	6.3.1.2. Proxy-Ingress Method		6.3.1.2. Proxy-Ingress Method
	The backup ingress determines the next-hops to be merged to by		The backup ingress determines the next-hops to be merged to by
	collecting the set of the pair of (IPv4/IPv6 sub-object, Label sub-		collecting the set of the pair of (IPv4/IPv6 sub-object, Label sub-
	object) from the Record Route Object of each RESV that are closest to		object) from the Record Route Object of each RESV that are closest to
	the top and not the Ingress router; this should be the second to the		the top and not the Ingress router; this should be the second to the
	top pair. If a Label-Routes sub-object is included in the INGRESS-		top pair. If a Label-Routes sub-object is included in the
	PROTECTION object, the included IPv4/IPv6 sub-objects are used to		INGRESS_PROTECTION object, the included IPv4/IPv6 sub-objects are
	filter the set down to the specific next-hops where protection is		used to filter the set down to the specific next-hops where
	desired. A RESV message must have been received before the Backup		protection is desired. A RESV message must have been received before
	Ingress can create or select the appropriate backup LSP.		the Backup Ingress can create or select the appropriate backup LSP.
	When the backup ingress receives a PATH message with the INGRESS-		When the backup ingress receives a PATH message with the
	PROTECTION object, the backup ingress examines the object to learn		INGRESS_PROTECTION object, the backup ingress examines the object to
	what traffic associated with the LSP. The backup ingress forwards		learn what traffic associated with the LSP. The backup ingress
	the PATH message to the ingress node with the normal RSVP changes.		forwards the PATH message to the ingress node with the normal RSVP
			changes.
	When the backup ingress receives a RESV message with the INGRESS-		When the backup ingress receives a RESV message with the
	PROTECTION object, the backup ingress records an IMPLICIT-NULL label		INGRESS_PROTECTION object, the backup ingress records an IMPLICIT-
	in the RRO. Then the backup ingress forwards the RESV message to the		NULL label in the RRO. Then the backup ingress forwards the RESV
	ingress node, which is acting for the proxy ingress.		message to the ingress node, which is acting for the proxy ingress.
	6.3.2. Backup Ingress Behavior in On-path Case		6.3.2. Backup Ingress Behavior in On-path Case
	An LER as the backup ingress determines that it is on-path if one of		An LER as the backup ingress determines that it is on-path if one of
	its addresses is a next hop of the primary ingress and the primary		its addresses is a next hop of the primary ingress (and the primary
	ingress is not its next hop via checking the PATH message with the		ingress is not its next hop via checking the PATH message with the
	INGRESS_PROTECTION object received from the primary ingress. The LER		INGRESS_PROTECTION object received from the primary ingress for
	on-path sends the corresponding PATH messages without any		Proxy-Ingress Method). The LER on-path sends the corresponding PATH
	INGRESS_PROTECTION object to its next hops. It creates a number of		messages without any INGRESS_PROTECTION object to its next hops. It
	backup P2P LSPs or a backup P2MP LSP from itself to the other next		creates a number of backup P2P LSPs or a backup P2MP LSP from itself
	hops (i.e., the next hops other than the backup ingress) of the		to the other next hops (i.e., the next hops other than the backup
	primary ingress. The other next hops are from the Label-Routes sub		ingress) of the primary ingress. The other next hops are from the
	object.		Label-Routes sub object.
	It also creates a forwarding entry, which sends/multicasts the		It also creates a forwarding entry, which sends/multicasts the
	traffic from the source to the next hops of the backup ingress along		traffic from the source to the next hops of the backup ingress along
	the protected LSP when the primary ingress fails. The traffic is		the protected LSP when the primary ingress fails. The traffic is
	described by the Traffic-Descriptor.		described by the Traffic-Descriptor.
	After the forwarding entry is created, all the backup P2P LSPs or the		After the forwarding entry is created, all the backup P2P LSPs or the
	backup P2MP LSP is up and associated with the protected LSP, the		backup P2MP LSP is up and associated with the protected LSP, the
	backup ingress sends the primary ingress the RESV message with the		backup ingress sends the primary ingress the RESV message with the
	INGRESS_PROTECTION object containing the state of the local		INGRESS_PROTECTION object containing the state of the local
	skipping to change at page 18, line 34		skipping to change at page 17, line 9
	backup P2MP LSP transmitting the traffic to the other next hops of		backup P2MP LSP transmitting the traffic to the other next hops of
	the primary ingress, where the traffic is merged into protected LSP.		the primary ingress, where the traffic is merged into protected LSP.
	During the local repair, the backup ingress continues to send the		During the local repair, the backup ingress continues to send the
	PATH messages to its next hops as before, keeps the PATH message with		PATH messages to its next hops as before, 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		the RESV message with the INGRESS_PROTECTION object to be sent to the
	primary ingress. It sets the "local protection in use" flag in the		primary ingress. It sets the "local protection in use" flag in the
	RESV message.		RESV message.
	6.3.3. Failure Detection		6.3.3. Failure Detection and Refresh PATH Messages
	As described in [RFC4090], it is necessary to refresh the PATH		As described in [RFC4090], it is necessary to refresh the PATH
	messages via the backup LSP(s). The Backup Ingress MUST wait to		messages via the backup LSP(s). The Backup Ingress MUST wait to
	refresh the backup PATH messages until it can accurately detect that		refresh the PATH messages until it can accurately detect that the
	the ingress node has failed. An example of such an accurate		ingress node has failed. An example of such an accurate detection
	detection would be that the IGP has no bi-directional links to the		would be that the IGP has no bi-directional links to the ingress node
	ingress node and the last change was long enough in the past that		and the last change was long enough in the past that changes should
	changes should have been received (i.e., an IGP network convergence		have been received (i.e., an IGP network convergence time or
	time or approximately 2-3 seconds) or a BFD session to the primary		approximately 2-3 seconds) or a BFD session to the primary ingress'
	ingress' loopback address has failed and stayed failed after the		loopback address has failed and stayed failed after the network has
	network has reconverged.		reconverged.
	As described in [RFC4090 Section 6.4.3], the backup ingress, acting		As described in [RFC4090 Section 6.4.3], the backup ingress, acting
	as PLR, SHOULD modify - including removing any INGRESS-PROTECTION and		as PLR, SHOULD modify and send any saved PATH messages associated
	FAST-REROUTE objects - and send any saved PATH messages associated		with the primary LSP to the corresponding next hops through backup
	with the primary LSP.		LSP(s). Any PATH message sent will not contain any
			INGRESS_PROTECTION object. The RSVP_HOP object in the message
			contains an IP source address belonging to the backup ingress. The
			sender template object has the backup ingress address as its tunnel
			sender address.
	6.4. Revertive Behavior		6.4. Revertive Behavior
	Upon a failure event in the (primary) ingress of a protected LSP, the		Upon a failure event in the (primary) ingress of a protected LSP, the
	protected LSP is locally repaired by the backup ingress. There are a		protected LSP is locally repaired by the backup ingress. There are a
	couple of basic strategies for restoring the LSP to a full working		couple of basic strategies for restoring the LSP to a full working
	path.		path.
	- Revert to Primary Ingress: When the primary ingress is restored,		- Revert to Primary Ingress: When the primary ingress is restored,
	it re-signals each of the LSPs that start from the primary		it re-signals each of the LSPs that start from the primary
	skipping to change at page 19, line 33		skipping to change at page 18, line 16
	If "Revert to Primary Ingress" is desired for a protected LSP, the		If "Revert to Primary Ingress" is desired for a protected LSP, the
	(primary) ingress of the LSP re-signals the LSP that starts from the		(primary) ingress of the LSP re-signals the LSP that starts from the
	primary ingress after the primary ingress restores. When the LSP is		primary ingress after the primary ingress restores. When the LSP is
	re-signaled successfully, the traffic is switched back to the primary		re-signaled successfully, the traffic is switched back to the primary
	ingress from the backup ingress and redirected into the LSP starting		ingress from the backup ingress and redirected into the LSP starting
	from the primary ingress.		from the primary ingress.
	If the ingress can resignal the PATH messages for the LSP, then the		If the ingress can resignal the PATH messages for the LSP, then the
	ingress can specify the "Revert to Ingress" control-option in the		ingress can specify the "Revert to Ingress" control-option in the
	INGRESS-PROTECTION object. Doing so may cause a duplication of		INGRESS_PROTECTION object. Doing so may cause a duplication of
	traffic while the Ingress starts sending traffic again before the		traffic while the Ingress starts sending traffic again before the
	Backup Ingress stops; the alternative is to drop traffic for a short		Backup Ingress stops; the alternative is to drop traffic for a short
	period of time.		period of time.
	Additionally, the Backup Ingress can set the "Revert To Ingress"		Additionally, the Backup Ingress can set the "Revert To Ingress"
	control-option as a request for the Ingress to take over.		control-option as a request for the Ingress to take over.
	6.4.2. Global Repair by Backup Ingress		6.4.2. Global Repair by Backup Ingress
	When the backup ingress has determined that the primary ingress of		When the backup ingress has determined that the primary ingress of
	the protected LSP has failed (e.g., via the IGP), it can compute a		the protected LSP has failed (e.g., via the IGP), it can compute a
	new path and signal a new LSP along the new path so that it no longer		new path and signal a new LSP along the new path so that it no longer
	relies upon local repair. To do this, the backup ingress uses the		relies upon local repair. To do this, the backup ingress uses the
	same tunnel sender address in the Sender Template Object and uses the		same tunnel sender address in the Sender Template Object and uses the
	previously allocated second LSP-ID in the INGRESS-PROTECTION object		previously allocated second LSP-ID in the INGRESS_PROTECTION object
	of the PATH message as the LSP-ID of the new LSP. This allows the		of the PATH message as the LSP-ID of the new LSP. This allows the
	new LSP to share resources with the old LSP. In addition, if the		new LSP to share resources with the old LSP. In addition, if the
	Ingress recovers, the Backup Ingress SHOULD send it RESVs with the		Ingress recovers, the Backup Ingress SHOULD send it RESVs with the
	INGRESS-PROTECTION object where either the "Force to Backup" or		INGRESS_PROTECTION object where the "Revert to Ingress" is specified.
	"Revert to Ingress" is specified. The Secondary LSP ID should be the		The Secondary LSP ID should be the unused LSP ID - while the LSP ID
	unused LSP ID - while the LSP ID signaled in the RESV will be that		signaled in the RESV will be that currently active. The Ingress can
	currently active. The Ingress can learn from the RESVs what to		learn from the RESVs what to signal. Even if the Ingress does not
	signal. Even if the Ingress does not take over, the RESVs notify it		take over, the RESVs notify it that the particular LSP IDs are in
	that the particular LSP IDs are in use. The Backup Ingress can		use. The Backup Ingress can reoptimize the new LSP as necessary
	reoptimize the new LSP as necessary until the Ingress recovers.		until the Ingress recovers. Alternately, the Backup Ingress can
	Alternately, the Backup Ingress can create a new LSP with no		create a new LSP with no bandwidth reservation that duplicates the
	bandwidth reservation that duplicates the path(s) of the protected		path(s) of the protected LSP, move traffic to the new LSP, delete the
	LSP, move traffic to the new LSP, delete the protected LSP, and then		protected LSP, and then resignal the new LSP with bandwidth.
	resignal the new LSP with bandwidth.
	7. Security Considerations		7. Security Considerations
	In principle this document does not introduce new security issues.		In principle this document does not introduce new security issues.
	The security considerations pertaining to RFC 4090, RFC 4875 and		The security considerations pertaining to RFC 4090, RFC 4875 and
	other RSVP protocols remain relevant.		other RSVP protocols remain relevant.
	8. IANA Considerations		8. IANA Considerations
	TBD		TBD
	skipping to change at page 21, line 28		skipping to change at page 20, line 9
	Markus Jork		Markus Jork
	Juniper Networks		Juniper Networks
	10 Technology Park Drive		10 Technology Park Drive
	Westford, MA 01886		Westford, MA 01886
	USA		USA
	Email: mjork@juniper.net		Email: mjork@juniper.net
	10. Acknowledgement		10. Acknowledgement
	The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric		The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric
	Osborne, Ross Callon, Loa Andersson, Michael Yue, Olufemi Komolafe,		Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue,
	Rob Rennison, Neil Harrison, Kannan Sampath, and Ronhazli Adam for		Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, and
	their valuable comments and suggestions on this draft.		Ronhazli Adam for their valuable comments and suggestions on this
			draft.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,		[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
	October 1994.		October 1994.
	[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.
	skipping to change at page 23, line 4		skipping to change at page 21, line 26
	[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.		[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
	McManus, "Requirements for Traffic Engineering Over MPLS",		McManus, "Requirements for Traffic Engineering Over MPLS",
	RFC 2702, September 1999.		RFC 2702, September 1999.
	[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,		[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
	Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack		Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
	Encoding", RFC 3032, January 2001.		Encoding", RFC 3032, January 2001.
	Appendix A. Authors' Addresses		Appendix A. Authors' Addresses
	Huaimo Chen		Huaimo Chen
	Huawei Technologies		Huawei Technologies
	Boston, MA		Boston, MA
	USA		USA
	Email: huaimo.chen@huawei.com		Email: huaimo.chen@huawei.com
			Raveendra Torvi
			Juniper Networks
			10 Technology Park Drive
			Westford, MA 01886
			USA
			Email: rtorvi@juniper.net
	Ning So		Ning So
	Tata Communications		Tata Communications
	2613 Fairbourne Cir.		2613 Fairbourne Cir.
	Plano, TX 75082		Plano, TX 75082
	USA		USA
	Email: ningso01@gmail.com		Email: ningso01@gmail.com
	Autumn Liu		Autumn Liu
	Ericsson		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: autumn.liu@ericsson.com		Email: autumn.liu@ericsson.com
	Raveendra Torvi
	Juniper Networks
	10 Technology Park Drive
	Westford, MA 01886
	USA
	Email: rtorvi@juniper.net
	Alia Atlas		Alia Atlas
	Juniper Networks		Juniper Networks
	10 Technology Park Drive		10 Technology Park Drive
	Westford, MA 01886		Westford, MA 01886
	USA		USA
	Email: akatlas@juniper.net		Email: akatlas@juniper.net
	Yimin Shen		Yimin Shen
	Juniper Networks		Juniper Networks
	10 Technology Park Drive		10 Technology Park Drive
	Westford, MA 01886		Westford, MA 01886
	USA		USA
	Email: yshen@juniper.net		Email: yshen@juniper.net
			Tarek Saad
			Cisco Systems
			Email: tsaad@cisco.com
	Fengman Xu		Fengman Xu
	Verizon		Verizon
	2400 N. Glenville Dr		2400 N. Glenville Dr
	Richardson, TX 75082		Richardson, TX 75082
	USA		USA
	Email: fengman.xu@verizon.com		Email: fengman.xu@verizon.com
	Mehmet Toy		Mehmet Toy
	Comcast		Comcast
	1800 Bishops Gate Blvd.		1800 Bishops Gate Blvd.
End of changes. 76 change blocks.
	273 lines changed or deleted		207 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/