draft-ietf-ccamp-gr-description-03.txt		draft-ietf-ccamp-gr-description-04.txt
	Network Working Group Dan Li (Huawei)		Network Working Group Dan Li (Huawei)
	Internet Draft Jianhua Gao (Huawei)		Internet Draft Jianhua Gao (Huawei)
	Arun Satyanarayana (Cisco)		Arun Satyanarayana (Cisco)
			Snigdho C. Bardalai (Fujitsu)
	Intended Status: Informational		Intended Status: Informational
	Expires: November 19, 2008 May 19, 2008		Expires: July 21, 2009 January 21, 2009
	Description of the RSVP-TE Graceful Restart Procedures		Description of the RSVP-TE Graceful Restart Procedures
	draft-ietf-ccamp-gr-description-03.txt		draft-ietf-ccamp-gr-description-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with
	applicable patent or other IPR claims of which he or she is aware		the provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other documents
	documents at any time. It is inappropriate to use Internet-Drafts		at any time. It is inappropriate to use Internet-Drafts as reference
	as reference material or to cite them other than as "work in		material or to cite them other than as "work in progress."
	progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	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. The Hello message has been extended for use in Generalized		network. The Hello message has been extended for use in Generalized
	MPLS (GMPLS) network for state recovery of control channel or nodal		MPLS (GMPLS) network for state recovery of control channel or nodal
	faults.		faults.
	skipping to change at page 7, line 17		skipping to change at page 7, line 17
	For each scenario, the RSVP state needs to be recovered at the		For each scenario, the RSVP state needs to be recovered at the
	restarting nodes are Path State Block (PSB) and Resv State Block		restarting nodes are 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 implementation issue. In fact, there is no requirement to		an implementation issue. In fact, there is no requirement to
	maintain separate PSB and RSB data structures. And in GMPLS, there		maintain separate PSB and RSB data structures. And in GMPLS, there
	is a much closer tie between Path and Resv state so it is possible		is a much closer tie between Path and Resv state so it is possible
	to combine the information into a single state block (the LSP state		to combine the information into a single state block (the LSP state
	block). On the other hand, if P2MP is supported, it may be		block). On the other hand, if point to multi-point is supported, it
	convenient to maintain separate upstream and downstream state. Note		may be convenient to maintain separate upstream and downstream
	that the PSB and RSB are not upstream and downstream state since		state. Note that the PSB and RSB are not upstream and downstream
	the PSB is responsible for receiving a Path from upstream and		state since the PSB is responsible for receiving a Path from
	sending a Path to downstream.		upstream and sending a 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 to the PSB and RSB.		correspond 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 which are described in [RFC3473] and [RFC5063].
	skipping to change at page 10, line 31		skipping to change at page 10, line 31
	PathTear from the upstream node (Node A), because there is no		PathTear from the upstream node (Node A), because there is no
	control plane connectivity to Node C from the upstream direction.		control plane connectivity to Node C from the upstream direction.
	There are two possibilities in [RFC3473]:		There are two 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, Node D) resulting in a PathErr message with the		example, Node D) resulting in a PathErr message with the
	Path_State_Reomved flag set being sent to Node C to tear the LSP		Path_State_Removed 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 and will be treated as a new Path message resulting in LSP setup.		C 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 label allocation, but may use other labels according to normal		its label allocation, but may use other labels according to normal
	LSP setup rules.		LSP setup rules.
	skipping to change at page 13, line 35		skipping to change at page 13, line 35
	|--------------->|		|--------------->|
	| |		| |
	| X (Restart complete)		| X (Restart complete)
	| SRefresh |		| SRefresh |
	|--------------->|		|--------------->|
	| NACK |		| NACK |
	|<---------------|		|<---------------|
	| Path without |		| Path without |
	| recovery label |		| recovery label |
	|--------------->|		|--------------->|
	| X (resoure allocation failed because the		| X (resource allocation failed because the
	| | resouces 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		Figure 2 Message flow for accidental LSP deletion
	The sequence diagram above depicts one scenario where the LSP may		The sequence diagram above depicts one scenario where the LSP may
	get deleted.		get deleted.
	skipping to change at page 15, line 19		skipping to change at page 15, line 19
	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 Recovery Label object from an upstream neighbor, or a false		a 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 travelling 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 and integrity procedures [RFC3209], [RFC3473]. If		authentication and integrity procedures [RFC3209], [RFC3473]. If
	the operator is particularly worried, the control plane may be		the operator is particularly worried, the control plane may be
	operated using IPsec [RFC4301], [RFC4302], [RFC4835], [RFC4306],		operated using IPsec [RFC4301], [RFC4302], [RFC4835], [RFC4306],
	skipping to change at page 17, line 21		skipping to change at page 17, line 21
	[RFC4302] S. Kent, "IP Authentication Header", RFC 4302, December		[RFC4302] S. Kent, "IP Authentication Header", RFC 4302, December
	2005.		2005.
	[RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", RFC		[RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", RFC
	4306, December 2005.		4306, December 2005.
	[RFC4835] V. Manral, "Cryptographic Algorithm Implementation		[RFC4835] V. Manral, "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. Author's Addresses		11. Authors' Addresses
	Dan Li		Dan Li
	Huawei Technologies Co., Ltd.		Huawei Technologies
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Bantian, Longgang District		Shenzhen 518129, China
	Shenzhen 518129, P.R.China
	Phone: +86 755 28973237		Phone: +86 755 28970230
	Email: danli@huawei.com		Email: danli@huawei.com
	Jianhua Gao		Jianhua Gao
	Huawei Technologies Co., Ltd.		Huawei Technologies
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Bantian, Longgang District		Shenzhen 518129, China
	Shenzhen 518129, P.R.China
	Phone: +86 755 28972902		Phone: +86 755 28972902
	Email: gjhhit@huawei.com		Email: gjhhit@huawei.com
	Arun Satyanarayana		Arun Satyanarayana
	Cisco Systems, Inc.		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, Inc.		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		12. Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
	This document is subject to the rights, licenses and restrictions		This document is subject to BCP 78 and the IETF Trust's Legal
	contained in BCP 78, and except as set forth therein, the authors		Provisions Relating to IETF Documents
	retain all their rights.		(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.
	This document and the information contained herein are provided on		All IETF Documents and the information contained therein are provided
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE		WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.		FOR A PARTICULAR PURPOSE.
	13. Intellectual Property Statement		13. Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF Trust takes no position regarding the validity or scope of
	Intellectual Property Rights or other rights that might be claimed		any Intellectual Property Rights or other rights that might be
	to pertain to the implementation or use of the technology described		claimed to pertain to the implementation or use of the technology
	in this document or the extent to which any license under such		described in any IETF Document or the extent to which any license
	rights might or might not be available; nor does it represent that		under such rights might or might not be available; nor does it
	it has made any independent effort to identify any such rights.		represent that it has made any independent effort to identify any
	Information on the procedures with respect to rights in RFC		such rights.
	documents can be found in BCP 78 and BCP 79.
	Copies of IPR 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.
			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		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		any standard or specification contained in an IETF Document. Please
	ietf-ipr@ietf.org.		address the information to the IETF at ietf-ipr@ietf.org.
	Internet-Drafts are working documents of the Internet Engineering		The definitive version of an IETF Document is that published by, or
	Task Force (IETF), its areas, and its working groups. Note that		under the auspices of, the IETF. Versions of IETF Documents that are
	other groups may also distribute working documents as Internet-		published by third parties, including those that are translated into
	Drafts.		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.
	Internet-Drafts are draft documents valid for a maximum of six		For the avoidance of doubt, each Contributor to the IETF Standards
	months and may be updated, replaced, or obsoleted by other		Process licenses each Contribution that he or she makes as part of
	documents at any time. It is inappropriate to use Internet-Drafts		the IETF Standards Process to the IETF Trust pursuant to the
	as reference material or to cite them other than as "work in		provisions of RFC 5378. No language to the contrary, or terms,
	progress".		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. 29 change blocks.
	61 lines changed or deleted		68 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/