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/