draft-ietf-ccamp-gr-description-04.txt		rfc5495.txt
	Network Working Group Dan Li (Huawei)
	Internet Draft Jianhua Gao (Huawei)
	Arun Satyanarayana (Cisco)
	Snigdho C. Bardalai (Fujitsu)
	Intended Status: Informational
	Expires: July 21, 2009 January 21, 2009
	Description of the RSVP-TE Graceful Restart Procedures		Network Working Group D. Li
			Request for Comments: 5495 J. Gao
	draft-ietf-ccamp-gr-description-04.txt		Category: Informational Huawei
			A. Satyanarayana
			Cisco
			S. Bardalai
			Fujitsu
			Description of the
			Resource Reservation Protocol - Traffic-Engineered (RSVP-TE)
			Graceful Restart Procedures
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with		This memo provides information for the Internet community. It does
	the provisions of BCP 78 and BCP 79.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	Internet-Drafts are working documents of the Internet Engineering		Copyright Notice
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Copyright (c) 2009 IETF Trust and the persons identified as the
	months and may be updated, replaced, or obsoleted by other documents		document authors. All rights reserved.
	at any time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This document is subject to BCP 78 and the IETF Trust's Legal
	http://www.ietf.org/ietf/1id-abstracts.txt.		Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	The list of Internet-Draft Shadow Directories can be accessed at		This document may contain material from IETF Documents or IETF
	http://www.ietf.org/shadow.html.		Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Abstract		Abstract
	The Hello message for the Resource Reservation Protocol (RSVP) has		The Hello message for the Resource Reservation Protocol (RSVP) has
	been defined to establish and maintain basic signaling node		been defined to establish and maintain basic signaling node
	adjacencies for Label Switching Routers (LSRs) participating in a		adjacencies for Label Switching Routers (LSRs) participating in a
	Multiprotocol Label Switching (MPLS) traffic engineered (TE)		Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network.
	network. The Hello message has been extended for use in Generalized		The Hello message has been extended for use in Generalized MPLS
	MPLS (GMPLS) network for state recovery of control channel or nodal		(GMPLS) networks for state recovery of control channel or nodal
	faults.		faults.
	GMPLS protocol definitions for RSVP also allow a restarting node to		The GMPLS protocol definitions for RSVP also allow a restarting node
	learn the label that it previously allocated for use on a Label		to learn which label it previously allocated for use on a Label
	Switching Path (LSP).		Switched Path (LSP).
	Further RSVP protocol extensions have been defined to enable a		Further RSVP protocol extensions have been defined to enable a
	restarting node to recover full control plane state by exchanging		restarting node to recover full control plane state by exchanging
	RSVP messages with its upstream and downstream neighbors.		RSVP messages with its upstream and downstream neighbors.
	This document provides an informational clarification of the		This document provides an informational clarification of the control
	control plane procedures for a GMPLS network when there are		plane procedures for a GMPLS network when there are multiple node
	multiple node failures, and describes how full control plane state		failures, and describes how full control plane state can be recovered
	can be recovered in different scenarios where the order in which		in different scenarios where the order in which the nodes restart is
	the nodes restart is different.		different.
	This document does not define any new processes or procedures. All		This document does not define any new processes or procedures. All
	protocol mechanisms are already defined in the referenced documents.		protocol mechanisms are already defined in the referenced documents.
	Table of Contents		Table of Contents
	1. Introduction.................................................3		1. Introduction ....................................................3
	2. Existing Procedures for Single Node Restart..................4		2. Existing Procedures for Single Node Restart .....................4
	2.1. Procedures Defined in [RFC3473]............................4		2.1. Procedures Defined in RFC 3473 .............................4
	2.2. Procedures Defined in [RFC5063]............................5		2.2. Procedures Defined in RFC 5063 .............................5
	3. Multiple Node Restart Scenarios..............................5		3. Multiple Node Restart Scenarios .................................6
	4. RSVP State...................................................7		4. RSVP State ......................................................7
	5. Procedures for Multiple Node Restart.........................7		5. Procedures for Multiple Node Restart ............................7
	5.1. Procedures for the Normal Node.............................7		5.1. Procedures for the Normal Node .............................8
	5.2. Procedures for the Restarting Node.........................7		5.2. Procedures for the Restarting Node .........................8
	5.2.1. Procedures for Scenario 1................................8		5.2.1. Procedures for Scenario 1 ...........................8
	5.2.2. Procedures for Scenario 2................................9		5.2.2. Procedures for Scenario 2 ...........................9
	5.2.3. Procedures for Scenario 3...............................10		5.2.3. Procedures for Scenario 3 ..........................11
	5.2.4. Procedures for Scenario 4...............................11		5.2.4. Procedures for Scenario 4 ..........................12
	5.2.5. Procedures for Scenario 5...............................12		5.2.5. Procedures for Scenario 5 ..........................12
	5.3. Consideration of Re-Use of Data Plane Resources...........12		5.3. Consideration of the Reuse of Data Plane Resources ........12
	5.4. Consideration of Management Plane Intervention............12		5.4. Consideration of Management Plane Intervention ............13
	6. Clarification of Restarting Node Procedure..................13		6. Clarification of Restarting Node Procedure .....................13
	7. Security Considerations.....................................14		7. Security Considerations ........................................15
	8. IANA Considerations.........................................16		8. Acknowledgments ................................................16
	9. Acknowledgments.............................................16		9. References .....................................................17
	10. References.................................................16		9.1. Normative References ......................................17
	10.1. Normative References.....................................16		9.2. Informative References ....................................17
	10.2. Informative References...................................16
	11. Author's Addresses.........................................17
	12. Full Copyright Statement...................................18
	13. Intellectual Property Statement............................18
	1. Introduction		1. Introduction
	The Hello message for the Resource Reservation Protocol (RSVP) has		The Hello message for the Resource Reservation Protocol (RSVP) has
	been defined to establish and maintain basic signaling node		been defined to establish and maintain basic signaling node
	adjacencies for Label Switching Routers (LSRs) participating in a		adjacencies for Label Switching Routers (LSRs) participating in a
	Multiprotocol Label Switching (MPLS) traffic engineered (TE)		Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network
	network [RFC3209]. The Hello message has been extended for use in		[RFC3209]. The Hello message has been extended for use in
	Generalized MPLS (GMPLS) network for state recovery of control		Generalized MPLS (GMPLS) networks for state recovery of control
	channel or nodal faults through the exchange of the Restart		channel or nodal faults through the exchange of the Restart_Cap
	Capabilities object [RFC3473].		Object [RFC3473].
	GMPLS protocol definitions for RSVP [RFC3473] also allow a		The GMPLS protocol definitions for RSVP [RFC3473] also allow a
	restarting node to learn the label that it previously allocated for		restarting node to learn which label it previously allocated for use
	use on a Label Switching Path (LSP) through the RECOVERY_LABEL		on a Label Switched Path (LSP) through the Recovery_Label Object
	object carried on a Path message sent to a restarting node from its		carried on a Path message sent to a restarting node from its upstream
	upstream neighbor.		neighbor.
	Further RSVP protocol extensions have been defined [RFC5063] to		Further RSVP protocol extensions have been defined [RFC5063] to
	perform graceful restart and to enable a restarting node to recover		perform graceful restart and to enable a restarting node to recover
	full control plane state by exchanging RSVP messages with its		full control plane state by exchanging RSVP messages with its
	upstream and downstream neighbors. State previously transmitted to		upstream and downstream neighbors. State previously transmitted to
	the upstream neighbor (principally the downstream label) is		the upstream neighbor (principally, the downstream label) is
	recovered from the upstream neighbor on a Path message (using the		recovered from the upstream neighbor on a Path message (using the
	RECOVERY_LABEL object as described in [RFC3473]). State previously		Recovery_Label Object as described in [RFC3473]). State previously
	transmitted to the downstream neighbor (including the upstream		transmitted to the downstream neighbor (including the upstream label,
	label, interface identifiers, and the explicit route) is recovered		interface identifiers, and the explicit route) is recovered from the
	from the downstream neighbor using a RecoveryPath message.		downstream neighbor using a RecoveryPath message.
	[RFC5063] also extends the Hello message to exchange information		[RFC5063] also extends the Hello message to exchange information
	about the ability to support the RecoveryPath message.		about the ability to support the RecoveryPath message.
	The examples and procedures in [RFC3473] and [RFC5063] focus on the		The examples and procedures in [RFC3473] and [RFC5063] focus on the
	description of a single node restart when adjacent network nodes		description of a single node restart when adjacent network nodes are
	are operative. Although the procedures are equally applicable to		operative. Although the procedures are equally applicable to multi-
	multi-node restarts, no detailed explanation is provided.		node restarts, no detailed explanation is provided for such a case.
	This document provides an informational clarification of the		This document provides an informational clarification of the control
	control plane procedures for a GMPLS network when there are		plane procedures for a GMPLS network when there are multiple node
	multiple node failures, and describes how full control plane state		failures, and describes how full control plane state can be recovered
	can be recovered in different scenarios where the order in which		in different scenarios where the order in which the nodes restart is
	the nodes restart is different.		different.
	This document does not define any new processes or procedures. All		This document does not define any new processes or procedures. All
	protocol mechanisms already defined in [RFC3473] and [RFC5063] are		protocol mechanisms already defined in [RFC3473] and [RFC5063] are
	definitive.		definitive.
	2. Existing Procedures for Single Node Restart		2. Existing Procedures for Single Node Restart
	This section documents for information the existing procedures		This section documents for information the existing procedures
	defined in [RFC3473] and [RFC5063]. Those documents are definitive,		defined in [RFC3473] and [RFC5063]. Those documents are definitive,
	and the description here is non-normative. It is provided for		and the description here is non-normative. It is provided for
	informational clarification only.		informational clarification only.
	2.1. Procedures Defined in [RFC3473]		2.1. Procedures Defined in RFC 3473
	In the case of nodal faults, the procedures for the restarting node		In the case of nodal faults, the procedures for the restarting node
	and the procedures for the neighbor of a restarting node are		and the procedures for the neighbor of a restarting node are applied
	applied to the corresponding nodes. These procedures described in		to the corresponding nodes. These procedures, described in
	[RFC3473] are summarized as follows:		[RFC3473], are summarized as follows:
	For the Restarting Node:		For the Restarting Node:
	1) Tells its neighbors that state recovery is supported using the		1) Tells its neighbors that state recovery is supported using the
	Hello message;		Hello message.
	2) Recover its RSVP state with the help of a Path message received		2) Recovers its RSVP state with the help of a Path message, received
	from its upstream neighbor carrying the RECOVERY_LABEL object;		from its upstream neighbor, that carries the Recovery_Label
			Object.
	3) For bidirectional LSPs, the UPSTREAM_LABEL object on the received		3) For bidirectional LSPs, uses the Upstream_Label Object on the
	Path message is used to recover the corresponding RSVP state;		received Path message to recover the corresponding RSVP state.
	4) If the corresponding forwarding state in the data plane does not		4) If the corresponding forwarding state in the data plane does not
	exist, the node treats this as a setup for a new LSP. If the		exist, the node treats this as a setup for a new LSP. If the
	forwarding state in the data plane exists, the forwarding state is		forwarding state in the data plane does exist, the forwarding
	bound to the LSP associated with the message, and related forwarding		state is bound to the LSP associated with the message, and the
	state should be considered as valid and refreshed. In addition, if		related forwarding state should be considered as valid and
	the node is not the tail-end of the LSP, the incoming label on the		refreshed. In addition, if the node is not the tail-end of the
	downstream interface is retrieved from the forwarding state on the		LSP, the incoming label on the downstream interface is retrieved
	restarting node and set in the UPSTREAM_LABEL object in the Path		from the forwarding state on the restarting node and set in the
	message sent to the downstream neighbor.		Upstream_Label Object in the Path message sent to the downstream
			neighbor.
	For the Neighbor of a restarting node:		For the Neighbor of a Restarting Node:
	1) Sends a Path message with RECOVERY_LABEL object containing a label		1) Sends a Path message with the Recovery_Label Object containing a
	value corresponding to the label value received in the most recently		label value corresponding to the label value received in the most
	received corresponding Resv message;		recently received corresponding Resv message.
	2) Resumes refreshing Path state with the restarting node;		2) Resumes refreshing Path state with the restarting node.
	3) Resumes refreshing Resv state with the restarting node.		3) Resumes refreshing Resv state with the restarting node.
	2.2. Procedures Defined in [RFC5063]		2.2. Procedures Defined in RFC 5063
	A new message is introduced in [RFC5063] called the RecoveryPath		A new message is introduced in [RFC5063] called the RecoveryPath
	message. The message is sent by the downstream neighbor of a		message. This message is sent by the downstream neighbor of a
	restarting node to convey the contents of the last received Path		restarting node to convey the contents of the last received Path
	message back to the restarting node.		message back to the restarting node.
	The restarting node will receive the Path message with the		The restarting node will receive the Path message with the
	RECOVERY_LABEL object from its upstream neighbor, and/or the		Recovery_Label Object from its upstream neighbor and/or the
	RecoveryPath message from its downstream neighbor. The full RSVP		RecoveryPath message from its downstream neighbor. The full RSVP
	state of the restarting node can be recovered from these two		state of the restarting node can be recovered from these two
	messages.		messages.
	The following state can be recovered from the received Path message:		The following state can be recovered from the received Path message:
	o Upstream data interface (from RSVP_HOP object)		o Upstream data interface (from RSVP_Hop Object)
	o Label on the upstream data interface (from RECOVERY_LABEL object)		o Label on the upstream data interface (from Recovery_Label Object)
	o Upstream label for bidirectional LSP (from UPSTREAM_LABEL object)		o Upstream label for bidirectional LSP (from Upstream_Label Object)
	The following state can be recovered from the received RecoveryPath		The following state can be recovered from the received RecoveryPath
	message:		message:
	o Downstream data interface (from RSVP_HOP object)		o Downstream data interface (from RSVP_Hop Object)
	o Label on the downstream data interface (from RECOVERY_LABEL object)
	o Upstream direction label for bidirectional LSP (from		o Label on the downstream data interface (from Recovery_Label Object)
	UPSTREAM_LABEL object)		o Upstream direction label for bidirectional LSP (from Upstream_Label
			Object)
	The other objects also can be recovered either from the regular		The other objects originally exchanged on Path and Resv messages can
	Path and Resv messages, or from the RecoveryPath message.		be recovered from the regular Path and Resv refresh messages, or from
			the RecoveryPath.
	3. Multiple Node Restart Scenarios		3. Multiple Node Restart Scenarios
	We define the following terms for the different node types:		We define the following terms for the different node types:
	Restarting - The node has restarted; communication with its		Restarting - The node has restarted. Communication with its neighbor
	neighbor nodes is restored, its RSVP state is under recovery.		nodes is restored, and its RSVP state is under recovery.
	Delayed Restarting - The node has restarted, but the communication		Delayed Restarting - The node has restarted, but the communication
	with a neighbor node is interrupted (for example, the neighbor node		with a neighbor node is interrupted (for example, the neighbor
	needs to restart).		node needs to restart).
	Normal - The normal node is the fully operational neighbor of a		Normal - The normal node is the fully operational neighbor of a
	restarting or delayed restarting node.		restarting or delayed restarting node.
	There are five scenarios for multi-node restart. We will focus on		There are five scenarios for multi-node restart. We will focus on
	the different positions of a restarting node. As shown in Figure 1,		the different positions of a restarting node. As shown in Figure 1,
	an LSP starts from Node A, traverses Nodes B and C, and ends at		an LSP starts from Node A, traverses Nodes B and C, and ends at Node
	Node D.		D.
	+-----+ Path +-----+ Path +-----+ Path +-----+		+-----+ Path +-----+ Path +-----+ Path +-----+
	| PSB |------->| PSB |------->| PSB |------->| PSB |		| PSB |------->| PSB |------->| PSB |------->| PSB |
	| | | | | | | |		| | | | | | | |
	| RSB |<-------| RSB |<-------| RSB |<-------| RSB |		| RSB |<-------| RSB |<-------| RSB |<-------| RSB |
	+-----+ Resv +-----+ Resv +-----+ Resv +-----+		+-----+ Resv +-----+ Resv +-----+ Resv +-----+
	Node A Node B Node C Node D		Node A Node B Node C Node D
	Figure 1 Two neighbor nodes restart
	1) A Restarting node with downstream Delayed Restarting node. For		Figure 1: Two Neighbor Nodes Restart
	example, in Figure 1, Nodes A and D are Normal nodes, Node B is a
	Restarting node, and Node C is a Delayed Restarting node.
	2) A Restarting node with upstream Delayed Restarting node. For		1) A restarting node with downstream delayed restarting node. For
	example, in Figure 1, Nodes A and D are Normal nodes, Node B is a		example, in Figure 1, Nodes A and D are normal nodes, Node B is a
	Delayed Restarting node, and Node C is a Restarting node.		restarting node, and Node C is a delayed restarting node.
	3) A Restarting node with downstream and upstream Delayed Restarting		2) A restarting node with upstream delayed restarting node. For
	nodes. For example, in Figure 1, Node A is a Normal node, Nodes B and		example, in Figure 1, Nodes A and D are normal nodes, Node B is a
	D are Delayed Restarting nodes, and Node C is a Restarting node.		delayed restarting node, and Node C is a restarting node.
	4) A Restarting Ingress node with downstream Delayed Restarting node.		3) A restarting node with downstream and upstream delayed restarting
	For example, in Figure 1, Node A is a Restarting node, and Node B is		nodes. For example, in Figure 1, Node A is a normal node, Nodes B
	a Delayed Restarting node. Nodes C and D are Normal nodes.		and D are delayed restarting nodes, and Node C is a restarting
			node.
	5) A Restarting Egress node with upstream Delayed Restarting node.		4) A restarting ingress node with downstream delayed restarting node.
	For example, in Figure 1, Nodes A and B are Normal nodes, Node C is a		For example, in Figure 1, Node A is a restarting node and Node B
	Delayed Restarting node, and Node D is a Restarting node.		is a delayed restarting node. Nodes C and D are normal nodes.
			5) A restarting egress node with upstream delayed restarting node.
			For example, in Figure 1, Nodes A and B are normal nodes, Node C
			is a delayed restarting node, and Node D is a restarting node.
	If the communication between two nodes is interrupted, the upstream		If the communication between two nodes is interrupted, the upstream
	node may think the downstream node is a Delayed Restarting node, or		node may think the downstream node is a delayed restarting node, or
	vice versa.		vice versa.
	Note that if multiple nodes which are not neighbors are restarted,		Note that if multiple nodes that are not neighbors are restarted, the
	the restart Procedures could be applied as multiple separated		restart procedures could be applied as multiple separated restart
	restart procedures which are exactly the same as the procedures		procedures that are exactly the same as the procedures described in
	described in [RFC3473] and [RFC5063]. Therefore, these scenarios		[RFC3473] and [RFC5063]. Therefore, these scenarios are not
	are not described in this document. For example, in Figure 1, Node		described in this document. For example, in Figure 1, Node A and
	A and Node C are normal nodes, and Node B and Node D are restarting		Node C are normal nodes, and Node B and Node D are restarting nodes;
	nodes, so Node B could be restarted through Node A and Node C,		therefore, Node B could be restarted through Node A and Node C, while
	meanwhile, Node D could be restarted through Node C separately.		Node D could be restarted through Node C separately.
	4. RSVP State		4. RSVP State
	For each scenario, the RSVP state needs to be recovered at the		For each scenario, the RSVP state that needs to be recovered at the
	restarting nodes are Path State Block (PSB) and Resv State Block		restarting nodes are the Path State Block (PSB) and Resv State Block
	(RSB), which are created when the node receives the corresponding		(RSB), which are created when the node receives the corresponding
	Path message and Resv message.		Path message and Resv message.
	According to [RFC2209], how to construct the PSB and RSB is really		According to [RFC2209], how to construct the PSB and RSB is really an
	an implementation issue. In fact, there is no requirement to		implementation issue. In fact, there is no requirement to maintain
	maintain separate PSB and RSB data structures. And in GMPLS, there		separate PSB and RSB data structures. In GMPLS, there is a much
	is a much closer tie between Path and Resv state so it is possible		closer tie between Path and Resv state so it is possible to combine
	to combine the information into a single state block (the LSP state		the information into a single state block (the LSP state block). On
	block). On the other hand, if point to multi-point is supported, it		the other hand, if point-to-multipoint is supported, it may be
	may be convenient to maintain separate upstream and downstream		convenient to maintain separate upstream and downstream state. Note
	state. Note that the PSB and RSB are not upstream and downstream		that the PSB and RSB are not upstream and downstream state since the
	state since the PSB is responsible for receiving a Path from		PSB is responsible for receiving a Path from upstream and sending a
	upstream and sending a Path to downstream.		Path to downstream.
	Regardless of how the RSVP state is implemented, on recovery there		Regardless of how the RSVP state is implemented, on recovery there
	are two logical pieces of state to be recovered and these		are two logical pieces of state to be recovered and these correspond
	correspond to the PSB and RSB.		to the PSB and RSB.
	5. Procedures for Multiple Node Restart		5. Procedures for Multiple Node Restart
	In this document, all the nodes are assumed to have the graceful		In this document, all the nodes are assumed to have the graceful
	restart capabilities which are described in [RFC3473] and [RFC5063].		restart capabilities that are described in [RFC3473] and [RFC5063].
	5.1. Procedures for the Normal Node		5.1. Procedures for the Normal Node
	When the downstream Normal node detects its neighbor restarting, it		When the downstream normal node detects its neighbor restarting, it
	must send a RecoveryPath message for each LSP associated with the		must send a RecoveryPath message for each LSP associated with the
	restarting node for which it has previously sent a Resv message and		restarting node for which it has previously sent a Resv message and
	which has not been torn down.		which has not been torn down.
	When the upstream Normal node detects its neighbor restarting, it		When the upstream normal node detects its neighbor restarting, it
	must send a Path message with RECOVERY_LABEL object containing a		must send a Path message with a Recovery_Label Object containing a
	label value corresponding to the label value received in the most		label value corresponding to the label value received in the most
	recently received corresponding Resv message.		recently received corresponding Resv message.
	This document does not modify the procedures for the Normal node		This document does not modify the procedures for the normal node,
	which are described in [RFC3473] and [RFC5063].		which are described in [RFC3473] and [RFC5063].
	5.2. Procedures for the Restarting Node		5.2. Procedures for the Restarting Node
	This document does not modify the procedures for the Restarting		This document does not modify the procedures for the restarting node,
	node which are described in [RFC3473] and [RFC5063].		which are described in [RFC3473] and [RFC5063].
	5.2.1. Procedures for Scenario 1		5.2.1. Procedures for Scenario 1
	After the Restarting node restarts, it starts a Recovery Timer. Any		After the restarting node restarts, it starts a Recovery Timer. Any
	RSVP state that has not been resynchronized when the Recovery Timer		RSVP state that has not been resynchronized when the Recovery Timer
	expires, should be cleared.		expires should be cleared.
	At the Restarting node (Node B in the example), full		At the restarting node (Node B in the example), full
	resynchronization with the upstream neighbor (Node A) is possible		resynchronization with the upstream neighbor (Node A) is possible
	because Node A is a Normal node. The upstream Path information is		because Node A is a normal node. The upstream Path information is
	recovered from the Path message received from Node A. Node B also		recovered from the Path message received from Node A. Node B also
	recovers the upstream Resv information (that it had previously sent		recovers the upstream Resv information (that it had previously sent
	to Node A) from the RECOVERY_LABEL object carried in the Path		to Node A) from the Recovery_Label Object carried in the Path message
	message received from Node A, but, obviously, some information		received from Node A, but, obviously, some information (like the
	(like the Recorded Route Object) will be missing from the new Resv		Recorded_Route Object) will be missing from the new Resv message
	message generated by Node B, and can not be supplied until the		generated by Node B and cannot be supplied until the downstream
	downstream Delayed Restarting node (Node C) restarts and sends a		delayed restarting node (Node C) restarts and sends a Resv.
	Resv.
	After the upstream Path information and upstream Resv information		After the upstream Path information and upstream Resv information
	has been recovered by Node B, the normal refresh procedure with the		have been recovered by Node B, the normal refresh procedure with
	upstream Node A should be started.		upstream Node A should be started.
	As per [RFC5063], the Restarting node (Node B) would normally		As per [RFC5063], the restarting node (Node B) would normally expect
	expect to receive a RecoveryPath message from its downstream		to receive a RecoveryPath message from its downstream neighbor (Node
	neighbor (Node C). It would use this to recover the downstream Path		C). It would use this to recover the downstream Path information,
	information, and would subsequently send a Path message to its		and would subsequently send a Path message to its downstream neighbor
	downstream neighbor and receive a Resv message. But in this		and receive a Resv message. But in this scenario, because the
	scenario, because the downstream neighbor has not restarted yet,		downstream neighbor has not restarted yet, Node B detects the
	Node B detects the communication with Node C is interrupted and		communication with
	must wait before resynchronizing with its downstream neighbor.		Node C is interrupted and must wait before resynchronizing with its
			downstream neighbor.
	In this case, the Restarting node (Node B) follows the procedures		In this case, the restarting node (Node B) follows the procedures in
	in section 9.3 of [RFC3473] and may run a Restart Timer to wait for		Section 9.3 of [RFC3473] and may run a Restart Timer to wait for the
	the downstream neighbor (Node C) to restart. If its downstream		downstream neighbor (Node C) to restart. If its downstream neighbor
	neighbor (Node C) has not restarted before the timer expires the		(Node C) has not restarted before the timer expires, the
	corresponding LSPs may be torn down according to local policy		corresponding LSPs may be torn down according to local policy
	[RFC3473]. Note, however, that the Restart Time value suggested in		[RFC3473]. Note, however, that the Restart Time value suggested in
	[RFC3473] is based on the previous Hello message exchanged with the		[RFC3473] is based on the previous Hello message exchanged with the
	node that has not restarted yet (Node C). Since this time value is		node that has not restarted yet (Node C). Since this time value is
	unlikely to be available to the restarting node (Node B), a		unlikely to be available to the restarting node (Node B), a
	configured time value must be used if the timer is operated.		configured time value must be used if the timer is operated.
	The RSVP state must be reconciled with the retained data plane		The RSVP state must be reconciled with the retained data plane state
	state if the cross-connect information can be retrieved from the		if the cross-connect information can be retrieved from the data
	data plane. In the event of any mismatches, local policy will		plane. In the event of any mismatches, local policy will dictate the
	dictate the action that must be taken which could include:		action that must be taken, which could include:
	- reprogramming the data plane		- reprogramming the data plane
	- sending an alert to the management plane		- sending an alert to the management plane
	- tearing down the control plane state for the LSP.		- tearing down the control plane state for the LSP
	In the case that the Delayed Restarting node never comes back, and		In the case that the delayed restarting node never comes back and a
	where a Restart Timer is not used to automatically tear down LSPs,		Restart Timer is not used to automatically tear down LSPs, the LSPs
	the LSPs can be tidied up through the control plane using a		can be tidied up through the control plane using a PathTear from the
	PathTear from the upstream node (Node A). Note that if Node C		upstream node (Node A). Note that if Node C restarts after this
	restarts after this operation, the RecoveryPath message that it		operation, the RecoveryPath message that it sends to Node B will not
	sends to Node B will not be matched with any state on Node B and		be matched with any state on Node B and will receive a PathTear as
	will receive a PathTear as its response resulting in the teardown		its response, resulting in the teardown of the LSP at all downstream
	of the LSP at all downstream nodes.		nodes.
	5.2.2. Procedures for Scenario 2		5.2.2. Procedures for Scenario 2
	In this case, the Restarting node (Node C) can recover full		In this case, the restarting node (Node C) can recover full
	downstream state from its downstream neighbor (Node D) which is a		downstream state from its downstream neighbor (Node D), which is a
	Normal node. The downstream Path state can be recovered from the		normal node. The downstream Path state can be recovered from the
	RecoveryPath message which is sent by Node D. This allows Node C to		RecoveryPath message, which is sent by Node D. This allows Node C to
	send a Path refresh message to Node D, and Node D will respond with		send a Path refresh message to Node D, and Node D will respond with a
	a Resv message from which Node C can reconstruct the downstream		Resv message from which Node C can reconstruct the downstream Resv
	Resv state.		state.
	After the downstream Path information and downstream Resv		After the downstream Path information and downstream Resv information
	information has been recovered in Node C, the normal refresh		have been recovered in Node C, the normal refresh procedure with
	procedure with downstream Node D should be started.		downstream Node D should be started.
	The Restarting node would normally expect to resynchronize with its		The restarting node would normally expect to resynchronize with its
	upstream neighbor to re-learn the upstream Path and Resv state, but		upstream neighbor to re-learn the upstream Path and Resv state, but
	in this scenario, because the upstream neighbor (Node B) has not		in this scenario, because the upstream neighbor (Node B) has not
	restarted yet, the Restarting node (Node C) detects that the		restarted yet, the restarting node (Node C) detects that the
	communication with upstream neighbor (Node B) is interrupted. The		communication with upstream neighbor (Node B) is interrupted. The
	Restarting node (Node C) follows the procedures in section 9.3 of		restarting node (Node C) follows the procedures in Section 9.3 of
	[RFC3473] and may run a Restart Timer to wait the upstream neighbor		[RFC3473] and may run a Restart Timer to wait for the upstream
	(Node B) to restart. If its upstream neighbor (Node B) has not		neighbor (Node B) to restart. If its upstream neighbor (Node B) has
	restarted before the Restart Timer expires, the corresponding LSPs		not restarted before the Restart Timer expires, the corresponding
	may be torn down according to local policy [RFC3473]. Note, however,		LSPs may be torn down according to local policy [RFC3473]. Note,
	that the Restart Time value suggested in [RFC3473] is based on the		however, that the Restart Time value suggested in [RFC3473] is based
	previous Hello message exchanged with the node that has not		on the previous Hello message exchanged with the node that has not
	restarted yet (Node B). Since this time value is unlikely to be		restarted yet (Node B). Since this time value is unlikely to be
	available to the restarting node (Node C), a configured time value		available to the restarting node (Node C), a configured time value
	must be used if the timer is operated.		must be used if the timer is operated.
	Note that no Resv message is sent to the upstream neighbor (Node B)		Note that no Resv message is sent to the upstream neighbor (Node B),
	because it has not restarted.		because it has not restarted.
	The RSVP state must be reconciled with the retained data plane		The RSVP state must be reconciled with the retained data plane state
	state if the cross-connect information can be retrieved from the		if the cross-connect information can be retrieved from the data
	data plane.		plane.
	In the event of any mismatches, local policy will dictate the		In the event of any mismatches, local policy will dictate the action
	action that must be taken which could include:		that must be taken, which could include:
	- reprogramming the data plane		- reprogramming the data plane
	- sending an alert to the management plane		- sending an alert to the management plane
	- tearing down the control plane state for the LSP.		- tearing down the control plane state for the LSP
	In the case that the Delayed Restarting node never comes back, and		In the case that the delayed restarting node never comes back and a
	where a Restart Timer is not used to automatically tear down LSPs,		Restart Timer is not used to automatically tear down LSPs, the LSPs
	the LSPs cannot be tidied up through the control plane using a		cannot be tidied up through the control plane using a PathTear from
	PathTear from the upstream node (Node A), because there is no		the upstream node (Node A), because there is no control plane
	control plane connectivity to Node C from the upstream direction.		connectivity to Node C from the upstream direction. There are two
	There are two possibilities in [RFC3473]:		possibilities in [RFC3473]:
	- Management action may be taken at the Restarting node to tear the		- Management action may be taken at the restarting node to tear the
	LSP. This will result in the LSP being removed from Node C, and a		LSP. This will result in the LSP being removed from Node C and a
	PathTear being sent downstream to Node D.		PathTear being sent downstream to Node D.
	- Management action may be taken at any downstream node (for		- Management action may be taken at any downstream node (for example,
	example, Node D) resulting in a PathErr message with the		Node D), resulting in a PathErr message with the Path_State_Removed
	Path_State_Removed flag set being sent to Node C to tear the LSP		flag set being sent to Node C to tear the LSP state.
	state.
	Note that if Node B restarts after this operation, the Path message		Note that if Node B restarts after this operation, the Path message
	that it sends to Node C will not be matched with any state on Node		that it sends to Node C will not be matched with any state on Node C
	C and will be treated as a new Path message resulting in LSP setup.		and will be treated as a new Path message, resulting in LSP setup.
	Node C should use the labels carried in the Path message (in the		Node C should use the labels carried in the Path message (in the
	UPSTREAM_LABEL object and in the RECOVERY_LABEL object) to drive		Upstream_Label Object and in the Recovery_Label Object) to drive its
	its label allocation, but may use other labels according to normal		label allocation, but may use other labels according to normal LSP
	LSP setup rules.		setup rules.
	5.2.3. Procedures for Scenario 3		5.2.3. Procedures for Scenario 3
	In this example, the Restarting node (Node C) is isolated. It's		In this example, the restarting node (Node C) is isolated. Its
	upstream and downstream neighbors have not restarted.		upstream and downstream neighbors have not restarted.
	The Restarting node (Node C) follows the procedures in section 9.3		The restarting node (Node C) follows the procedures in Section 9.3 of
	of [RFC3473] and may run a Restart Timer for each of its neighbors		[RFC3473] and may run a Restart Timer for each of its neighbors
	(Nodes B and D). If a neighbor has not restarted before its Restart		(Nodes B and D). If a neighbor has not restarted before its Restart
	Timer expires, the corresponding LSPs may be torn down according to		Timer expires, the corresponding LSPs may be torn down according to
	local policy [RFC3473]. Note, however, that the Restart Time values		local policy [RFC3473]. Note, however, that the Restart Time values
	suggested in [RFC3473] are based on the previous Hello message		suggested in [RFC3473] are based on the previous Hello message
	exchanged with the nodes that have not restarted yet. Since these		exchanged with the nodes that have not restarted yet. Since these
	time values are unlikely to be available to the restarting node		time values are unlikely to be available to the restarting node (Node
	(Node C), a configured time value must be used if the timer is		C), a configured time value must be used if the timer is operated.
	operated.
	During the Recovery Time, if the upstream Delayed Restarting node		During the Recovery Time, if the upstream delayed restarting node has
	has restarted, the procedure for scenario 1 can be applied.		restarted, the procedure for scenario 1 can be applied.
	During the Recovery Time, if the downstream Delayed Restarting node		During the Recovery Time, if the downstream delayed restarting node
	has restarted, the procedure for scenario 2 can be applied.		has restarted, the procedure for scenario 2 can be applied.
	In the case that neither Delayed Restarting node ever comes back,		In the case that neither delayed restarting node ever comes back and
	and where a Restart Timer is not used to automatically tear down		a Restart Timer is not used to automatically tear down LSPs,
	LSPs, management intervention is required to tidy up the control		management intervention is required to tidy up the control plane and
	plane and the data plane on the node that is waiting for the failed		the data plane on the node that is waiting for the failed device to
	device to restart.		restart.
	If the downstream Delayed Restarting node restarts after the		If the downstream delayed restarting node restarts after the cleanup
	cleanup of LSPs at Node C, the RecoveryPath message from Node D		of LSPs at Node C, the RecoveryPath message from Node D will be
	will be responded with a PathTear message. If the upstream Delayed		responded to with a PathTear message. If the upstream delayed
	Restarting node restarts after the cleanup of LSPs at Node C, the		restarting node restarts after the cleanup of LSPs at Node C, the
	Path message from Node B will be treated as a new LSP setup request,		Path message from Node B will be treated as a new LSP setup request,
	but the setup will fail because Node D cannot be reached - Node C		but the setup will fail because Node D cannot be reached; Node C will
	will respond with a PathErr message. Since this happens to Node B		respond with a PathErr message. Since this happens to Node B during
	during its restart processing, it should follow the rules of		its restart processing, it should follow the rules of [RFC5063] and
	[RFC5063] and tear down the LSP.		tear down the LSP.
	5.2.4. Procedures for Scenario 4		5.2.4. Procedures for Scenario 4
	When the Ingress node (Node A) restarts, it does not know which		When the ingress node (Node A) restarts, it does not know which LSPs
	LSPs it caused to be created. Usually, however, this information is		it caused to be created. Usually, however, this information is
	retrieved from the management plane or from the configuration		retrieved from the management plane or from the configuration
	requests stored in non-volatile form in the node in order to		requests stored in non-volatile form in the node in order to recover
	recover the LSP state.		the LSP state.
	Furthermore, if the downstream node (Node B) is a Normal node,		Furthermore, if the downstream node (Node B) is a normal node,
	according to the procedures in [RFC5063], the ingress will receive		according to the procedures in [RFC5063], the ingress will receive a
	a RecoveryPath message and will understand that it was the ingress		RecoveryPath message and will understand that it was the ingress of
	of the LSP.		the LSP.
	However, in this scenario, the downstream node is a Delayed		However, in this scenario, the downstream node is a delayed
	Restarting node, so Node A must rely on the information from the		restarting node, so Node A must either rely on the information from
	management plane or stored configuration, or it must wait for Node		the management plane or stored configuration, or it must wait for
	B to restart.		Node B to restart.
	In the event that Node B never restarts, management plane		In the event that Node B never restarts, management plane
	intervention is needed at Node A to clean up any LSP control plane		intervention is needed at Node A to clean up any LSP control plane
	state restored from the management plane or from local		state restored from the management plane or from local configuration,
	configuration, and to release any data plane resources.		and to release any data plane resources.
	5.2.5. Procedures for Scenario 5		5.2.5. Procedures for Scenario 5
	In this scenario the Egress node (Node D) restarts, and its		In this scenario, the egress node (Node D) restarts, and its upstream
	upstream neighbor (Node C) has not restarted. In this case, the		neighbor (Node C) has not restarted. In this case, the egress node
	Egress node may have no control plane state relating to the LSPs.		may have no control plane state relating to the LSPs. It has no
	It has no downstream neighbor to help it, and no management plane		downstream neighbor to help it and no management plane or
	or configuration information, although there will be data plane		configuration information, although there will be data plane state
	state for the LSP. The Egress node must simply wait until its		for the LSP. The egress node must simply wait until its upstream
	upstream neighbor restarts and gives it the information as Path		neighbor restarts and gives it the information in Path messages
	messages carrying RECOVERY_LABEL objects.		carrying Recovery_Label Objects.
	5.3. Consideration of Re-Use of Data Plane Resources		5.3. Consideration of the Reuse of Data Plane Resources
	Fundamental to the processes described above is an understanding		Fundamental to the processes described above is an understanding that
	that data plane resources may remain in use (allocated and cross-		data plane resources may remain in use (allocated and cross-
	connected) when control plane state has not been fully		connected) when control plane state has not been fully resynchronized
	resynchronized because some control plane nodes have not restarted.		because some control plane nodes have not restarted.
	It is assumed that these data plane resources might be carrying		It is assumed that these data plane resources might be carrying
	traffic and should not be reconfigured except through application		traffic and should not be reconfigured except through application of
	of operator-configured policy, or as a direct result of operator		operator-configured policy, or as a direct result of operator action.
	action.
	In particular, new LSP setup requests from the control plane or the		In particular, new LSP setup requests from the control plane or the
	management plane should not be allowed to use data plane resources		management plane should not be allowed to use data plane resources
	that are still in use. Specific action must first be taken to		that are still in use. Specific action must first be taken to
	release the resources.		release the resources.
	5.4. Consideration of Management Plane Intervention		5.4. Consideration of Management Plane Intervention
	The management plane must always retain the ability to control data		The management plane must always retain the ability to control data
	plane resources and to over-ride the control plane. In this context,		plane resources and to override the control plane. In this context,
	the management plane must always be able to release data plane		the management plane must always be able to release data plane
	resources that were previously in place for use by control-plane		resources that were previously in place for use by control-plane-
	established LSPs. Further, the management plane must always be able		established LSPs. Further, the management plane must always be able
	to instruct any control plane node to tear down any LSP.		to instruct any control plane node to tear down any LSP.
	Operators should be aware of the risks of misconnection that could		Operators should be aware of the risks of misconnection that could be
	be caused by careless manipulation from the management plane of in-		caused by careless manipulation from the management plane of in-use
	use data plane resources.		data plane resources.
	6. Clarification of Restarting Node Procedure		6. Clarification of Restarting Node Procedure
	According to the current graceful restart procedure [RFC3473],		According to the current graceful restart procedure [RFC3473], after
	after a node restarts its control plane, it needs its upstream node		a node restarts its control plane, it needs its upstream node to send
	to send PATH message with recovery label to synchronize its RSVP		a PATH message with a recovery label in order to synchronize its RSVP
	state. If the restarted control plane becomes operational quickly,		state. If the restarted control plane becomes operational quickly,
	the upstream node may not detect the restarting of downstream node		the upstream node may not detect the restarting of the downstream
	and therefore, may send a PATH message without recovery label		node and, therefore, may send a PATH message without a recovery
	causing errors and unwanted connection deletion.		label, causing errors and unwanted connection deletion.
	N1 N2		N1 N2
	| |		| |
	| X (Restart start)		| X (Restart start)
	| HELLO |		| HELLO |
	|--------------->|		|--------------->|
	| |		| |
	| SRefresh |		| SRefresh |
	|--------------->|		|--------------->|
	| |		| |
	skipping to change at page 13, line 43		skipping to change at page 14, line 33
	| recovery label |		| recovery label |
	|--------------->|		|--------------->|
	| X (resource allocation failed because the		| X (resource allocation failed because the
	| | resources are in use)		| | resources are in use)
	| PathErr |		| PathErr |
	|<---------------|		|<---------------|
	| PathTear |		| PathTear |
	|--------------->|		|--------------->|
	X(LSP deletion) X (LSP deletion)		X(LSP deletion) X (LSP deletion)
	| |		| |
	Figure 2 Message flow for accidental LSP deletion
	The sequence diagram above depicts one scenario where the LSP may		Figure 2: Message Flow for Accidental LSP Deletion
	get deleted.
	In this sequence N1 did not detect Hello failure and continues		The sequence diagram above depicts one scenario where the LSP may get
	sending SRefreshes which may get NACK'ed by N2 once restart		deleted.
			In this sequence, N1 does not detect Hello failure and continues
			sending SRefreshes, which may get NACK'ed by N2 once restart
	completes because there is no Path state corresponding to the		completes because there is no Path state corresponding to the
	SRefresh message. This NACK causes a Path refresh message to be		SRefresh message. This NACK causes a Path refresh message to be
	generated but there is no RECOVERY_LABEL because N1 did not yet		generated, but there is no Recovery_Label because N1 does not yet
	detect that N2 has restarted as Hello exchanges have not yet		detect that N2 has restarted, as Hello exchanges have not yet
	started. The Path message is treated as "new" and fails to allocate		started. The Path message is treated as "new" and fails to allocate
	the resources because they are still in use. This causes a PathErr		the resources because they are still in use. This causes a PathErr
	message to be generated which may lead to the tear down of the LSP.		message to be generated, which may lead to the teardown of the LSP.
	To resolve the aforementioned problem, the following procedures		To resolve the aforementioned problem, the following procedures,
	which are implicit in [RFC3473] and [RFC5063] should be followed.		which are implicit in [RFC3473] and [RFC5063], should be followed.
	These procedures work together with the recovery procedures		These procedures work together with the recovery procedures
	documented in [RFC3473]. Here, it is assumed that the restarting		documented in [RFC3473]. Here, it is assumed that the restarting
	node and the neighboring node(s) support Hello extension as		node and the neighboring node(s) support the Hello extension as
	documented in [RFC3209] and recovery procedures documented in		documented in [RFC3209] as well as the recovery procedures documented
	[RFC3473].		in [RFC3473].
	After a node restarts its control plane, it should ignore and		After a node restarts its control plane, it should ignore and
	silently drop all RSVP-TE messages, except Hello messages, it		silently drop all RSVP-TE messages (except Hello messages) it
	receives from any neighbor to which, no HELLO session has been		receives from any neighbor to which no HELLO session has been
	established.		established.
	The restarting node should follow [RFC3209] to establish Hello		The restarting node should follow [RFC3209] to establish Hello
	sessions with its neighbors, after its control plane becomes		sessions with its neighbors, after its control plane becomes
	operational.		operational.
	The restarting node resumes processing of RSVP-TE messages sent		The restarting node resumes processing of RSVP-TE messages sent from
	from each neighbor to which the Hello session has been established.		each neighbor to which the Hello session has been established.
	7. Security Considerations		7. Security Considerations
	This document clarifies the procedures defined in [RFC3473] and		This document clarifies the procedures defined in [RFC3473] and
	[RFC5063] to be performed on RSVP agents that neighbor one or more		[RFC5063] to be performed on RSVP agents that neighbor one or more
	restarting RSVP agents. It does not introduce any new procedures		restarting RSVP agents. It does not introduce any new procedures
	and, therefore, does not introduce any new security risks or issues.		and, therefore, does not introduce any new security risks or issues.
	In the case of the control plane in general, and the RSVP agent in		In the case of the control plane in general, and the RSVP agent in
	particular, where one or more nodes carrying one or more LSPs are		particular, where one or more nodes carrying one or more LSPs are
	restarted due to external attacks, the procedures defined in		restarted due to external attacks, the procedures defined in
	[RFC5063] and described in this document provide the ability for		[RFC5063] and described in this document provide the ability for the
	the restarting RSVP agents to recover the RSVP state in each		restarting RSVP agents to recover the RSVP state in each restarting
	restarting node corresponding to the LSPs, with the least possible		node corresponding to the LSPs, with the least possible perturbation
	perturbation to the rest of the network. These procedures can be		to the rest of the network. These procedures can be considered to
	considered to provide mechanisms by which the GMPLS network can		provide mechanisms by which the GMPLS network can recover from
	recover from physical attacks or from attacks on remotely		physical attacks or from attacks on remotely controlled power
	controlled power supplies.		supplies.
	The procedures described are such that, only the neighboring RSVP		The procedures described are such that only the neighboring RSVP
	agents should notice the restart of a node, and hence only they		agents should notice the restart of a node, and hence only they need
	need to perform additional processing. This allows for a network		to perform additional processing. This allows for a network with
	with active LSPs to recover LSP state gracefully from an external		active LSPs to recover LSP state gracefully from an external attack,
	attack, without perturbing the data/forwarding plane state, and		without perturbing the data/forwarding plane state and without
	without propagating the error condition in the control or data		propagating the error condition in the control or data plane. In
	plane. In other words, the effect of the restart (which might be		other words, the effect of the restart (which might be the result of
	the result of an attack) does not spread into the network.		an attack) does not spread into the network.
	Note that concern has been expressed about the vulnerability of a		Note that concern has been expressed about the vulnerability of a
	restarting node to false messages received from its neighbors. For		restarting node to false messages received from its neighbors. For
	example, a restarting node might receive a false Path message with		example, a restarting node might receive a false Path message with a
	a Recovery Label object from an upstream neighbor, or a false		Recovery_Label Object from an upstream neighbor, or a false
	RecoveryPath message from its downstream neighbor. This situation		RecoveryPath message from its downstream neighbor. This situation
	might arise in one of four cases:		might arise in one of four cases:
	- The message is spoofed and does not come from the neighbor at all.		- The message is spoofed and does not come from the neighbor at all.
	- The message has been modified as it was traveling from the		- The message has been modified as it was traveling from the
	neighbor.		neighbor.
	- The neighbor is defective and has generated a message in error.		- The neighbor is defective and has generated a message in error.
	- The neighbor has been subverted and has a "rogue" RSVP agent.		- The neighbor has been subverted and has a "rogue" RSVP agent.
	The first two cases may be handled using standard RSVP		The first two cases may be handled using standard RSVP authentication
	authentication and integrity procedures [RFC3209], [RFC3473]. If		and integrity procedures [RFC3209], [RFC3473]. If the operator is
	the operator is particularly worried, the control plane may be		particularly worried, the control plane may be operated using IPsec
	operated using IPsec [RFC4301], [RFC4302], [RFC4835], [RFC4306],		[RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411].
	and [RFC2411].
	Protection against defective or rogue RSVP implementations is		Protection against defective or rogue RSVP implementations is
	generally hard to impossible. Neighbor-to-neighbor authentication		generally hard-to-impossible. Neighbor-to-neighbor authentication
	and integrity validation is, by definition, ineffective in these		and integrity validation is, by definition, ineffective in these
	situations. For example, if a neighbor node sends a Resv during		situations. For example, if a neighbor node sends a Resv during
	normal LSP setup, and if that message carries a GENERALIZED_LABEL		normal LSP setup, and if that message carries a Generalized_Label
	object carrying an incorrect label value, then the receiving LSR		Object carrying an incorrect label value, then the receiving LSR will
	will use the supplied value and the LSP will be set up incorrectly.		use the supplied value and the LSP will be set up incorrectly.
	Alternatively, if a Path message is modified by an upstream LSR to		Alternatively, if a Path message is modified by an upstream LSR to
	change the destination and explicit route, there is no way for the		change the destination and explicit route, there is no way for the
	downstream LSR to detect this, and the LSP may be set up to the		downstream LSR to detect this, and the LSP may be set up to the wrong
	wrong destination. Furthermore, the upstream LSR could disguise		destination. Furthermore, the upstream LSR could disguise this fact
	this fact by modifying the recorded route reported in the Resv		by modifying the recorded route reported in the Resv message. Thus,
	message. Thus, these issues are in no way specific to the restart		these issues are in no way specific to the restart case, do not cause
	case, do not cause any greater or different problems from the		any greater or different problems from the normal case, and do not
	normal case, and do not warrant specific security measure		warrant specific security measures applicable to restart scenarios.
	applicable to restart scenarios.
	Note that the RSVP POLICY_DATA object [RFC2205] provides a scope by		Note that the RSVP Policy_Data Object [RFC2205] provides a scope by
	which secure end-to-end checks could be applied. However, very		which secure end-to-end checks could be applied. However, very
	little definition of the use of this object has been made to date.		little definition of the use of this object has been made to date.
	See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS		See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS
	networks.		networks.
	8. IANA Considerations		8. Acknowledgments
	This document defines no new protocols or extensions and makes no
	requests to IANA for registry management.
	9. Acknowledgments
	We would like to thank Adrian Farrel, Dimitri Papadimitriou, and		We would like to thank Adrian Farrel, Dimitri Papadimitriou, and Lou
	Lou Berger for their useful comments.		Berger for their useful comments.
	10. References		9. References
	10.1. Normative References		9.1. Normative References
	[RFC2209] R. Braden, L. Zhang, "Resource ReSerVation Protocol (RSVP)		[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol
	-- Version 1 Message Processing Rules", RFC 2209, September		(RSVP) -- Version 1 Message Processing Rules", RFC 2209,
	1997.		September 1997.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic		Switching (GMPLS) Signaling Resource ReserVation
	Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.		Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
			3473, January 2003.
	[RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP		[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to
	Graceful Restart", RFC 5063, September 2007.		GMPLS Resource Reservation Protocol (RSVP) Graceful
			Restart", RFC 5063, October 2007.
	10.2. Informative References		9.2. Informative References
	[MPLS-SEC] Fang, L., "Security Framework for MPLS and GMPLS Networks",		[MPLS-SEC] Fang, L., "Security Framework for MPLS and GMPLS
	draft-ietf-mpls-mpls-and-gmpls-security-framework, work in		Networks", Work in Progress, November 2008.
	progress.
	[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and S.		[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReserVation Protocol -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, September 1997.		Functional Specification", RFC 2205, September 1997.
	[RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document		[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
	Roadmap", RFC 2411, November 1998.		Document Roadmap", RFC 2411, November 1998.
	[RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[RFC4302] S. Kent, "IP Authentication Header", RFC 4302, December		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
	2005.		2005.
	[RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", RFC		[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
	4306, December 2005.		Protocol", RFC 4306, December 2005.
	[RFC4835] V. Manral, "Cryptographic Algorithm Implementation		[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
	Requirements for Encapsulating Security Payload (ESP) and		Requirements for Encapsulating Security Payload (ESP) and
	Authentication Header (AH)", RFC 4835, April 2007.		Authentication Header (AH)", RFC 4835, April 2007.
	11. Authors' Addresses		Authors' Addresses
	Dan Li		Dan Li
	Huawei Technologies		Huawei Technologies
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Shenzhen 518129, China		Shenzhen 518129, China
	Phone: +86 755 28970230		Phone: +86 755 28970230
	Email: danli@huawei.com		EMail: danli@huawei.com
	Jianhua Gao		Jianhua Gao
	Huawei Technologies		Huawei Technologies
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Shenzhen 518129, China		Shenzhen 518129, China
	Phone: +86 755 28972902		Phone: +86 755 28972902
	Email: gjhhit@huawei.com		EMail: gjhhit@huawei.com
	Arun Satyanarayana		Arun Satyanarayana
	Cisco Systems		Cisco Systems
	170 West Tasman Dr		170 West Tasman Dr
	San Jose, CA 95134, USA		San Jose, CA 95134, USA
	Phone: +1 408 853-3206		Phone: +1 408 853-3206
	Email: asatyana@cisco.com		EMail: asatyana@cisco.com
	Snigdho C. Bardalai		Snigdho C. Bardalai
	Fujitsu Network Communications		Fujitsu Network Communications
	2801 Telecom Parkway		2801 Telecom Parkway
	Richardson, Texas 75082, USA		Richardson, Texas 75082, USA
	Phone: +1 972 479 2951		Phone: +1 972 479 2951
	Email: snigdho.bardalai@us.fujitsu.com		EMail: snigdho.bardalai@us.fujitsu.com
	12. Full Copyright Statement
	Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect
	to this document.
	All IETF Documents and the information contained therein are provided
	on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.
	13. Intellectual Property Statement
	The IETF Trust takes no position regarding the validity or scope of
	any Intellectual Property Rights or other rights that might be
	claimed to pertain to the implementation or use of the technology
	described in any IETF Document or the extent to which any license
	under such rights might or might not be available; nor does it
	represent that it has made any independent effort to identify any
	such rights.
	Copies of Intellectual Property disclosures made to the IETF
	Secretariat and any assurances of licenses to be made available, or
	the result of an attempt made to obtain a general license or
	permission for the use of such proprietary rights by implementers or
	users of this specification can be obtained from the IETF on-line IPR
	repository at http://www.ietf.org/ipr
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	any standard or specification contained in an IETF Document. Please
	address the information to the IETF at ietf-ipr@ietf.org.
	The definitive version of an IETF Document is that published by, or
	under the auspices of, the IETF. Versions of IETF Documents that are
	published by third parties, including those that are translated into
	other languages, should not be considered to be definitive versions
	of IETF Documents. The definitive version of these Legal Provisions
	is that published by, or under the auspices of, the IETF. Versions of
	these Legal Provisions that are published by third parties, including
	those that are translated into other languages, should not be
	considered to be definitive versions of these Legal Provisions.
	For the avoidance of doubt, each Contributor to the IETF Standards
	Process licenses each Contribution that he or she makes as part of
	the IETF Standards Process to the IETF Trust pursuant to the
	provisions of RFC 5378. No language to the contrary, or terms,
	conditions or rights that differ from or are inconsistent with the
	rights and licenses granted under RFC 5378, shall have any effect and
	shall be null and void, whether published or posted by such
	Contributor, or included with or in such Contribution.
End of changes. 139 change blocks.
	400 lines changed or deleted		401 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/