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/