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/ |