--- 1/draft-ietf-ccamp-gr-description-03.txt 2009-01-21 10:12:02.000000000 +0100 +++ 2/draft-ietf-ccamp-gr-description-04.txt 2009-01-21 10:12:02.000000000 +0100 @@ -1,44 +1,42 @@ Network Working Group Dan Li (Huawei) Internet Draft Jianhua Gao (Huawei) Arun Satyanarayana (Cisco) + Snigdho C. Bardalai (Fujitsu) 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 - draft-ietf-ccamp-gr-description-03.txt + draft-ietf-ccamp-gr-description-04.txt Status of this Memo - By submitting this Internet-Draft, each author represents that any - 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 - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with + the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering 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 - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." + months and may be updated, replaced, or obsoleted by other documents + 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 - 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 - http://www.ietf.org/shadow.html + http://www.ietf.org/shadow.html. Abstract The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. @@ -279,25 +277,25 @@ For each scenario, the RSVP state needs to be recovered at the restarting nodes are Path State Block (PSB) and Resv State Block (RSB), which are created when the node receives the corresponding Path message and Resv message. According to [RFC2209], how to construct the PSB and RSB is really an implementation issue. In fact, there is no requirement to 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 to combine the information into a single state block (the LSP state - block). On the other hand, if P2MP is supported, it may be - convenient to maintain separate upstream and downstream state. Note - that the PSB and RSB are not upstream and downstream state since - the PSB is responsible for receiving a Path from upstream and - sending a Path to downstream. + block). On the other hand, if point to multi-point is supported, it + may be convenient to maintain separate upstream and downstream + state. Note that the PSB and RSB are not upstream and downstream + state since the PSB is responsible for receiving a Path from + upstream and sending a Path to downstream. Regardless of how the RSVP state is implemented, on recovery there are two logical pieces of state to be recovered and these correspond to the PSB and RSB. 5. Procedures for Multiple Node Restart In this document, all the nodes are assumed to have the graceful restart capabilities which are described in [RFC3473] and [RFC5063]. @@ -435,21 +433,21 @@ PathTear from the upstream node (Node A), because there is no control plane connectivity to Node C from the upstream direction. There are two possibilities in [RFC3473]: - 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 PathTear being sent downstream to Node D. - Management action may be taken at any downstream node (for 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. 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 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 UPSTREAM_LABEL object and in the RECOVERY_LABEL object) to drive its label allocation, but may use other labels according to normal LSP setup rules. @@ -578,22 +576,22 @@ |--------------->| | | | X (Restart complete) | SRefresh | |--------------->| | NACK | |<---------------| | Path without | | recovery label | |--------------->| - | X (resoure allocation failed because the - | | resouces are in use) + | X (resource allocation failed because the + | | resources are in use) | PathErr | |<---------------| | PathTear | |--------------->| 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 get deleted. @@ -657,21 +655,21 @@ Note that concern has been expressed about the vulnerability of a restarting node to false messages received from its neighbors. For example, a restarting node might receive a false Path message with a Recovery Label object from an upstream neighbor, or a false RecoveryPath message from its downstream neighbor. This situation might arise in one of four cases: - 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. - The neighbor is defective and has generated a message in error. - The neighbor has been subverted and has a "rogue" RSVP agent. The first two cases may be handled using standard RSVP authentication and integrity procedures [RFC3209], [RFC3473]. If the operator is particularly worried, the control plane may be operated using IPsec [RFC4301], [RFC4302], [RFC4835], [RFC4306], @@ -749,92 +747,104 @@ [RFC4302] S. Kent, "IP Authentication Header", RFC 4302, December 2005. [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4835] V. Manral, "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007. -11. Author's Addresses +11. Authors' Addresses Dan Li - Huawei Technologies Co., Ltd. + Huawei Technologies F3-5-B R&D Center, Huawei Base, - Bantian, Longgang District - Shenzhen 518129, P.R.China - Phone: +86 755 28973237 + Shenzhen 518129, China + + Phone: +86 755 28970230 Email: danli@huawei.com Jianhua Gao - Huawei Technologies Co., Ltd. + Huawei Technologies F3-5-B R&D Center, Huawei Base, - Bantian, Longgang District - Shenzhen 518129, P.R.China + Shenzhen 518129, China + Phone: +86 755 28972902 Email: gjhhit@huawei.com Arun Satyanarayana - Cisco Systems, Inc. - 170 West Tasman Dr. + Cisco Systems + 170 West Tasman Dr San Jose, CA 95134, USA + Phone: +1 408 853-3206 Email: asatyana@cisco.com Snigdho C. Bardalai - Fujitsu Network Communications, Inc. - 2801 Telecom Parkway, + Fujitsu Network Communications + 2801 Telecom Parkway Richardson, Texas 75082, USA + Phone: +1 972 479 2951 Email: snigdho.bardalai@us.fujitsu.com 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 - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. + 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. - This document and the information contained herein are provided on - an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + 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 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 FOR A PARTICULAR PURPOSE. 13. Intellectual Property Statement - The IETF 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 this 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. - Information on the procedures with respect to rights in RFC - 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. + 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 - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. + any standard or specification contained in an IETF Document. Please + address the information to the IETF at ietf-ipr@ietf.org. - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + 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. - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress". + 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.