doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc5495.txt b/doc/rfc/rfc5495.txt
new file mode 100644
index 0000000..340ebf1
--- /dev/null
+++ b/doc/rfc/rfc5495.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                              D. Li
+Request for Comments: 5495                                        J. Gao
+Category: Informational                                           Huawei
+                                                        A. Satyanarayana
+                                                                   Cisco
+                                                             S. Bardalai
+                                                                 Fujitsu
+                                                              March 2009
+
+
+                          Description of the
+     Resource Reservation Protocol - Traffic-Engineered (RSVP-TE)
+                      Graceful Restart Procedures
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   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 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.
+
+   This document may contain material from IETF Documents or IETF
+   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.
+
+
+
+
+
+
+
+
+
+Li, et al.                   Informational                      [Page 1]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+Abstract
+
+   The Hello message for the Resource Reservation Protocol (RSVP) has
+   been defined to establish and maintain basic signaling node
+   adjacencies for Label Switching Routers (LSRs) participating in a
+   Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network.
+   The Hello message has been extended for use in Generalized MPLS
+   (GMPLS) networks for state recovery of control channel or nodal
+   faults.
+
+   The GMPLS protocol definitions for RSVP also allow a restarting node
+   to learn which label it previously allocated for use on a Label
+   Switched Path (LSP).
+
+   Further RSVP protocol extensions have been defined to enable a
+   restarting node to recover full control plane state by exchanging
+   RSVP messages with its upstream and downstream neighbors.
+
+   This document provides an informational clarification of the control
+   plane procedures for a GMPLS network when there are multiple node
+   failures, and describes how full control plane state can be recovered
+   in different scenarios where the order in which the nodes restart is
+   different.
+
+   This document does not define any new processes or procedures.  All
+   protocol mechanisms are already defined in the referenced documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Informational                      [Page 2]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Existing Procedures for Single Node Restart .....................4
+      2.1. Procedures Defined in RFC 3473 .............................4
+      2.2. Procedures Defined in RFC 5063 .............................5
+   3. Multiple Node Restart Scenarios .................................6
+   4. RSVP State ......................................................7
+   5. Procedures for Multiple Node Restart ............................7
+      5.1. Procedures for the Normal Node .............................8
+      5.2. Procedures for the Restarting Node .........................8
+           5.2.1. Procedures for Scenario 1 ...........................8
+           5.2.2. Procedures for Scenario 2 ...........................9
+           5.2.3. Procedures for Scenario 3 ..........................11
+           5.2.4. Procedures for Scenario 4 ..........................12
+           5.2.5. Procedures for Scenario 5 ..........................12
+      5.3. Consideration of the Reuse of Data Plane Resources ........12
+      5.4. Consideration of Management Plane Intervention ............13
+   6. Clarification of Restarting Node Procedure .....................13
+   7. Security Considerations ........................................15
+   8. Acknowledgments ................................................16
+   9. References .....................................................17
+      9.1. Normative References ......................................17
+      9.2. Informative References ....................................17
+
+1.  Introduction
+
+   The Hello message for the Resource Reservation Protocol (RSVP) has
+   been defined to establish and maintain basic signaling node
+   adjacencies for Label Switching Routers (LSRs) participating in a
+   Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network
+   [RFC3209].  The Hello message has been extended for use in
+   Generalized MPLS (GMPLS) networks for state recovery of control
+   channel or nodal faults through the exchange of the Restart_Cap
+   Object [RFC3473].
+
+   The GMPLS protocol definitions for RSVP [RFC3473] also allow a
+   restarting node to learn which label it previously allocated for use
+   on a Label Switched Path (LSP) through the Recovery_Label Object
+   carried on a Path message sent to a restarting node from its upstream
+   neighbor.
+
+   Further RSVP protocol extensions have been defined [RFC5063] to
+   perform graceful restart and to enable a restarting node to recover
+   full control plane state by exchanging RSVP messages with its
+   upstream and downstream neighbors.  State previously transmitted to
+   the upstream neighbor (principally, the downstream label) is
+   recovered from the upstream neighbor on a Path message (using the
+
+
+
+Li, et al.                   Informational                      [Page 3]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+   Recovery_Label Object as described in [RFC3473]).  State previously
+   transmitted to the downstream neighbor (including the upstream label,
+   interface identifiers, and the explicit route) is recovered from the
+   downstream neighbor using a RecoveryPath message.
+
+   [RFC5063] also extends the Hello message to exchange information
+   about the ability to support the RecoveryPath message.
+
+   The examples and procedures in [RFC3473] and [RFC5063] focus on the
+   description of a single node restart when adjacent network nodes are
+   operative.  Although the procedures are equally applicable to multi-
+   node restarts, no detailed explanation is provided for such a case.
+
+   This document provides an informational clarification of the control
+   plane procedures for a GMPLS network when there are multiple node
+   failures, and describes how full control plane state can be recovered
+   in different scenarios where the order in which the nodes restart is
+   different.
+
+   This document does not define any new processes or procedures.  All
+   protocol mechanisms already defined in [RFC3473] and [RFC5063] are
+   definitive.
+
+2.  Existing Procedures for Single Node Restart
+
+   This section documents for information the existing procedures
+   defined in [RFC3473] and [RFC5063].  Those documents are definitive,
+   and the description here is non-normative.  It is provided for
+   informational clarification only.
+
+2.1.  Procedures Defined in RFC 3473
+
+   In the case of nodal faults, the procedures for the restarting node
+   and the procedures for the neighbor of a restarting node are applied
+   to the corresponding nodes.  These procedures, described in
+   [RFC3473], are summarized as follows:
+
+   For the Restarting Node:
+
+   1) Tells its neighbors that state recovery is supported using the
+      Hello message.
+
+   2) Recovers its RSVP state with the help of a Path message, received
+      from its upstream neighbor, that carries the Recovery_Label
+      Object.
+
+   3) For bidirectional LSPs, uses the Upstream_Label Object on the
+      received Path message to recover the corresponding RSVP state.
+
+
+
+Li, et al.                   Informational                      [Page 4]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+   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
+      forwarding state in the data plane does exist, the forwarding
+      state is bound to the LSP associated with the message, and the
+      related forwarding state should be considered as valid and
+      refreshed.  In addition, if the node is not the tail-end of the
+      LSP, the incoming label on the downstream interface is retrieved
+      from the forwarding state on the restarting node and set in the
+      Upstream_Label Object in the Path message sent to the downstream
+      neighbor.
+
+   For the Neighbor of a Restarting Node:
+
+   1) Sends a Path message with the Recovery_Label Object containing a
+      label value corresponding to the label value received in the most
+      recently received corresponding Resv message.
+
+   2) Resumes refreshing Path state with the restarting node.
+
+   3) Resumes refreshing Resv state with the restarting node.
+
+2.2.  Procedures Defined in RFC 5063
+
+   A new message is introduced in [RFC5063] called the RecoveryPath
+   message.  This message is sent by the downstream neighbor of a
+   restarting node to convey the contents of the last received Path
+   message back to the restarting node.
+
+   The restarting node will receive the Path message with the
+   Recovery_Label Object from its upstream neighbor and/or the
+   RecoveryPath message from its downstream neighbor.  The full RSVP
+   state of the restarting node can be recovered from these two
+   messages.
+
+   The following state can be recovered from the received Path message:
+
+   o Upstream data interface (from RSVP_Hop Object)
+
+   o Label on the upstream data interface (from Recovery_Label Object)
+
+   o Upstream label for bidirectional LSP (from Upstream_Label Object)
+
+   The following state can be recovered from the received RecoveryPath
+   message:
+
+   o Downstream data interface (from RSVP_Hop Object)
+
+   o Label on the downstream data interface (from Recovery_Label Object)
+
+
+
+Li, et al.                   Informational                      [Page 5]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+   o Upstream direction label for bidirectional LSP (from Upstream_Label
+     Object)
+
+   The other objects originally exchanged on Path and Resv messages can
+   be recovered from the regular Path and Resv refresh messages, or from
+   the RecoveryPath.
+
+3.  Multiple Node Restart Scenarios
+
+   We define the following terms for the different node types:
+
+   Restarting - The node has restarted.  Communication with its neighbor
+      nodes is restored, and its RSVP state is under recovery.
+
+   Delayed Restarting - The node has restarted, but the communication
+      with a neighbor node is interrupted (for example, the neighbor
+      node needs to restart).
+
+   Normal - The normal node is the fully operational neighbor of a
+      restarting or delayed restarting node.
+
+   There are five scenarios for multi-node restart.  We will focus on
+   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 Node
+   D.
+
+          +-----+  Path  +-----+  Path  +-----+  Path  +-----+
+          | PSB |------->| PSB |------->| PSB |------->| PSB |
+          |     |        |     |        |     |        |     |
+          | RSB |<-------| RSB |<-------| RSB |<-------| RSB |
+          +-----+  Resv  +-----+  Resv  +-----+  Resv  +-----+
+          Node A         Node B         Node C         Node D
+
+                   Figure 1: Two Neighbor Nodes Restart
+
+   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
+      restarting node, and Node C is a delayed restarting node.
+
+   2) A restarting node with upstream delayed restarting node.  For
+      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.
+
+   3) A restarting node with downstream and upstream delayed restarting
+      nodes.  For example, in Figure 1, Node A is a normal node, Nodes B
+      and D are delayed restarting nodes, and Node C is a restarting
+      node.
+
+
+
+
+Li, et al.                   Informational                      [Page 6]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+   4) A restarting ingress node with downstream delayed restarting node.
+      For example, in Figure 1, Node A is a restarting node and Node B
+      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
+   node may think the downstream node is a delayed restarting node, or
+   vice versa.
+
+   Note that if multiple nodes that are not neighbors are restarted, the
+   restart procedures could be applied as multiple separated restart
+   procedures that are exactly the same as the procedures described in
+   [RFC3473] and [RFC5063].  Therefore, these scenarios are not
+   described in this document.  For example, in Figure 1, Node A and
+   Node C are normal nodes, and Node B and Node D are restarting nodes;
+   therefore, Node B could be restarted through Node A and Node C, while
+   Node D could be restarted through Node C separately.
+
+4.  RSVP State
+
+   For each scenario, the RSVP state that needs to be recovered at the
+   restarting nodes are the Path State Block (PSB) and Resv State Block
+   (RSB), which are created when the node receives the corresponding
+   Path message and Resv message.
+
+   According to [RFC2209], how to construct the PSB and RSB is really an
+   implementation issue.  In fact, there is no requirement to maintain
+   separate PSB and RSB data structures.  In GMPLS, there is a much
+   closer tie between Path and Resv state so it is possible to combine
+   the information into a single state block (the LSP state block).  On
+   the other hand, if point-to-multipoint is supported, it may be
+   convenient to maintain separate upstream and downstream state.  Note
+   that the PSB and RSB are not upstream and downstream state since the
+   PSB is responsible for receiving a Path from upstream and sending a
+   Path to downstream.
+
+   Regardless of how the RSVP state is implemented, on recovery there
+   are two logical pieces of state to be recovered and these correspond
+   to the PSB and RSB.
+
+5.  Procedures for Multiple Node Restart
+
+   In this document, all the nodes are assumed to have the graceful
+   restart capabilities that are described in [RFC3473] and [RFC5063].
+
+
+
+
+Li, et al.                   Informational                      [Page 7]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+5.1.  Procedures for the Normal Node
+
+   When the downstream normal node detects its neighbor restarting, it
+   must send a RecoveryPath message for each LSP associated with the
+   restarting node for which it has previously sent a Resv message and
+   which has not been torn down.
+
+   When the upstream normal node detects its neighbor restarting, it
+   must send a Path message with a Recovery_Label Object containing a
+   label value corresponding to the label value received in the most
+   recently received corresponding Resv message.
+
+   This document does not modify the procedures for the normal node,
+   which are described in [RFC3473] and [RFC5063].
+
+5.2.  Procedures for the Restarting Node
+
+   This document does not modify the procedures for the restarting node,
+   which are described in [RFC3473] and [RFC5063].
+
+5.2.1.  Procedures for Scenario 1
+
+   After the restarting node restarts, it starts a Recovery Timer.  Any
+   RSVP state that has not been resynchronized when the Recovery Timer
+   expires should be cleared.
+
+   At the restarting node (Node B in the example), full
+   resynchronization with the upstream neighbor (Node A) is possible
+   because Node A is a normal node.  The upstream Path information is
+   recovered from the Path message received from Node A.  Node B also
+   recovers the upstream Resv information (that it had previously sent
+   to Node A) from the Recovery_Label Object carried in the Path message
+   received from Node A, but, obviously, some information (like the
+   Recorded_Route Object) will be missing from the new Resv message
+   generated by Node B and cannot be supplied until the downstream
+   delayed restarting node (Node C) restarts and sends a Resv.
+
+   After the upstream Path information and upstream Resv information
+   have been recovered by Node B, the normal refresh procedure with
+   upstream Node A should be started.
+
+   As per [RFC5063], the restarting node (Node B) would normally expect
+   to receive a RecoveryPath message from its downstream neighbor (Node
+   C).  It would use this to recover the downstream Path information,
+   and would subsequently send a Path message to its downstream neighbor
+   and receive a Resv message.  But in this scenario, because the
+   downstream neighbor has not restarted yet, Node B detects the
+   communication with
+
+
+
+Li, et al.                   Informational                      [Page 8]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+   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
+   Section 9.3 of [RFC3473] and may run a Restart Timer to wait for the
+   downstream neighbor (Node C) to restart.  If its downstream neighbor
+   (Node C) has not restarted before the timer expires, the
+   corresponding LSPs may be torn down according to local policy
+   [RFC3473].  Note, however, that the Restart Time value suggested in
+   [RFC3473] is based on the previous Hello message exchanged with the
+   node that has not restarted yet (Node C).  Since this time value is
+   unlikely to be available to the restarting node (Node B), a
+   configured time value must be used if the timer is operated.
+
+   The RSVP state must be reconciled with the retained data plane state
+   if the cross-connect information can be retrieved from the data
+   plane.  In the event of any mismatches, local policy will dictate the
+   action that must be taken, which could include:
+
+   - reprogramming the data plane
+
+   - sending an alert to the management plane
+
+   - tearing down the control plane state for the LSP
+
+   In the case that the delayed restarting node never comes back and a
+   Restart Timer is not used to automatically tear down LSPs, the LSPs
+   can be tidied up through the control plane using a PathTear from the
+   upstream node (Node A).  Note that if Node C restarts after this
+   operation, the RecoveryPath message that it sends to Node B will not
+   be matched with any state on Node B and will receive a PathTear as
+   its response, resulting in the teardown of the LSP at all downstream
+   nodes.
+
+5.2.2.  Procedures for Scenario 2
+
+   In this case, the restarting node (Node C) can recover full
+   downstream state from its downstream neighbor (Node D), which is a
+   normal node.  The downstream Path state can be recovered from the
+   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 a
+   Resv message from which Node C can reconstruct the downstream Resv
+   state.
+
+   After the downstream Path information and downstream Resv information
+   have been recovered in Node C, the normal refresh procedure with
+   downstream Node D should be started.
+
+
+
+
+Li, et al.                   Informational                      [Page 9]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+   The restarting node would normally expect to resynchronize with its
+   upstream neighbor to re-learn the upstream Path and Resv state, but
+   in this scenario, because the upstream neighbor (Node B) has not
+   restarted yet, the restarting node (Node C) detects that the
+   communication with upstream neighbor (Node B) is interrupted.  The
+   restarting node (Node C) follows the procedures in Section 9.3 of
+   [RFC3473] and may run a Restart Timer to wait for the upstream
+   neighbor (Node B) to restart.  If its upstream neighbor (Node B) has
+   not restarted before the Restart Timer expires, the corresponding
+   LSPs may be torn down according to local policy [RFC3473].  Note,
+   however, that the Restart Time value suggested in [RFC3473] is based
+   on the previous Hello message exchanged with the node that has not
+   restarted yet (Node B).  Since this time value is unlikely to be
+   available to the restarting node (Node C), a configured time value
+   must be used if the timer is operated.
+
+   Note that no Resv message is sent to the upstream neighbor (Node B),
+   because it has not restarted.
+
+   The RSVP state must be reconciled with the retained data plane state
+   if the cross-connect information can be retrieved from the data
+   plane.
+
+   In the event of any mismatches, local policy will dictate the action
+   that must be taken, which could include:
+
+   - reprogramming the data plane
+
+   - sending an alert to the management plane
+
+   - tearing down the control plane state for the LSP
+
+   In the case that the delayed restarting node never comes back and a
+   Restart Timer is not used to automatically tear down LSPs, the LSPs
+   cannot be tidied up through the control plane using a PathTear from
+   the upstream node (Node A), because there is no control plane
+   connectivity to Node C from the upstream direction.  There are two
+   possibilities in [RFC3473]:
+
+   - Management action may be taken at the restarting node to tear the
+     LSP.  This will result in the LSP being removed from Node C and a
+     PathTear being sent downstream to Node D.
+
+   - Management action may be taken at any downstream node (for example,
+     Node D), resulting in a PathErr message with the Path_State_Removed
+     flag set being sent to Node C to tear the LSP state.
+
+
+
+
+
+Li, et al.                   Informational                     [Page 10]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+   Note that if Node B restarts after this operation, the Path message
+   that it sends to Node C will not be matched with any state on Node C
+   and will be treated as a new Path message, resulting in LSP setup.
+   Node C should use the labels carried in the Path message (in the
+   Upstream_Label Object and in the Recovery_Label Object) to drive its
+   label allocation, but may use other labels according to normal LSP
+   setup rules.
+
+5.2.3.  Procedures for Scenario 3
+
+   In this example, the restarting node (Node C) is isolated.  Its
+   upstream and downstream neighbors have not restarted.
+
+   The restarting node (Node C) follows the procedures in Section 9.3 of
+   [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
+   Timer expires, the corresponding LSPs may be torn down according to
+   local policy [RFC3473].  Note, however, that the Restart Time values
+   suggested in [RFC3473] are based on the previous Hello message
+   exchanged with the nodes that have not restarted yet.  Since these
+   time values are unlikely to be available to the restarting node (Node
+   C), a configured time value must be used if the timer is operated.
+
+   During the Recovery Time, if the upstream delayed restarting node has
+   restarted, the procedure for scenario 1 can be applied.
+
+   During the Recovery Time, if the downstream delayed restarting node
+   has restarted, the procedure for scenario 2 can be applied.
+
+   In the case that neither delayed restarting node ever comes back and
+   a Restart Timer is not used to automatically tear down LSPs,
+   management intervention is required to tidy up the control plane and
+   the data plane on the node that is waiting for the failed device to
+   restart.
+
+   If the downstream delayed restarting node restarts after the cleanup
+   of LSPs at Node C, the RecoveryPath message from Node D will be
+   responded to with a PathTear message.  If the upstream delayed
+   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,
+   but the setup will fail because Node D cannot be reached; Node C will
+   respond with a PathErr message.  Since this happens to Node B during
+   its restart processing, it should follow the rules of [RFC5063] and
+   tear down the LSP.
+
+
+
+
+
+
+
+Li, et al.                   Informational                     [Page 11]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+5.2.4.  Procedures for Scenario 4
+
+   When the ingress node (Node A) restarts, it does not know which LSPs
+   it caused to be created.  Usually, however, this information is
+   retrieved from the management plane or from the configuration
+   requests stored in non-volatile form in the node in order to recover
+   the LSP state.
+
+   Furthermore, if the downstream node (Node B) is a normal node,
+   according to the procedures in [RFC5063], the ingress will receive a
+   RecoveryPath message and will understand that it was the ingress of
+   the LSP.
+
+   However, in this scenario, the downstream node is a delayed
+   restarting node, so Node A must either rely on the information from
+   the management plane or stored configuration, or it must wait for
+   Node B to restart.
+
+   In the event that Node B never restarts, management plane
+   intervention is needed at Node A to clean up any LSP control plane
+   state restored from the management plane or from local configuration,
+   and to release any data plane resources.
+
+5.2.5.  Procedures for Scenario 5
+
+   In this scenario, the egress node (Node D) restarts, and its upstream
+   neighbor (Node C) has not restarted.  In this case, the egress node
+   may have no control plane state relating to the LSPs.  It has no
+   downstream neighbor to help it and no management plane or
+   configuration information, although there will be data plane state
+   for the LSP.  The egress node must simply wait until its upstream
+   neighbor restarts and gives it the information in Path messages
+   carrying Recovery_Label Objects.
+
+5.3.  Consideration of the Reuse of Data Plane Resources
+
+   Fundamental to the processes described above is an understanding that
+   data plane resources may remain in use (allocated and cross-
+   connected) when control plane state has not been fully resynchronized
+   because some control plane nodes have not restarted.
+
+   It is assumed that these data plane resources might be carrying
+   traffic and should not be reconfigured except through application of
+   operator-configured policy, or as a direct result of operator action.
+
+   In particular, new LSP setup requests from the control plane or the
+   management plane should not be allowed to use data plane resources
+
+
+
+
+Li, et al.                   Informational                     [Page 12]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+   that are still in use.  Specific action must first be taken to
+   release the resources.
+
+5.4.  Consideration of Management Plane Intervention
+
+   The management plane must always retain the ability to control data
+   plane resources and to override the control plane.  In this context,
+   the management plane must always be able to release data plane
+   resources that were previously in place for use by control-plane-
+   established LSPs.  Further, the management plane must always be able
+   to instruct any control plane node to tear down any LSP.
+
+   Operators should be aware of the risks of misconnection that could be
+   caused by careless manipulation from the management plane of in-use
+   data plane resources.
+
+6.  Clarification of Restarting Node Procedure
+
+   According to the current graceful restart procedure [RFC3473], after
+   a node restarts its control plane, it needs its upstream node to send
+   a PATH message with a recovery label in order to synchronize its RSVP
+   state.  If the restarted control plane becomes operational quickly,
+   the upstream node may not detect the restarting of the downstream
+   node and, therefore, may send a PATH message without a recovery
+   label, causing errors and unwanted connection deletion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Informational                     [Page 13]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+     N1               N2
+     |                |
+     |                X (Restart start)
+     | HELLO          |
+     |--------------->|
+     |                |
+     | SRefresh       |
+     |--------------->|
+     |                |
+     | HELLO          |
+     |--------------->|
+     |                |
+     |                X (Restart complete)
+     | SRefresh       |
+     |--------------->|
+     | NACK           |
+     |<---------------|
+     | Path without   |
+     | recovery label |
+     |--------------->|
+     |                X (resource allocation failed because the
+     |                | resources are in use)
+     |  PathErr       |
+     |<---------------|
+     |  PathTear      |
+     |--------------->|
+     X(LSP deletion)  X (LSP deletion)
+     |                |
+
+            Figure 2: Message Flow for Accidental LSP Deletion
+
+   The sequence diagram above depicts one scenario where the LSP may get
+   deleted.
+
+   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
+   SRefresh message.  This NACK causes a Path refresh message to be
+   generated, but there is no Recovery_Label because N1 does 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
+   the resources because they are still in use.  This causes a PathErr
+   message to be generated, which may lead to the teardown of the LSP.
+
+   To resolve the aforementioned problem, the following procedures,
+   which are implicit in [RFC3473] and [RFC5063], should be followed.
+   These procedures work together with the recovery procedures
+   documented in [RFC3473].  Here, it is assumed that the restarting
+
+
+
+Li, et al.                   Informational                     [Page 14]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+   node and the neighboring node(s) support the Hello extension as
+   documented in [RFC3209] as well as the recovery procedures documented
+   in [RFC3473].
+
+   After a node restarts its control plane, it should ignore and
+   silently drop all RSVP-TE messages (except Hello messages) it
+   receives from any neighbor to which no HELLO session has been
+   established.
+
+   The restarting node should follow [RFC3209] to establish Hello
+   sessions with its neighbors, after its control plane becomes
+   operational.
+
+   The restarting node resumes processing of RSVP-TE messages sent from
+   each neighbor to which the Hello session has been established.
+
+7.  Security Considerations
+
+   This document clarifies the procedures defined in [RFC3473] and
+   [RFC5063] to be performed on RSVP agents that neighbor one or more
+   restarting RSVP agents.  It does not introduce any new procedures
+   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
+   particular, where one or more nodes carrying one or more LSPs are
+   restarted due to external attacks, the procedures defined in
+   [RFC5063] and described in this document provide the ability for the
+   restarting RSVP agents to recover the RSVP state in each restarting
+   node corresponding to the LSPs, with the least possible perturbation
+   to the rest of the network.  These procedures can be considered to
+   provide mechanisms by which the GMPLS network can recover from
+   physical attacks or from attacks on remotely controlled power
+   supplies.
+
+   The procedures described are such that only the neighboring RSVP
+   agents should notice the restart of a node, and hence only they need
+   to perform additional processing.  This allows for a network with
+   active LSPs to recover LSP state gracefully from an external attack,
+   without perturbing the data/forwarding plane state and without
+   propagating the error condition in the control or data plane.  In
+   other words, the effect of the restart (which might be the result of
+   an attack) does not spread into the network.
+
+   Note that concern has been expressed about the vulnerability of a
+   restarting node to false messages received from its neighbors.  For
+   example, a restarting node might receive a false Path message with a
+
+
+
+
+
+Li, et al.                   Informational                     [Page 15]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+   Recovery_Label Object from an upstream neighbor, or a false
+   RecoveryPath message from its downstream neighbor.  This situation
+   might arise in one of four cases:
+
+   - The message is spoofed and does not come from the neighbor at all.
+
+   - The message has been modified as it was traveling from the
+     neighbor.
+
+   - The neighbor is defective and has generated a message in error.
+
+   - The neighbor has been subverted and has a "rogue" RSVP agent.
+
+   The first two cases may be handled using standard RSVP authentication
+   and integrity procedures [RFC3209], [RFC3473].  If the operator is
+   particularly worried, the control plane may be operated using IPsec
+   [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411].
+
+   Protection against defective or rogue RSVP implementations is
+   generally hard-to-impossible.  Neighbor-to-neighbor authentication
+   and integrity validation is, by definition, ineffective in these
+   situations.  For example, if a neighbor node sends a Resv during
+   normal LSP setup, and if that message carries a Generalized_Label
+   Object carrying an incorrect label value, then the receiving LSR will
+   use the supplied value and the LSP will be set up incorrectly.
+   Alternatively, if a Path message is modified by an upstream LSR to
+   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 wrong
+   destination.  Furthermore, the upstream LSR could disguise this fact
+   by modifying the recorded route reported in the Resv message.  Thus,
+   these issues are in no way specific to the restart case, do not cause
+   any greater or different problems from the normal case, and do not
+   warrant specific security measures applicable to restart scenarios.
+
+   Note that the RSVP Policy_Data Object [RFC2205] provides a scope by
+   which secure end-to-end checks could be applied.  However, very
+   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
+   networks.
+
+8.  Acknowledgments
+
+   We would like to thank Adrian Farrel, Dimitri Papadimitriou, and Lou
+   Berger for their useful comments.
+
+
+
+
+
+
+Li, et al.                   Informational                     [Page 16]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2209]  Braden, R. and L. Zhang, "Resource ReSerVation Protocol
+              (RSVP) -- Version 1 Message Processing Rules", RFC 2209,
+              September 1997.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, December 2001.
+
+   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Resource ReserVation
+              Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
+              3473, January 2003.
+
+   [RFC5063]  Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to
+              GMPLS Resource Reservation Protocol (RSVP) Graceful
+              Restart", RFC 5063, October 2007.
+
+9.2.  Informative References
+
+   [MPLS-SEC] Fang, L., "Security Framework for MPLS and GMPLS
+              Networks", Work in Progress, November 2008.
+
+   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, September 1997.
+
+   [RFC2411]  Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
+              Document Roadmap", RFC 2411, November 1998.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
+              2005.
+
+   [RFC4306]  Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+              Protocol", RFC 4306, December 2005.
+
+   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation
+              Requirements for Encapsulating Security Payload (ESP) and
+              Authentication Header (AH)", RFC 4835, April 2007.
+
+
+
+
+
+
+Li, et al.                   Informational                     [Page 17]
+
+RFC 5495          RSVP-TE Graceful Restart Procedures      February 2009
+
+
+Authors' Addresses
+
+   Dan Li
+   Huawei Technologies
+   F3-5-B R&D Center, Huawei Base,
+   Shenzhen 518129, China
+
+   Phone: +86 755 28970230
+   EMail: danli@huawei.com
+
+
+   Jianhua Gao
+   Huawei Technologies
+   F3-5-B R&D Center, Huawei Base,
+   Shenzhen 518129, China
+
+   Phone: +86 755 28972902
+   EMail: gjhhit@huawei.com
+
+
+   Arun Satyanarayana
+   Cisco Systems
+   170 West Tasman Dr
+   San Jose, CA 95134, USA
+
+   Phone: +1 408 853-3206
+   EMail: asatyana@cisco.com
+
+
+   Snigdho C. Bardalai
+   Fujitsu Network Communications
+   2801 Telecom Parkway
+   Richardson, Texas 75082, USA
+
+   Phone: +1 972 479 2951
+   EMail: snigdho.bardalai@us.fujitsu.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Informational                     [Page 18]
+