draft-ietf-ccamp-gr-description-01.txt		draft-ietf-ccamp-gr-description-02.txt
	Network Working Group Dan Li		Network Working Group Dan Li (Huawei)
	Internet Draft Jianhua Gao		Internet Draft Jianhua Gao (Huawei)
	Huawei		Arun Satyanarayana (Cisco)
	Arun Satyanarayana
	Cisco
	Intended Status: Informational		Intended Status: Informational
	Expires: May 2008 November, 2007		Expires: November 5, 2008 May 5, 2008
	Description of the RSVP-TE Graceful Restart Procedures		Description of the RSVP-TE Graceful Restart Procedures
	draft-ietf-ccamp-gr-description-01.txt
			draft-ietf-ccamp-gr-description-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		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.		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
	skipping to change at page 2, line 29		skipping to change at page 2, line 29
	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 [RFC3473]............................4
	2.2. Procedures defined in [RFC5063]............................5		2.2. Procedures defined in [RFC5063]............................5
	3. Multiple Node Restart Scenarios..............................5		3. Multiple Node Restart Scenarios..............................5
	4. RSVP State...................................................6		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.............................7
	5.2. Procedures for the Restarting Node.........................7		5.2. Procedures for the Restarting Node.........................7
	5.2.1. Procedures for Scenario 1................................7		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...............................10
	5.2.4. Procedures for scenario 4...............................11		5.2.4. Procedures for scenario 4...............................11
	5.2.5. Procedures for scenario 5...............................11		5.2.5. Procedures for scenario 5...............................12
	5.3. Consideration of Re-Use of Data Plane Resources...........12		5.3. Consideration of Re-Use of Data Plane Resources...........12
	5.4. Consideration of Management Plane Intervention............12		5.4. Consideration of Management Plane Intervention............12
	6. Clarification of Restarting Node Procedure..................12		6. Clarification of Restarting Node Procedure..................13
	7. Security Considerations.....................................14		7. Security Considerations.....................................14
	8. IANA Considerations.........................................14		8. IANA Considerations.........................................14
	9. Acknowledgments.............................................14		9. Acknowledgments.............................................15
	10. References.................................................15		10. References.................................................15
	10.1. Normative References.....................................15		10.1. Normative References.....................................15
	11. Authors' Addresses.........................................16		10.2. Informative References...................................15
			11. Author's Addresses.........................................16
	12. Full Copyright Statement...................................16		12. Full Copyright Statement...................................16
	13. Intellectual Property Statement............................17		13. Intellectual Property Statement............................17
	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 [RFC3209]. The Hello message has been extended for use in		network [RFC3209]. The Hello message has been extended for use in
	skipping to change at page 6, line 42		skipping to change at page 6, line 42
	a Delayed Restarting node. Nodes C and D are Normal nodes.		a Delayed Restarting node. Nodes C and D are Normal nodes.
	5) A Restarting Egress node with upstream Delayed Restarting node.		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		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.		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 multi nodes which are not neighbors are restarted, the
			restart Procedures could be applied as multiple separated restart
			procedures which are exactly the same as the procedures described
			in [RFC3473] and [RFC5063]. Therefore, these scenarios are not
			described in this document. For example, in Figure 1, Node A and
			Node C are normal nodes, and Node B and Node D are restarting nodes,
			so Node B could be restarted through Node A and Node C, meanwhile,
			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 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
	skipping to change at page 13, line 31		skipping to change at page 13, line 41
	|<---------------|		|<---------------|
	| Path without |		| Path without |
	| recovery label |		| recovery label |
	|--------------->|		|--------------->|
	| X (resoure allocation failed because the		| X (resoure allocation failed because the
	| | resouces are in use)		| | resouces are in use)
	| PathErr |		| PathErr |
	|<---------------|		|<---------------|
	| PathTear |		| PathTear |
	|--------------->|		|--------------->|
	X(CON deletion) X (XCON deletion)		X(CON deletion) X (CON 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.
	In this sequence N1 did not detect hello failure and continues		In this sequence N1 did not detect hello failure and continues
	sending SRefreshes which may get NACK'ed by N2 once restart		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 did not yet
	skipping to change at page 16, line 5		skipping to change at page 15, line 29
	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., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic		(GMPLS) Signaling Resource ReserVation Protocol-Traffic
	Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.		Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
	[RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP		[RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP
	Graceful Restart", RFC 5063, September 2007.		Graceful Restart", RFC 5063, September 2007.
	11. Authors' Addresses		10.2. Informative References
			None.
			11. Author's Addresses
	Dan Li		Dan Li
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Bantian, Longgang District		Bantian, Longgang District
	Shenzhen 518129 P.R.China		Shenzhen 518129,
			China
	Phone: +86-755-28972910		Phone: +86 755 28973237
	Email: danli@huawei.com		Email: danli@huawei.com
	Jianhua Gao		Jianhua Gao
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	F3-5-B R&D Center, Huawei Base,		F3-5-B R&D Center, Huawei Base,
	Bantian, Longgang District		Bantian, Longgang District
	Shenzhen 518129 P.R.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, Inc.		Cisco Systems, Inc.
	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, Inc.
	2801 Telecom Parkway,		2801 Telecom Parkway,
	Richardson, Texas 75082		Richardson, Texas 75082
	United States of America		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 (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		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
End of changes. 18 change blocks.
	26 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/