draft-ietf-ccamp-gr-description-04.txt | rfc5495.txt | |||
---|---|---|---|---|
Network Working Group Dan Li (Huawei) | ||||
Internet Draft Jianhua Gao (Huawei) | ||||
Arun Satyanarayana (Cisco) | ||||
Snigdho C. Bardalai (Fujitsu) | ||||
Intended Status: Informational | ||||
Expires: July 21, 2009 January 21, 2009 | ||||
Description of the RSVP-TE Graceful Restart Procedures | Network Working Group D. Li | |||
Request for Comments: 5495 J. Gao | ||||
draft-ietf-ccamp-gr-description-04.txt | Category: Informational Huawei | |||
A. Satyanarayana | ||||
Cisco | ||||
S. Bardalai | ||||
Fujitsu | ||||
Description of the | ||||
Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) | ||||
Graceful Restart Procedures | ||||
Status of this Memo | Status of This Memo | |||
This Internet-Draft is submitted to IETF in full conformance with | This memo provides information for the Internet community. It does | |||
the provisions of BCP 78 and BCP 79. | not specify an Internet standard of any kind. Distribution of this | |||
memo is unlimited. | ||||
Internet-Drafts are working documents of the Internet Engineering | Copyright Notice | |||
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 | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
months and may be updated, replaced, or obsoleted by other documents | document authors. All rights reserved. | |||
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 | This document is subject to BCP 78 and the IETF Trust's Legal | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | Provisions Relating to IETF Documents in effect on the date of | |||
publication of this document (http://trustee.ietf.org/license-info). | ||||
Please review these documents carefully, as they describe your rights | ||||
and restrictions with respect to this document. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | This document may contain material from IETF Documents or IETF | |||
http://www.ietf.org/shadow.html. | Contributions published or made publicly available before November | |||
10, 2008. The person(s) controlling the copyright in some of this | ||||
material may not have granted the IETF Trust the right to allow | ||||
modifications of such material outside the IETF Standards Process. | ||||
Without obtaining an adequate license from the person(s) controlling | ||||
the copyright in such materials, this document may not be modified | ||||
outside the IETF Standards Process, and derivative works of it may | ||||
not be created outside the IETF Standards Process, except to format | ||||
it for publication as an RFC or to translate it into languages other | ||||
than English. | ||||
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. | |||
network. The Hello message has been extended for use in Generalized | The Hello message has been extended for use in Generalized MPLS | |||
MPLS (GMPLS) network for state recovery of control channel or nodal | (GMPLS) networks for state recovery of control channel or nodal | |||
faults. | faults. | |||
GMPLS protocol definitions for RSVP also allow a restarting node to | The GMPLS protocol definitions for RSVP also allow a restarting node | |||
learn the label that it previously allocated for use on a Label | to learn which label it previously allocated for use on a Label | |||
Switching Path (LSP). | Switched Path (LSP). | |||
Further RSVP protocol extensions have been defined to enable a | Further RSVP protocol extensions have been defined to enable a | |||
restarting node to recover full control plane state by exchanging | restarting node to recover full control plane state by exchanging | |||
RSVP messages with its upstream and downstream neighbors. | RSVP messages with its upstream and downstream neighbors. | |||
This document provides an informational clarification of the | This document provides an informational clarification of the control | |||
control plane procedures for a GMPLS network when there are | plane procedures for a GMPLS network when there are multiple node | |||
multiple node failures, and describes how full control plane state | failures, and describes how full control plane state can be recovered | |||
can be recovered in different scenarios where the order in which | in different scenarios where the order in which the nodes restart is | |||
the nodes restart is different. | different. | |||
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 RFC 3473 .............................4 | |||
2.2. Procedures Defined in [RFC5063]............................5 | 2.2. Procedures Defined in RFC 5063 .............................5 | |||
3. Multiple Node Restart Scenarios..............................5 | 3. Multiple Node Restart Scenarios .................................6 | |||
4. RSVP State...................................................7 | 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 .............................8 | |||
5.2. Procedures for the Restarting Node.........................7 | 5.2. Procedures for the Restarting Node .........................8 | |||
5.2.1. Procedures for Scenario 1................................8 | 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 ..........................11 | |||
5.2.4. Procedures for Scenario 4...............................11 | 5.2.4. Procedures for Scenario 4 ..........................12 | |||
5.2.5. Procedures for Scenario 5...............................12 | 5.2.5. Procedures for Scenario 5 ..........................12 | |||
5.3. Consideration of Re-Use of Data Plane Resources...........12 | 5.3. Consideration of the Reuse of Data Plane Resources ........12 | |||
5.4. Consideration of Management Plane Intervention............12 | 5.4. Consideration of Management Plane Intervention ............13 | |||
6. Clarification of Restarting Node Procedure..................13 | 6. Clarification of Restarting Node Procedure .....................13 | |||
7. Security Considerations.....................................14 | 7. Security Considerations ........................................15 | |||
8. IANA Considerations.........................................16 | 8. Acknowledgments ................................................16 | |||
9. Acknowledgments.............................................16 | 9. References .....................................................17 | |||
10. References.................................................16 | 9.1. Normative References ......................................17 | |||
10.1. Normative References.....................................16 | 9.2. Informative References ....................................17 | |||
10.2. Informative References...................................16 | ||||
11. Author's Addresses.........................................17 | ||||
12. Full Copyright Statement...................................18 | ||||
13. Intellectual Property Statement............................18 | ||||
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 | |||
network [RFC3209]. The Hello message has been extended for use in | [RFC3209]. The Hello message has been extended for use in | |||
Generalized MPLS (GMPLS) network for state recovery of control | Generalized MPLS (GMPLS) networks for state recovery of control | |||
channel or nodal faults through the exchange of the Restart | channel or nodal faults through the exchange of the Restart_Cap | |||
Capabilities object [RFC3473]. | Object [RFC3473]. | |||
GMPLS protocol definitions for RSVP [RFC3473] also allow a | The GMPLS protocol definitions for RSVP [RFC3473] also allow a | |||
restarting node to learn the label that it previously allocated for | restarting node to learn which label it previously allocated for use | |||
use on a Label Switching Path (LSP) through the RECOVERY_LABEL | on a Label Switched Path (LSP) through the Recovery_Label Object | |||
object carried on a Path message sent to a restarting node from its | carried on a Path message sent to a restarting node from its upstream | |||
upstream neighbor. | neighbor. | |||
Further RSVP protocol extensions have been defined [RFC5063] to | Further RSVP protocol extensions have been defined [RFC5063] to | |||
perform graceful restart and to enable a restarting node to recover | perform graceful restart and to enable a restarting node to recover | |||
full control plane state by exchanging RSVP messages with its | full control plane state by exchanging RSVP messages with its | |||
upstream and downstream neighbors. State previously transmitted to | upstream and downstream neighbors. State previously transmitted to | |||
the upstream neighbor (principally the downstream label) is | the upstream neighbor (principally, the downstream label) is | |||
recovered from the upstream neighbor on a Path message (using the | recovered from the upstream neighbor on a Path message (using the | |||
RECOVERY_LABEL object as described in [RFC3473]). State previously | Recovery_Label Object as described in [RFC3473]). State previously | |||
transmitted to the downstream neighbor (including the upstream | transmitted to the downstream neighbor (including the upstream label, | |||
label, interface identifiers, and the explicit route) is recovered | interface identifiers, and the explicit route) is recovered from the | |||
from the downstream neighbor using a RecoveryPath message. | downstream neighbor using a RecoveryPath message. | |||
[RFC5063] also extends the Hello message to exchange information | [RFC5063] also extends the Hello message to exchange information | |||
about the ability to support the RecoveryPath message. | about the ability to support the RecoveryPath message. | |||
The examples and procedures in [RFC3473] and [RFC5063] focus on the | The examples and procedures in [RFC3473] and [RFC5063] focus on the | |||
description of a single node restart when adjacent network nodes | description of a single node restart when adjacent network nodes are | |||
are operative. Although the procedures are equally applicable to | operative. Although the procedures are equally applicable to multi- | |||
multi-node restarts, no detailed explanation is provided. | node restarts, no detailed explanation is provided for such a case. | |||
This document provides an informational clarification of the | This document provides an informational clarification of the control | |||
control plane procedures for a GMPLS network when there are | plane procedures for a GMPLS network when there are multiple node | |||
multiple node failures, and describes how full control plane state | failures, and describes how full control plane state can be recovered | |||
can be recovered in different scenarios where the order in which | in different scenarios where the order in which the nodes restart is | |||
the nodes restart is different. | different. | |||
This document does not define any new processes or procedures. All | This document does not define any new processes or procedures. All | |||
protocol mechanisms already defined in [RFC3473] and [RFC5063] are | protocol mechanisms already defined in [RFC3473] and [RFC5063] are | |||
definitive. | definitive. | |||
2. Existing Procedures for Single Node Restart | 2. Existing Procedures for Single Node Restart | |||
This section documents for information the existing procedures | This section documents for information the existing procedures | |||
defined in [RFC3473] and [RFC5063]. Those documents are definitive, | defined in [RFC3473] and [RFC5063]. Those documents are definitive, | |||
and the description here is non-normative. It is provided for | and the description here is non-normative. It is provided for | |||
informational clarification only. | informational clarification only. | |||
2.1. Procedures Defined in [RFC3473] | 2.1. Procedures Defined in RFC 3473 | |||
In the case of nodal faults, the procedures for the restarting node | In the case of nodal faults, the procedures for the restarting node | |||
and the procedures for the neighbor of a restarting node are | and the procedures for the neighbor of a restarting node are applied | |||
applied to the corresponding nodes. These procedures described in | to the corresponding nodes. These procedures, described in | |||
[RFC3473] are summarized as follows: | [RFC3473], are summarized as follows: | |||
For the Restarting Node: | For the Restarting Node: | |||
1) Tells its neighbors that state recovery is supported using the | 1) Tells its neighbors that state recovery is supported using the | |||
Hello message; | Hello message. | |||
2) Recover its RSVP state with the help of a Path message received | 2) Recovers its RSVP state with the help of a Path message, received | |||
from its upstream neighbor carrying the RECOVERY_LABEL object; | from its upstream neighbor, that carries the Recovery_Label | |||
Object. | ||||
3) For bidirectional LSPs, the UPSTREAM_LABEL object on the received | 3) For bidirectional LSPs, uses the Upstream_Label Object on the | |||
Path message is used to recover the corresponding RSVP state; | received Path message to recover the corresponding RSVP state. | |||
4) If the corresponding forwarding state in the data plane does not | 4) If the corresponding forwarding state in the data plane does not | |||
exist, the node treats this as a setup for a new LSP. If the | exist, the node treats this as a setup for a new LSP. If the | |||
forwarding state in the data plane exists, the forwarding state is | forwarding state in the data plane does exist, the forwarding | |||
bound to the LSP associated with the message, and related forwarding | state is bound to the LSP associated with the message, and the | |||
state should be considered as valid and refreshed. In addition, if | related forwarding state should be considered as valid and | |||
the node is not the tail-end of the LSP, the incoming label on the | refreshed. In addition, if the node is not the tail-end of the | |||
downstream interface is retrieved from the forwarding state on the | LSP, the incoming label on the downstream interface is retrieved | |||
restarting node and set in the UPSTREAM_LABEL object in the Path | from the forwarding state on the restarting node and set in the | |||
message sent to the downstream neighbor. | Upstream_Label Object in the Path message sent to the downstream | |||
neighbor. | ||||
For the Neighbor of a restarting node: | For the Neighbor of a Restarting Node: | |||
1) Sends a Path message with RECOVERY_LABEL object containing a label | 1) Sends a Path message with the Recovery_Label Object containing a | |||
value corresponding to the label value received in the most recently | label value corresponding to the label value received in the most | |||
received corresponding Resv message; | recently received corresponding Resv message. | |||
2) Resumes refreshing Path state with the restarting node; | 2) Resumes refreshing Path state with the restarting node. | |||
3) Resumes refreshing Resv state with the restarting node. | 3) Resumes refreshing Resv state with the restarting node. | |||
2.2. Procedures Defined in [RFC5063] | 2.2. Procedures Defined in RFC 5063 | |||
A new message is introduced in [RFC5063] called the RecoveryPath | A new message is introduced in [RFC5063] called the RecoveryPath | |||
message. The message is sent by the downstream neighbor of a | message. This message is sent by the downstream neighbor of a | |||
restarting node to convey the contents of the last received Path | restarting node to convey the contents of the last received Path | |||
message back to the restarting node. | message back to the restarting node. | |||
The restarting node will receive the Path message with the | The restarting node will receive the Path message with the | |||
RECOVERY_LABEL object from its upstream neighbor, and/or the | Recovery_Label Object from its upstream neighbor and/or the | |||
RecoveryPath message from its downstream neighbor. The full RSVP | RecoveryPath message from its downstream neighbor. The full RSVP | |||
state of the restarting node can be recovered from these two | state of the restarting node can be recovered from these two | |||
messages. | messages. | |||
The following state can be recovered from the received Path message: | The following state can be recovered from the received Path message: | |||
o Upstream data interface (from RSVP_HOP object) | o Upstream data interface (from RSVP_Hop Object) | |||
o Label on the upstream data interface (from RECOVERY_LABEL object) | o Label on the upstream data interface (from Recovery_Label Object) | |||
o Upstream label for bidirectional LSP (from UPSTREAM_LABEL object) | o Upstream label for bidirectional LSP (from Upstream_Label Object) | |||
The following state can be recovered from the received RecoveryPath | The following state can be recovered from the received RecoveryPath | |||
message: | message: | |||
o Downstream data interface (from RSVP_HOP object) | o Downstream data interface (from RSVP_Hop Object) | |||
o Label on the downstream data interface (from RECOVERY_LABEL object) | ||||
o Upstream direction label for bidirectional LSP (from | o Label on the downstream data interface (from Recovery_Label Object) | |||
UPSTREAM_LABEL object) | o Upstream direction label for bidirectional LSP (from Upstream_Label | |||
Object) | ||||
The other objects also can be recovered either from the regular | The other objects originally exchanged on Path and Resv messages can | |||
Path and Resv messages, or from the RecoveryPath message. | be recovered from the regular Path and Resv refresh messages, or from | |||
the RecoveryPath. | ||||
3. Multiple Node Restart Scenarios | 3. Multiple Node Restart Scenarios | |||
We define the following terms for the different node types: | We define the following terms for the different node types: | |||
Restarting - The node has restarted; communication with its | Restarting - The node has restarted. Communication with its neighbor | |||
neighbor nodes is restored, its RSVP state is under recovery. | nodes is restored, and its RSVP state is under recovery. | |||
Delayed Restarting - The node has restarted, but the communication | Delayed Restarting - The node has restarted, but the communication | |||
with a neighbor node is interrupted (for example, the neighbor node | with a neighbor node is interrupted (for example, the neighbor | |||
needs to restart). | node needs to restart). | |||
Normal - The normal node is the fully operational neighbor of a | Normal - The normal node is the fully operational neighbor of a | |||
restarting or delayed restarting node. | restarting or delayed restarting node. | |||
There are five scenarios for multi-node restart. We will focus on | There are five scenarios for multi-node restart. We will focus on | |||
the different positions of a restarting node. As shown in Figure 1, | the different positions of a restarting node. As shown in Figure 1, | |||
an LSP starts from Node A, traverses Nodes B and C, and ends at | an LSP starts from Node A, traverses Nodes B and C, and ends at Node | |||
Node D. | D. | |||
+-----+ Path +-----+ Path +-----+ Path +-----+ | +-----+ Path +-----+ Path +-----+ Path +-----+ | |||
| PSB |------->| PSB |------->| PSB |------->| PSB | | | PSB |------->| PSB |------->| PSB |------->| PSB | | |||
| | | | | | | | | | | | | | | | | | |||
| RSB |<-------| RSB |<-------| RSB |<-------| RSB | | | RSB |<-------| RSB |<-------| RSB |<-------| RSB | | |||
+-----+ Resv +-----+ Resv +-----+ Resv +-----+ | +-----+ Resv +-----+ Resv +-----+ Resv +-----+ | |||
Node A Node B Node C Node D | Node A Node B Node C Node D | |||
Figure 1 Two neighbor nodes restart | ||||
1) A Restarting node with downstream Delayed Restarting node. For | Figure 1: Two Neighbor Nodes Restart | |||
example, in Figure 1, Nodes A and D are Normal nodes, Node B is a | ||||
Restarting node, and Node C is a Delayed Restarting node. | ||||
2) A Restarting node with upstream Delayed Restarting node. For | 1) A restarting node with downstream delayed restarting node. For | |||
example, in Figure 1, Nodes A and D are Normal nodes, Node B is a | example, in Figure 1, Nodes A and D are normal nodes, Node B is a | |||
Delayed Restarting node, and Node C is a Restarting node. | restarting node, and Node C is a delayed restarting node. | |||
3) A Restarting node with downstream and upstream Delayed Restarting | 2) A restarting node with upstream delayed restarting node. For | |||
nodes. For example, in Figure 1, Node A is a Normal node, Nodes B and | example, in Figure 1, Nodes A and D are normal nodes, Node B is a | |||
D are Delayed Restarting nodes, and Node C is a Restarting node. | delayed restarting node, and Node C is a restarting node. | |||
4) A Restarting Ingress node with downstream Delayed Restarting node. | 3) A restarting node with downstream and upstream delayed restarting | |||
For example, in Figure 1, Node A is a Restarting node, and Node B is | nodes. For example, in Figure 1, Node A is a normal node, Nodes B | |||
a Delayed Restarting node. Nodes C and D are Normal nodes. | and D are delayed restarting nodes, and Node C is a restarting | |||
node. | ||||
5) A Restarting Egress node with upstream Delayed Restarting node. | 4) A restarting ingress node with downstream delayed restarting node. | |||
For example, in Figure 1, Nodes A and B are Normal nodes, Node C is a | For example, in Figure 1, Node A is a restarting node and Node B | |||
Delayed Restarting node, and Node D is a Restarting node. | is a delayed restarting node. Nodes C and D are normal nodes. | |||
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 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 multiple nodes which are not neighbors are restarted, | Note that if multiple nodes that are not neighbors are restarted, the | |||
the restart Procedures could be applied as multiple separated | restart procedures could be applied as multiple separated restart | |||
restart procedures which are exactly the same as the procedures | procedures that are exactly the same as the procedures described in | |||
described in [RFC3473] and [RFC5063]. Therefore, these scenarios | [RFC3473] and [RFC5063]. Therefore, these scenarios are not | |||
are not described in this document. For example, in Figure 1, Node | described in this document. For example, in Figure 1, Node A and | |||
A and Node C are normal nodes, and Node B and Node D are restarting | Node C are normal nodes, and Node B and Node D are restarting nodes; | |||
nodes, so Node B could be restarted through Node A and Node C, | therefore, Node B could be restarted through Node A and Node C, while | |||
meanwhile, Node D could be restarted through Node C separately. | 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 that needs to be recovered at the | |||
restarting nodes are Path State Block (PSB) and Resv State Block | restarting nodes are the 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 | |||
an implementation issue. In fact, there is no requirement to | implementation issue. In fact, there is no requirement to maintain | |||
maintain separate PSB and RSB data structures. And in GMPLS, there | separate PSB and RSB data structures. In GMPLS, there is a much | |||
is a much closer tie between Path and Resv state so it is possible | closer tie between Path and Resv state so it is possible to combine | |||
to combine the information into a single state block (the LSP state | the information into a single state block (the LSP state block). On | |||
block). On the other hand, if point to multi-point is supported, it | the other hand, if point-to-multipoint is supported, it may be | |||
may be convenient to maintain separate upstream and downstream | convenient to maintain separate upstream and downstream state. Note | |||
state. Note that the PSB and RSB are not upstream and downstream | that the PSB and RSB are not upstream and downstream state since the | |||
state since the PSB is responsible for receiving a Path from | PSB is responsible for receiving a Path from upstream and sending a | |||
upstream and sending a Path to downstream. | 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 | |||
correspond to the PSB and RSB. | 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 that are described in [RFC3473] and [RFC5063]. | |||
5.1. Procedures for the Normal Node | 5.1. Procedures for the Normal Node | |||
When the downstream Normal node detects its neighbor restarting, it | When the downstream normal node detects its neighbor restarting, it | |||
must send a RecoveryPath message for each LSP associated with the | must send a RecoveryPath message for each LSP associated with the | |||
restarting node for which it has previously sent a Resv message and | restarting node for which it has previously sent a Resv message and | |||
which has not been torn down. | which has not been torn down. | |||
When the upstream Normal node detects its neighbor restarting, it | When the upstream normal node detects its neighbor restarting, it | |||
must send a Path message with RECOVERY_LABEL object containing a | must send a Path message with a Recovery_Label Object containing a | |||
label value corresponding to the label value received in the most | label value corresponding to the label value received in the most | |||
recently received corresponding Resv message. | recently received corresponding Resv message. | |||
This document does not modify the procedures for the Normal node | This document does not modify the procedures for the normal node, | |||
which are described in [RFC3473] and [RFC5063]. | which are described in [RFC3473] and [RFC5063]. | |||
5.2. Procedures for the Restarting Node | 5.2. Procedures for the Restarting Node | |||
This document does not modify the procedures for the Restarting | This document does not modify the procedures for the restarting node, | |||
node which are described in [RFC3473] and [RFC5063]. | which are described in [RFC3473] and [RFC5063]. | |||
5.2.1. Procedures for Scenario 1 | 5.2.1. Procedures for Scenario 1 | |||
After the Restarting node restarts, it starts a Recovery Timer. Any | After the restarting node restarts, it starts a Recovery Timer. Any | |||
RSVP state that has not been resynchronized when the Recovery Timer | RSVP state that has not been resynchronized when the Recovery Timer | |||
expires, should be cleared. | expires should be cleared. | |||
At the Restarting node (Node B in the example), full | At the restarting node (Node B in the example), full | |||
resynchronization with the upstream neighbor (Node A) is possible | resynchronization with the upstream neighbor (Node A) is possible | |||
because Node A is a Normal node. The upstream Path information is | because Node A is a normal node. The upstream Path information is | |||
recovered from the Path message received from Node A. Node B also | recovered from the Path message received from Node A. Node B also | |||
recovers the upstream Resv information (that it had previously sent | recovers the upstream Resv information (that it had previously sent | |||
to Node A) from the RECOVERY_LABEL object carried in the Path | to Node A) from the Recovery_Label Object carried in the Path message | |||
message received from Node A, but, obviously, some information | received from Node A, but, obviously, some information (like the | |||
(like the Recorded Route Object) will be missing from the new Resv | Recorded_Route Object) will be missing from the new Resv message | |||
message generated by Node B, and can not be supplied until the | generated by Node B and cannot be supplied until the downstream | |||
downstream Delayed Restarting node (Node C) restarts and sends a | delayed restarting node (Node C) restarts and sends a Resv. | |||
Resv. | ||||
After the upstream Path information and upstream Resv information | After the upstream Path information and upstream Resv information | |||
has been recovered by Node B, the normal refresh procedure with the | have been recovered by Node B, the normal refresh procedure with | |||
upstream Node A should be started. | upstream Node A should be started. | |||
As per [RFC5063], the Restarting node (Node B) would normally | As per [RFC5063], the restarting node (Node B) would normally expect | |||
expect to receive a RecoveryPath message from its downstream | to receive a RecoveryPath message from its downstream neighbor (Node | |||
neighbor (Node C). It would use this to recover the downstream Path | C). It would use this to recover the downstream Path information, | |||
information, and would subsequently send a Path message to its | and would subsequently send a Path message to its downstream neighbor | |||
downstream neighbor and receive a Resv message. But in this | and receive a Resv message. But in this scenario, because the | |||
scenario, because the downstream neighbor has not restarted yet, | downstream neighbor has not restarted yet, Node B detects the | |||
Node B detects the communication with Node C is interrupted and | communication with | |||
must wait before resynchronizing with its downstream neighbor. | Node C is interrupted and must wait before resynchronizing with its | |||
downstream neighbor. | ||||
In this case, the Restarting node (Node B) follows the procedures | In this case, the restarting node (Node B) follows the procedures in | |||
in section 9.3 of [RFC3473] and may run a Restart Timer to wait for | Section 9.3 of [RFC3473] and may run a Restart Timer to wait for the | |||
the downstream neighbor (Node C) to restart. If its downstream | downstream neighbor (Node C) to restart. If its downstream neighbor | |||
neighbor (Node C) has not restarted before the timer expires the | (Node C) has not restarted before the timer expires, the | |||
corresponding LSPs may be torn down according to local policy | corresponding LSPs may be torn down according to local policy | |||
[RFC3473]. Note, however, that the Restart Time value suggested in | [RFC3473]. Note, however, that the Restart Time value suggested in | |||
[RFC3473] is based on the previous Hello message exchanged with the | [RFC3473] is based on the previous Hello message exchanged with the | |||
node that has not restarted yet (Node C). Since this time value is | node that has not restarted yet (Node C). Since this time value is | |||
unlikely to be available to the restarting node (Node B), a | unlikely to be available to the restarting node (Node B), a | |||
configured time value must be used if the timer is operated. | configured time value must be used if the timer is operated. | |||
The RSVP state must be reconciled with the retained data plane | The RSVP state must be reconciled with the retained data plane state | |||
state if the cross-connect information can be retrieved from the | if the cross-connect information can be retrieved from the data | |||
data plane. In the event of any mismatches, local policy will | plane. In the event of any mismatches, local policy will dictate the | |||
dictate the action that must be taken which could include: | action that must be taken, which could include: | |||
- reprogramming the data plane | - reprogramming the data plane | |||
- sending an alert to the management plane | - sending an alert to the management plane | |||
- tearing down the control plane state for the LSP. | - tearing down the control plane state for the LSP | |||
In the case that the Delayed Restarting node never comes back, and | In the case that the delayed restarting node never comes back and a | |||
where a Restart Timer is not used to automatically tear down LSPs, | Restart Timer is not used to automatically tear down LSPs, the LSPs | |||
the LSPs can be tidied up through the control plane using a | can be tidied up through the control plane using a PathTear from the | |||
PathTear from the upstream node (Node A). Note that if Node C | upstream node (Node A). Note that if Node C restarts after this | |||
restarts after this operation, the RecoveryPath message that it | operation, the RecoveryPath message that it sends to Node B will not | |||
sends to Node B will not be matched with any state on Node B and | be matched with any state on Node B and will receive a PathTear as | |||
will receive a PathTear as its response resulting in the teardown | its response, resulting in the teardown of the LSP at all downstream | |||
of the LSP at all downstream nodes. | nodes. | |||
5.2.2. Procedures for Scenario 2 | 5.2.2. Procedures for Scenario 2 | |||
In this case, the Restarting node (Node C) can recover full | In this case, the restarting node (Node C) can recover full | |||
downstream state from its downstream neighbor (Node D) which is a | downstream state from its downstream neighbor (Node D), which is a | |||
Normal node. The downstream Path state can be recovered from the | normal node. The downstream Path state can be recovered from the | |||
RecoveryPath message which is sent by Node D. This allows Node C to | RecoveryPath message, which is sent by Node D. This allows Node C to | |||
send a Path refresh message to Node D, and Node D will respond with | send a Path refresh message to Node D, and Node D will respond with a | |||
a Resv message from which Node C can reconstruct the downstream | Resv message from which Node C can reconstruct the downstream Resv | |||
Resv state. | state. | |||
After the downstream Path information and downstream Resv | After the downstream Path information and downstream Resv information | |||
information has been recovered in Node C, the normal refresh | have been recovered in Node C, the normal refresh procedure with | |||
procedure with downstream Node D should be started. | downstream Node D should be started. | |||
The Restarting node would normally expect to resynchronize with its | The restarting node would normally expect to resynchronize with its | |||
upstream neighbor to re-learn the upstream Path and Resv state, but | upstream neighbor to re-learn the upstream Path and Resv state, but | |||
in this scenario, because the upstream neighbor (Node B) has not | in this scenario, because the upstream neighbor (Node B) has not | |||
restarted yet, the Restarting node (Node C) detects that the | restarted yet, the restarting node (Node C) detects that the | |||
communication with upstream neighbor (Node B) is interrupted. The | communication with upstream neighbor (Node B) is interrupted. The | |||
Restarting node (Node C) follows the procedures in section 9.3 of | restarting node (Node C) follows the procedures in Section 9.3 of | |||
[RFC3473] and may run a Restart Timer to wait the upstream neighbor | [RFC3473] and may run a Restart Timer to wait for the upstream | |||
(Node B) to restart. If its upstream neighbor (Node B) has not | neighbor (Node B) to restart. If its upstream neighbor (Node B) has | |||
restarted before the Restart Timer expires, the corresponding LSPs | not restarted before the Restart Timer expires, the corresponding | |||
may be torn down according to local policy [RFC3473]. Note, however, | LSPs may be torn down according to local policy [RFC3473]. Note, | |||
that the Restart Time value suggested in [RFC3473] is based on the | however, that the Restart Time value suggested in [RFC3473] is based | |||
previous Hello message exchanged with the node that has not | on the previous Hello message exchanged with the node that has not | |||
restarted yet (Node B). Since this time value is unlikely to be | restarted yet (Node B). Since this time value is unlikely to be | |||
available to the restarting node (Node C), a configured time value | available to the restarting node (Node C), a configured time value | |||
must be used if the timer is operated. | must be used if the timer is operated. | |||
Note that no Resv message is sent to the upstream neighbor (Node B) | Note that no Resv message is sent to the upstream neighbor (Node B), | |||
because it has not restarted. | because it has not restarted. | |||
The RSVP state must be reconciled with the retained data plane | The RSVP state must be reconciled with the retained data plane state | |||
state if the cross-connect information can be retrieved from the | if the cross-connect information can be retrieved from the data | |||
data plane. | plane. | |||
In the event of any mismatches, local policy will dictate the | In the event of any mismatches, local policy will dictate the action | |||
action that must be taken which could include: | that must be taken, which could include: | |||
- reprogramming the data plane | - reprogramming the data plane | |||
- sending an alert to the management plane | - sending an alert to the management plane | |||
- tearing down the control plane state for the LSP. | - tearing down the control plane state for the LSP | |||
In the case that the Delayed Restarting node never comes back, and | In the case that the delayed restarting node never comes back and a | |||
where a Restart Timer is not used to automatically tear down LSPs, | Restart Timer is not used to automatically tear down LSPs, the LSPs | |||
the LSPs cannot be tidied up through the control plane using a | cannot be tidied up through the control plane using a PathTear from | |||
PathTear from the upstream node (Node A), because there is no | the upstream node (Node A), because there is no control plane | |||
control plane connectivity to Node C from the upstream direction. | connectivity to Node C from the upstream direction. There are two | |||
There are two possibilities in [RFC3473]: | 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, | |||
example, Node D) resulting in a PathErr message with the | Node D), resulting in a PathErr message with the Path_State_Removed | |||
Path_State_Removed flag set being sent to Node C to tear the LSP | 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 | |||
C and will be treated as a new Path message resulting in LSP setup. | 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 | |||
its label allocation, but may use other labels according to normal | label allocation, but may use other labels according to normal LSP | |||
LSP setup rules. | setup rules. | |||
5.2.3. Procedures for Scenario 3 | 5.2.3. Procedures for Scenario 3 | |||
In this example, the Restarting node (Node C) is isolated. It's | In this example, the restarting node (Node C) is isolated. Its | |||
upstream and downstream neighbors have not restarted. | upstream and downstream neighbors have not restarted. | |||
The Restarting node (Node C) follows the procedures in section 9.3 | The restarting node (Node C) follows the procedures in Section 9.3 of | |||
of [RFC3473] and may run a Restart Timer for each of its neighbors | [RFC3473] and may run a Restart Timer for each of its neighbors | |||
(Nodes B and D). If a neighbor has not restarted before its Restart | (Nodes B and D). If a neighbor has not restarted before its Restart | |||
Timer expires, the corresponding LSPs may be torn down according to | Timer expires, the corresponding LSPs may be torn down according to | |||
local policy [RFC3473]. Note, however, that the Restart Time values | local policy [RFC3473]. Note, however, that the Restart Time values | |||
suggested in [RFC3473] are based on the previous Hello message | suggested in [RFC3473] are based on the previous Hello message | |||
exchanged with the nodes that have not restarted yet. Since these | exchanged with the nodes that have not restarted yet. Since these | |||
time values are unlikely to be available to the restarting node | time values are unlikely to be available to the restarting node (Node | |||
(Node C), a configured time value must be used if the timer is | C), a configured time value must be used if the timer is operated. | |||
operated. | ||||
During the Recovery Time, if the upstream Delayed Restarting node | During the Recovery Time, if the upstream delayed restarting node has | |||
has restarted, the procedure for scenario 1 can be applied. | restarted, the procedure for scenario 1 can be applied. | |||
During the Recovery Time, if the downstream Delayed Restarting node | During the Recovery Time, if the downstream delayed restarting node | |||
has restarted, the procedure for scenario 2 can be applied. | has restarted, the procedure for scenario 2 can be applied. | |||
In the case that neither Delayed Restarting node ever comes back, | In the case that neither delayed restarting node ever comes back and | |||
and where a Restart Timer is not used to automatically tear down | a Restart Timer is not used to automatically tear down LSPs, | |||
LSPs, management intervention is required to tidy up the control | management intervention is required to tidy up the control plane and | |||
plane and the data plane on the node that is waiting for the failed | the data plane on the node that is waiting for the failed device to | |||
device to restart. | restart. | |||
If the downstream Delayed Restarting node restarts after the | If the downstream delayed restarting node restarts after the cleanup | |||
cleanup of LSPs at Node C, the RecoveryPath message from Node D | of LSPs at Node C, the RecoveryPath message from Node D will be | |||
will be responded with a PathTear message. If the upstream Delayed | responded to with a PathTear message. If the upstream delayed | |||
Restarting node restarts after the cleanup of LSPs at Node C, the | restarting node restarts after the cleanup of LSPs at Node C, the | |||
Path message from Node B will be treated as a new LSP setup request, | Path message from Node B will be treated as a new LSP setup request, | |||
but the setup will fail because Node D cannot be reached - Node C | but the setup will fail because Node D cannot be reached; Node C will | |||
will respond with a PathErr message. Since this happens to Node B | respond with a PathErr message. Since this happens to Node B during | |||
during its restart processing, it should follow the rules of | its restart processing, it should follow the rules of [RFC5063] and | |||
[RFC5063] and tear down the LSP. | tear down the LSP. | |||
5.2.4. Procedures for Scenario 4 | 5.2.4. Procedures for Scenario 4 | |||
When the Ingress node (Node A) restarts, it does not know which | When the ingress node (Node A) restarts, it does not know which LSPs | |||
LSPs it caused to be created. Usually, however, this information is | it caused to be created. Usually, however, this information is | |||
retrieved from the management plane or from the configuration | retrieved from the management plane or from the configuration | |||
requests stored in non-volatile form in the node in order to | requests stored in non-volatile form in the node in order to recover | |||
recover the LSP state. | the LSP state. | |||
Furthermore, if the downstream node (Node B) is a Normal node, | Furthermore, if the downstream node (Node B) is a normal node, | |||
according to the procedures in [RFC5063], the ingress will receive | according to the procedures in [RFC5063], the ingress will receive a | |||
a RecoveryPath message and will understand that it was the ingress | RecoveryPath message and will understand that it was the ingress of | |||
of the LSP. | the LSP. | |||
However, in this scenario, the downstream node is a Delayed | However, in this scenario, the downstream node is a delayed | |||
Restarting node, so Node A must rely on the information from the | restarting node, so Node A must either rely on the information from | |||
management plane or stored configuration, or it must wait for Node | the management plane or stored configuration, or it must wait for | |||
B to restart. | Node B to restart. | |||
In the event that Node B never restarts, management plane | In the event that Node B never restarts, management plane | |||
intervention is needed at Node A to clean up any LSP control plane | intervention is needed at Node A to clean up any LSP control plane | |||
state restored from the management plane or from local | state restored from the management plane or from local configuration, | |||
configuration, and to release any data plane resources. | and to release any data plane resources. | |||
5.2.5. Procedures for Scenario 5 | 5.2.5. Procedures for Scenario 5 | |||
In this scenario the Egress node (Node D) restarts, and its | In this scenario, the egress node (Node D) restarts, and its upstream | |||
upstream neighbor (Node C) has not restarted. In this case, the | neighbor (Node C) has not restarted. In this case, the egress node | |||
Egress node may have no control plane state relating to the LSPs. | may have no control plane state relating to the LSPs. It has no | |||
It has no downstream neighbor to help it, and no management plane | downstream neighbor to help it and no management plane or | |||
or configuration information, although there will be data plane | configuration information, although there will be data plane state | |||
state for the LSP. The Egress node must simply wait until its | for the LSP. The egress node must simply wait until its upstream | |||
upstream neighbor restarts and gives it the information as Path | neighbor restarts and gives it the information in Path messages | |||
messages carrying RECOVERY_LABEL objects. | carrying Recovery_Label Objects. | |||
5.3. Consideration of Re-Use of Data Plane Resources | 5.3. Consideration of the Reuse of Data Plane Resources | |||
Fundamental to the processes described above is an understanding | Fundamental to the processes described above is an understanding that | |||
that data plane resources may remain in use (allocated and cross- | data plane resources may remain in use (allocated and cross- | |||
connected) when control plane state has not been fully | connected) when control plane state has not been fully resynchronized | |||
resynchronized because some control plane nodes have not restarted. | because some control plane nodes have not restarted. | |||
It is assumed that these data plane resources might be carrying | It is assumed that these data plane resources might be carrying | |||
traffic and should not be reconfigured except through application | traffic and should not be reconfigured except through application of | |||
of operator-configured policy, or as a direct result of operator | operator-configured policy, or as a direct result of operator action. | |||
action. | ||||
In particular, new LSP setup requests from the control plane or the | In particular, new LSP setup requests from the control plane or the | |||
management plane should not be allowed to use data plane resources | management plane should not be allowed to use data plane resources | |||
that are still in use. Specific action must first be taken to | that are still in use. Specific action must first be taken to | |||
release the resources. | release the resources. | |||
5.4. Consideration of Management Plane Intervention | 5.4. Consideration of Management Plane Intervention | |||
The management plane must always retain the ability to control data | The management plane must always retain the ability to control data | |||
plane resources and to over-ride the control plane. In this context, | plane resources and to override the control plane. In this context, | |||
the management plane must always be able to release data plane | the management plane must always be able to release data plane | |||
resources that were previously in place for use by control-plane | resources that were previously in place for use by control-plane- | |||
established LSPs. Further, the management plane must always be able | established LSPs. Further, the management plane must always be able | |||
to instruct any control plane node to tear down any LSP. | to instruct any control plane node to tear down any LSP. | |||
Operators should be aware of the risks of misconnection that could | Operators should be aware of the risks of misconnection that could be | |||
be caused by careless manipulation from the management plane of in- | caused by careless manipulation from the management plane of in-use | |||
use data plane resources. | data plane resources. | |||
6. Clarification of Restarting Node Procedure | 6. Clarification of Restarting Node Procedure | |||
According to the current graceful restart procedure [RFC3473], | According to the current graceful restart procedure [RFC3473], after | |||
after a node restarts its control plane, it needs its upstream node | a node restarts its control plane, it needs its upstream node to send | |||
to send PATH message with recovery label to synchronize its RSVP | a PATH message with a recovery label in order to synchronize its RSVP | |||
state. If the restarted control plane becomes operational quickly, | state. If the restarted control plane becomes operational quickly, | |||
the upstream node may not detect the restarting of downstream node | the upstream node may not detect the restarting of the downstream | |||
and therefore, may send a PATH message without recovery label | node and, therefore, may send a PATH message without a recovery | |||
causing errors and unwanted connection deletion. | label, causing errors and unwanted connection deletion. | |||
N1 N2 | N1 N2 | |||
| | | | | | |||
| X (Restart start) | | X (Restart start) | |||
| HELLO | | | HELLO | | |||
|--------------->| | |--------------->| | |||
| | | | | | |||
| SRefresh | | | SRefresh | | |||
|--------------->| | |--------------->| | |||
| | | | | | |||
skipping to change at page 13, line 43 | skipping to change at page 14, line 33 | |||
| recovery label | | | recovery label | | |||
|--------------->| | |--------------->| | |||
| X (resource allocation failed because the | | X (resource allocation failed because the | |||
| | resources 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 | ||||
The sequence diagram above depicts one scenario where the LSP may | Figure 2: Message Flow for Accidental LSP Deletion | |||
get deleted. | ||||
In this sequence N1 did not detect Hello failure and continues | The sequence diagram above depicts one scenario where the LSP may get | |||
sending SRefreshes which may get NACK'ed by N2 once restart | deleted. | |||
In this sequence, N1 does not detect Hello failure and continues | ||||
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 does not yet | |||
detect that N2 has restarted as Hello exchanges have not yet | detect that N2 has restarted, as Hello exchanges have not yet | |||
started. The Path message is treated as "new" and fails to allocate | started. The Path message is treated as "new" and fails to allocate | |||
the resources because they are still in use. This causes a PathErr | the resources because they are still in use. This causes a PathErr | |||
message to be generated which may lead to the tear down of the LSP. | message to be generated, which may lead to the teardown of the LSP. | |||
To resolve the aforementioned problem, the following procedures | To resolve the aforementioned problem, the following procedures, | |||
which are implicit in [RFC3473] and [RFC5063] should be followed. | which are implicit in [RFC3473] and [RFC5063], should be followed. | |||
These procedures work together with the recovery procedures | These procedures work together with the recovery procedures | |||
documented in [RFC3473]. Here, it is assumed that the restarting | documented in [RFC3473]. Here, it is assumed that the restarting | |||
node and the neighboring node(s) support Hello extension as | node and the neighboring node(s) support the Hello extension as | |||
documented in [RFC3209] and recovery procedures documented in | documented in [RFC3209] as well as the recovery procedures documented | |||
[RFC3473]. | in [RFC3473]. | |||
After a node restarts its control plane, it should ignore and | After a node restarts its control plane, it should ignore and | |||
silently drop all RSVP-TE messages, except Hello messages, it | silently drop all RSVP-TE messages (except Hello messages) it | |||
receives from any neighbor to which, no HELLO session has been | receives from any neighbor to which no HELLO session has been | |||
established. | established. | |||
The restarting node should follow [RFC3209] to establish Hello | The restarting node should follow [RFC3209] to establish Hello | |||
sessions with its neighbors, after its control plane becomes | sessions with its neighbors, after its control plane becomes | |||
operational. | operational. | |||
The restarting node resumes processing of RSVP-TE messages sent | The restarting node resumes processing of RSVP-TE messages sent from | |||
from each neighbor to which the Hello session has been established. | each neighbor to which the Hello session has been established. | |||
7. Security Considerations | 7. Security Considerations | |||
This document clarifies the procedures defined in [RFC3473] and | This document clarifies the procedures defined in [RFC3473] and | |||
[RFC5063] to be performed on RSVP agents that neighbor one or more | [RFC5063] to be performed on RSVP agents that neighbor one or more | |||
restarting RSVP agents. It does not introduce any new procedures | restarting RSVP agents. It does not introduce any new procedures | |||
and, therefore, does not introduce any new security risks or issues. | and, therefore, does not introduce any new security risks or issues. | |||
In the case of the control plane in general, and the RSVP agent in | In the case of the control plane in general, and the RSVP agent in | |||
particular, where one or more nodes carrying one or more LSPs are | particular, where one or more nodes carrying one or more LSPs are | |||
restarted due to external attacks, the procedures defined in | restarted due to external attacks, the procedures defined in | |||
[RFC5063] and described in this document provide the ability for | [RFC5063] and described in this document provide the ability for the | |||
the restarting RSVP agents to recover the RSVP state in each | restarting RSVP agents to recover the RSVP state in each restarting | |||
restarting node corresponding to the LSPs, with the least possible | node corresponding to the LSPs, with the least possible perturbation | |||
perturbation to the rest of the network. These procedures can be | to the rest of the network. These procedures can be considered to | |||
considered to provide mechanisms by which the GMPLS network can | provide mechanisms by which the GMPLS network can recover from | |||
recover from physical attacks or from attacks on remotely | physical attacks or from attacks on remotely controlled power | |||
controlled power supplies. | supplies. | |||
The procedures described are such that, only the neighboring RSVP | The procedures described are such that only the neighboring RSVP | |||
agents should notice the restart of a node, and hence only they | agents should notice the restart of a node, and hence only they need | |||
need to perform additional processing. This allows for a network | to perform additional processing. This allows for a network with | |||
with active LSPs to recover LSP state gracefully from an external | active LSPs to recover LSP state gracefully from an external attack, | |||
attack, without perturbing the data/forwarding plane state, and | without perturbing the data/forwarding plane state and without | |||
without propagating the error condition in the control or data | propagating the error condition in the control or data plane. In | |||
plane. In other words, the effect of the restart (which might be | other words, the effect of the restart (which might be the result of | |||
the result of an attack) does not spread into the network. | an attack) does not spread into the network. | |||
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 | |||
a Recovery Label object from an upstream neighbor, or a false | 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 traveling 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 | |||
authentication and integrity procedures [RFC3209], [RFC3473]. If | and integrity procedures [RFC3209], [RFC3473]. If the operator is | |||
the operator is particularly worried, the control plane may be | particularly worried, the control plane may be operated using IPsec | |||
operated using IPsec [RFC4301], [RFC4302], [RFC4835], [RFC4306], | [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411]. | |||
and [RFC2411]. | ||||
Protection against defective or rogue RSVP implementations is | Protection against defective or rogue RSVP implementations is | |||
generally hard to impossible. Neighbor-to-neighbor authentication | generally hard-to-impossible. Neighbor-to-neighbor authentication | |||
and integrity validation is, by definition, ineffective in these | and integrity validation is, by definition, ineffective in these | |||
situations. For example, if a neighbor node sends a Resv during | situations. For example, if a neighbor node sends a Resv during | |||
normal LSP setup, and if that message carries a GENERALIZED_LABEL | normal LSP setup, and if that message carries a Generalized_Label | |||
object carrying an incorrect label value, then the receiving LSR | Object carrying an incorrect label value, then the receiving LSR will | |||
will use the supplied value and the LSP will be set up incorrectly. | use the supplied value and the LSP will be set up incorrectly. | |||
Alternatively, if a Path message is modified by an upstream LSR to | Alternatively, if a Path message is modified by an upstream LSR to | |||
change the destination and explicit route, there is no way for the | change the destination and explicit route, there is no way for the | |||
downstream LSR to detect this, and the LSP may be set up to the | downstream LSR to detect this, and the LSP may be set up to the wrong | |||
wrong destination. Furthermore, the upstream LSR could disguise | destination. Furthermore, the upstream LSR could disguise this fact | |||
this fact by modifying the recorded route reported in the Resv | by modifying the recorded route reported in the Resv message. Thus, | |||
message. Thus, these issues are in no way specific to the restart | these issues are in no way specific to the restart case, do not cause | |||
case, do not cause any greater or different problems from the | any greater or different problems from the normal case, and do not | |||
normal case, and do not warrant specific security measure | warrant specific security measures applicable to restart scenarios. | |||
applicable to restart scenarios. | ||||
Note that the RSVP POLICY_DATA object [RFC2205] provides a scope by | Note that the RSVP Policy_Data Object [RFC2205] provides a scope by | |||
which secure end-to-end checks could be applied. However, very | which secure end-to-end checks could be applied. However, very | |||
little definition of the use of this object has been made to date. | little definition of the use of this object has been made to date. | |||
See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS | See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS | |||
networks. | networks. | |||
8. IANA Considerations | 8. Acknowledgments | |||
This document defines no new protocols or extensions and makes no | ||||
requests to IANA for registry management. | ||||
9. Acknowledgments | ||||
We would like to thank Adrian Farrel, Dimitri Papadimitriou, and | We would like to thank Adrian Farrel, Dimitri Papadimitriou, and Lou | |||
Lou Berger for their useful comments. | Berger for their useful comments. | |||
10. References | 9. References | |||
10.1. Normative References | 9.1. Normative References | |||
[RFC2209] R. Braden, L. Zhang, "Resource ReSerVation Protocol (RSVP) | [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol | |||
-- Version 1 Message Processing Rules", RFC 2209, September | (RSVP) -- Version 1 Message Processing Rules", RFC 2209, | |||
1997. | September 1997. | |||
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | |||
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., Ed., "Generalized Multi-Protocol Label | |||
(GMPLS) Signaling Resource ReserVation Protocol-Traffic | Switching (GMPLS) Signaling Resource ReserVation | |||
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. | Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC | |||
3473, January 2003. | ||||
[RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP | [RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to | |||
Graceful Restart", RFC 5063, September 2007. | GMPLS Resource Reservation Protocol (RSVP) Graceful | |||
Restart", RFC 5063, October 2007. | ||||
10.2. Informative References | 9.2. Informative References | |||
[MPLS-SEC] Fang, L., "Security Framework for MPLS and GMPLS Networks", | [MPLS-SEC] Fang, L., "Security Framework for MPLS and GMPLS | |||
draft-ietf-mpls-mpls-and-gmpls-security-framework, work in | Networks", Work in Progress, November 2008. | |||
progress. | ||||
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and S. | [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. | |||
Jamin, "Resource ReserVation Protocol -- Version 1 | Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | |||
Functional Specification", RFC 2205, September 1997. | Functional Specification", RFC 2205, September 1997. | |||
[RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document | [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security | |||
Roadmap", RFC 2411, November 1998. | Document Roadmap", RFC 2411, November 1998. | |||
[RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |||
Protocol", RFC 4301, December 2005. | Internet Protocol", RFC 4301, December 2005. | |||
[RFC4302] S. Kent, "IP Authentication Header", RFC 4302, December | [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December | |||
2005. | 2005. | |||
[RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", RFC | [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) | |||
4306, December 2005. | Protocol", RFC 4306, December 2005. | |||
[RFC4835] V. Manral, "Cryptographic Algorithm Implementation | [RFC4835] Manral, V., "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. Authors' Addresses | Authors' Addresses | |||
Dan Li | Dan Li | |||
Huawei Technologies | Huawei Technologies | |||
F3-5-B R&D Center, Huawei Base, | F3-5-B R&D Center, Huawei Base, | |||
Shenzhen 518129, China | Shenzhen 518129, China | |||
Phone: +86 755 28970230 | Phone: +86 755 28970230 | |||
Email: danli@huawei.com | EMail: danli@huawei.com | |||
Jianhua Gao | Jianhua Gao | |||
Huawei Technologies | Huawei Technologies | |||
F3-5-B R&D Center, Huawei Base, | F3-5-B R&D Center, Huawei Base, | |||
Shenzhen 518129, 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 | 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 | 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 | ||||
Copyright (c) 2009 IETF Trust and the persons identified as the | ||||
document authors. All rights reserved. | ||||
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. | ||||
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 THEREIN WILL NOT INFRINGE | ||||
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS | ||||
FOR A PARTICULAR PURPOSE. | ||||
13. Intellectual Property Statement | ||||
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 | ||||
any standard or specification contained in an IETF Document. Please | ||||
address the information to the IETF at ietf-ipr@ietf.org. | ||||
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. | ||||
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. | ||||
End of changes. 139 change blocks. | ||||
400 lines changed or deleted | 401 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/ |