CCAMP
TEAS Working Group                                            Xian Zhang
Internet-Draft                                        Haomian Zheng, Ed.
Intended Status: Informational                                    Huawei
Expires: June 11, August 3, 2015                               Rakesh Gandhi, Ed.
                                                               Zafar Ali
                                               Gabriele Maria Galimberti
                                                     Cisco Systems, Inc.
                                                        Pawel Brzozowski
                                                            ADVA Optical
                                                        December 8, 2014
                                                        January 30, 2015

    RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and
                             Resource Sharing-
                           based LSP Setup and Teardown

             draft-ietf-teas-gmpls-resource-sharing-proc-00 Sharing
             draft-ietf-teas-gmpls-resource-sharing-proc-01

Abstract

   In transport networks, there are requirements where Generalized
   Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme
   needs to employ restoration Label Switched Path (LSP) while keeping
   resources for the working and/or restoration protecting LSPs reserved in the
   network after the failure occurs.

   This document reviews how the LSP association is to be provided using
   Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
   signaling in the context of GMPLS end-
   to-end end-to-end recovery scheme when
   using restoration LSP where failed LSP is not torn down.

   This  In
   addition, this document compliments existing standards by explaining the
   missing pieces of information during clarifies the RSVP-TE signaling procedure
   in to
   support of resource sharing-based setup and teardown of LSPs as well as
   LSP setup/teardown in
   GMPLS-controlled circuit networks. reversion.  No new procedures or mechanisms extensions are defined by this document, and
   it is strictly informative in nature.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (c) 2014 2015 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. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Problem Statement . . . . . . . .  Overview . . . . . . . . . . . . . . .  4
     2.1. GMPLS Restoration . . . . . . . . . . . . . . . . . . . . .  4
       2.1.1.
     2.1.  1+R Restoration  . . . . . . . . . . . . . . . . . . . . .  4
       2.1.2.
     2.2.  1+1+R Restoration  . . . . . . . . . . . . . . . . . . . .  5
     2.2.
     2.3.  Resource Sharing-based Sharing By Restoration LSP Setup/Teardown . . .  . . . . . .  6
   3. RSVP-TE Signaling For Restoration LSP Association . . . . . . .  7
   4.  6
   3.  RSVP-TE Signaling For Resource Sharing During LSP
      Setup/Teardown  . . . . . . . Procedure  . . . . . . . . . . . . . . . . .  8
     4.1. LSPs with Identical Tunnel ID  6
     3.1.  Restoration LSP Association  . . . . . . . . . . . . . . .  8
       4.1.1.  6
     3.2.  Resource Sharing-based Restoration LSP Setup . . . . . . . . . . . . . . . . .  8
       4.1.2.  7
     3.3.  LSP Reversion  . . . . . . . . . . . . . . . . . . . . . 10
         4.1.2.1. .  8
       3.3.1.  Make-while-break Reversion . . . . . . . . . . . . 11
         4.1.2.2. Make-before-break Reversion . . . . . . . . . . . . 13
       4.1.3. Re-optimization LSP Setup and  8
       3.3.2.  Make-before-break Reversion  . . . . . . . . 15
     4.2. LSPs with Different Tunnel IDs  . . . . . . . . . . . . . . 15
   5.  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . . 16
   6. 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 16
   7. 11
   6.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . . 16
   8. 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1. 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2. 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   9. 12
   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 13

1.  Introduction

   Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] defines
   a set of protocols, including Open Shortest Path First - Traffic
   Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol -
   Traffic Engineering (RSVP-TE) [RFC3473].  These protocols can be used
   to create setup Label Switched Paths (LSPs) in a number of deployment
   scenarios with various transport technologies. networks.  The
   GMPLS protocol
   set extends MPLS, which supports only Packet Switch Capable (PSC) and
   Layer 2 Switch Capable interfaces (L2SC), MPLS to also cater for support interfaces capable of Time
   Division Multiplexing (TDM), Lambda Switching (LSC) and Fiber Switching (FSC). Switching.
   These switching technologies provide several protection schemes
   [RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N).

   Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
   signaling has been extended to support various GMPLS recovery schemes [RFC4872][RFC4873],
   schemes, such as end-to-end recovery [RFC4872] and segment recovery
   [RFC4873].  As described in [RFC6689], ASSOCIATION object can be used
   to establish Label
   Switched Paths (LSPs), typically identify the LSPs for working LSP and protecting LSP.
   [RFC4427] restoration using Association Type set to
   "Recovery" [RFC4872].  [RFC6689] Section 7 specifies various schemes 2.2 reviews the procedure
   for providing LSP associations for GMPLS recovery.

   In GMPLS end-to-end recovery and
   covers the schemes generally considered, restoration LSP is
   signaled after where the failure has been failed working LSP and/or protecting LSP
   are torn down.

   In GMPLS end-to-end recovery schemes generally considered,
   restoration LSP is signaled after the failure has been detected and
   notified on the working LSP.  In non-revertive recovery mode, working LSP is assumed
   to be removed from the network before restoration LSP is signaled.  For revertive recovery mode, a
   restoration LSP is signaled while working LSP and/or protecting LSP
   are not torn down in control plane due to a failure.  In transport
   networks, as working LSPs are typically signaled over a nominal path,
   service providers would like to keep resources associated with the
   working LSPs reserved.  This is to make sure that the service
   (working LSP) can use be reverted to the nominal path when the failure is
   repaired to provide deterministic behavior and guaranteed Service
   Level Agreement (SLA).  Consequently, revertive
   recovery mode is usually preferred by recovery schemes used in
   transport networks.

   The Make-Before-Break (MBB) mechanisms exploiting the Shared-Explicit
   (SE) reservation style can be employed in MPLS networks to avoid
   double booking of resource during the process of LSP re-optimization
   as specified in [RFC3209].  This method is also used in GMPLS-
   controlled networks [RFC4872] [RFC4873] for end-to-end and segment
   recovery of LSPs.  This was further generalized to support resource
   sharing oriented applications in MPLS networks as well as non-LSP
   contexts, as specified in [RFC6780].

   Due to the fact that the features of GMPLS-controlled networks
   (specifically for TDM, LSC and FSC),

   Following behaviors are not identical to that of fully documented in the
   MPLS networks, additional considerations existing
   standards for LSP associations, resource sharing based LSP association are needed.  As defined in [RFC4872] setup,
   teardown and being
   considered LSP reversion in this document, "fully dynamic rerouting switches normal
   traffic to an alternate transport networks:

   o  The procedure for providing LSP that is associations for the GMPLS
   recovery using restoration LSP where working and protecting LSPs are
   not even partially established
   only torn down after the working LSP failure occurs.  The new alternate route is selected at not clearly documented.

   o  In [RFC3209], the LSP head-end node, it may reuse resources of MBB method assumes the
   failed LSP at intermediate nodes old and may include additional
   intermediate nodes and/or links".  During new LSPs share
   the signaling procedure for
   resource sharing based LSP setup/teardown, SESSION object and signal Shared Explicit (SE) flag in
   SESSION_ATTRIBUTE object.  According to [RFC6689], ASSOCIATION object
   with Association Type "Resource sharing" enables the behaviors sharing of the nodes
   along the path may be
   resources across LSPs with different from that in the MPLS networks as
   well as the effect it may have on SESSION objects.  However,
   existing documents do not mention the traffic delivery. usage of SE flag for resource
   sharing with ASSOCIATION object.

   o  As described in [RFC6689], ASSOCIATION Object [RFC3209], Section 2.5, the purpose of make before
   break (MBB) is used "not to identify disrupt traffic, or adversely impact network
   operations while TE tunnel rerouting is in progress".  In transport
   networks, the
   LSPs for restoration using association type "Recovery" [RFC4872] label has a mapping into the data plane resource used
   and the nodes along the LSP need to send triggering commands to data
   plane for resource setting up cross-connections accordingly during the RSVP-TE
   signaling procedure.  Due to the nature of transport networks, node
   may not be able to fulfill this purpose when sharing resources in
   some scenarios.

   o  When using association type "Resource Sharing"
   [RFC4873].

   Following section describes the problem statements end-to-end recovery with revertive mode, methods for the GMPLS
   restoration
   LSP reversion and resource sharing based have not been described.

   This document reviews how the LSP setup and teardown.

2. Problem Statement

   Problem statements association is to be provided for the
   GMPLS end-to-end recovery when using restoration schemes and resource
   sharing-based LSP setup where working
   and teardown protecting LSP resources are described kept reserved in this section.

2.1. GMPLS Restoration

2.1.1. 1+R Restoration

   One example of the recovery scheme considered in network after
   the failure.  In addition, this document clarifies the signaling
   procedure for sharing resources during setup and teardown of LSPs as
   well as LSP reversion.  This document is 1+R
   recovery. strictly informative in
   nature and does not define any RSVP-TE signaling extensions.

2.  Overview

   The 1+R GMPLS end-to-end recovery is exemplified scheme, as defined in [RFC4872] and
   being considered in Figure 1.  In this
   example, working document, "fully dynamic rerouting switches
   normal traffic to an alternate LSP on path that is not even partially
   established only after the working LSP failure occurs.  The new
   alternate route is selected at the LSP head-end node, it may reuse
   resources of the failed LSP at intermediate nodes and may include
   additional intermediate nodes and/or links".  Two examples, 1+R and
   1+1+R are described in the following sections.

2.1.  1+R Restoration

   One example of the recovery scheme considered in this document is 1+R
   recovery.  The 1+R recovery is exemplified in Figure 1.  In this
   example, working LSP on path A-B-C-Z is pre-established.  Typically
   after a failure detection and notification on the working LSP, a
   second LSP on path A-H-I-J-Z is established as a restoration LSP.
   Unlike protection LSP, restoration LSP is signaled per need basis.

          +-----+    +-----+     +-----+     +-----+
          |  A  +----+  B  +-----+  C  +-----+  Z  |
          +--+--+    +-----+     +-----+     +--+--+
              \                                /
               \                              /
             +--+--+       +-----+        +--+--+
             |  H  +-------+  I  +--------+  J  |
             +-----+       +-----+        +-----+

          Figure 1: An Example of 1+R Recovery Scheme

   During failure switchover with 1+R recovery scheme, in general,
   working LSP resources are not released and so that working and
   restoration LSPs coexist in the network.  Nonetheless, working and
   restoration LSPs can share network resources.  Typically when failure
   is recovered on the working LSP, restoration LSP is no longer
   required and torn down (e.g., revertive mode).

2.1.2. down, while the traffic is reverted to the original
   working LSP.

2.2.  1+1+R Restoration

   Another example of the recovery scheme considered in this document is
   1+1+R.  In 1+1+R, a restoration LSP is signaled for the working LSP
   and/or the protecting LSP after the failure has been detected detected, and
   notified on the working LSP or the protecting LSP.  The 1+1+R
   this recovery is exemplified in Figure 2.

             +-----+       +-----+        +-----+
             |  D  +-------+  E  +--------+  F  |
             +--+--+       +-----+        +--+--+
               /                              \
              /                                \
          +--+--+    +-----+     +-----+     +--+--+
          |  A  +----+  B  +-----+  C  +-----+  Z  |
          +--+--+    +-----+     +-----+     +--+--+
              \                                /
               \                              /
             +--+--+       +-----+        +--+--+
             |  H  +-------+  I  +--------+  J  |
             +-----+       +-----+        +-----+

          Figure 2: An Example of 1+1+R Recovery Scheme

   In this example, working LSP on path A-B-C-Z and protecting LSP on
   path A-D-E-F-Z are pre-established.  After a failure detection and
   notification on a working LSP or protecting LSP, a third LSP on path
   A-H-I-J-Z is established as a restoration LSP.  The restoration LSP
   in this case provides protection against a second order failure.
   Restoration

   During failure switchover with 1+1+R recovery scheme, in general,
   failed LSP resources are not released so that working, protecting and
   restoration LSPs coexist in the network.  Nonetheless, restoration
   LSP with working LSP it is restoring as well as restoration LSP with
   protecting LSP it is restoring can share network resources.
   Typically, restoration LSP is torn down when the failure on the
   working or protecting LSP is repaired.

   [RFC4872] Section 14 defines PROTECTION Object for GMPLS recovery
   signaling.  As defined, the PROTECTION Object is used to identify
   primary and secondary LSPs using S bit and protecting and working
   LSPs using P bit.  Furthermore, [RFC4872] defines the usage of
   ASSOCIATION Object for associating GMPLS working and protecting LSPs.

   [RFC6689] Section 2.2 reviews the procedure for providing LSP
   associations for GMPLS end-to-end recovery repaired and covers the schemes
   where the failed working LSP and/or protecting LSP are torn down.

   This document reviews how while the LSP association traffic is
   reverted to be provided for
   GMPLS end-to-end recovery when using restoration LSP where working
   and protecting LSP resources are kept reserved in the network after
   the failure.

2.2. original LSP.

2.3.  Resource Sharing-based Sharing By Restoration LSP Setup/Teardown

                               +-----+      +-----+
                               |  F  +------+  G  +--------+
                               +--+--+      +-----+        |
                                  |                        |
                                  |                        |
        +-----+    +-----+     +--+--+      +-----+     +--+--+
        |  A  +----+  B  +-----+  C  +--X---+  D  +-----+  E  |
        +-----+    +-----+     +-----+      +-----+     +-----+

          Figure 3: A Simple OTN Network Resource Sharing in 1+R Recovery Scheme

   Using the Optical Transport Network (OTN) topology network shown in Figure 3 as an example, GMPLS-controlled circuit LSP1 (A-B-C-D-E)
   is the working LSP and it allows for resource sharing when the LSP is
   dynamically rerouted due to link failure.  Upon detecting the failure
   of a link along the LSP1, e.g. Link C-D, node A needs to decide on which alternate
   alternative path it will establish an LSP use to signal restoration LSP and reroute the
   traffic.  In this case, A-B-C-F-G-E is chosen as the alternative path for the restoration LSP
   path and the resources on the path segment A-B-C are re-used by this
   LSP.  Since this is an OTN network, which
   LSP when working LSP is different from not torn down as in 1+R recovery scheme.

3.  RSVP-TE Signaling Procedure

3.1.  Restoration LSP Association

   Where GMPLS end-to-end recovery scheme needs to employ restoration
   LSP while keeping resources for the working and/or protecting LSPs
   reserved in the
   packet-switching network, network after the label failure, restoration LSP is
   signaled with ASSOCIATION object that has a mapping into Association Type set to
   "Recovery" [RFC4872] with the data plane
   resource used (e.g. wavelength) and also association ID set to the nodes along LSP ID of the path
   need to send triggering commands to data plane nodes
   LSP it is restoring.  For example, when a restoration LSP is signaled
   for setting up
   cross-connection accordingly during the RSVP-TE signaling process.
   In this case, a working LSP, the following issues are left un-described ASSOCIATION object in the
   existing standards for resource sharing based restoration LSP setup/teardown in
   GMPLS-controlled circuit networks:

   - Reservation style Shared-Explicit (SE) as defined in [RFC3209] may
   not be applicable due
   contains the association ID set to the nature LSP ID of the GMPLS-controlled circuits.
    It is not clear how reservation style working LSP.
   Similarly, when a restoration LSP is to be used by the GMPLS
   LSPs signaled for resource sharing.

   - As described in [RFC3209], a protecting LSP,
   the purpose of Make-Before-Break (MBB)
   is to "not disrupt traffic or adversely impact network operations
   while TE tunnel rerouting is ASSOCIATION object in progress".  Due the restoration LSP contains the
   association ID set to the nature LSP ID of the
   GMPLS-controlled circuit networks, this may not be fulfilled under
   certain scenarios.  Thus, the name "Make-Before-Break" may no longer
   hold true.

   - protecting LSP.

   The existing MBB method may not be sufficient to support procedure for signaling the PROTECTION object is specified in

   [RFC4872].  Specifically, restoration LSP setup
   and teardown being used as a working LSP
   is signaled with resource sharing.

   - In [RFC3209], the MBB method assumes the old P bit cleared and new being used as a protecting LSP is
   signaled with P bit set.

3.2.  Resource Sharing-based Restoration LSP Setup

   GMPLS LSPs can share the
   same tunnel ID (i.e., sharing the same source and destination nodes).
    [RFC4873] does not impose this constraint but limit the resource
   sharing usage resources if they have Shared Explicit (SE) flag
   set in LSP recoveries only.  [RFC6780] generalizes the
   resource sharing application, based on the ASSOCIATION Object, to be
   useful their SESSION_ATTRIBUTE objects and:

   o  As defined in MPLS networks as well as [RFC3209], LSPs have identical SESSION objects
   and/or

   o  As defined in non-LSP association such as
   Voice Call-Waiting.  Recently, there are also requirements to
   generalize resource sharing of [RFC6689], LSPs have matching ASSOCIATION object
   with Association Type set to "Resource Sharing".  LSPs in this case
   can have different SESSION objects i.e. different tunnel IDs, such ID, source
   and destination.

   For LSP restoration upon failure, as the one mentioned explained in [PCEP-RSO] and LSPs with LSP-stitching across
   multi-domains.  In this case, how Section 11 of
   [RFC4872], reroute procedure may re-use existing resources.  The
   behavior of the signaling process can make intermediate nodes aware of during rerouting process to
   reconfigure cross-connections does not further impact the resource sharing constraint and
   behave accordingly is an issue that needs traffic
   since it has been interrupted due to be described.

   - the already failed LSP.

   The node behavior during traffic reversion in for setting up the GMPLS-controlled
   circuit network is missing and should restoration LSP can be clarified.

   This document reviews
   categorized into the signaling procedure for resource
   sharing-based following three categories:

           Table 1: Node Behavior during Restoration LSP setup and teardown for GMPLS-based circuits in OTN
   networks.  This includes the node behavior description, besides
   clarifying some un-discussed points for this process.  Two typical
   examples mentioned in this document are Setup
   ---------+---------------------------------------------------------
   Category |       Node Behavior during Restoration LSP restoration Setup
   ---------+---------------------------------------------------------
      C1    + Reusing existing resource on both input and LSP re-
   optimization, where it is desirable to share resources. output
            + interfaces (node A & B in Figure 3).
            +
            + This
   document does not define any RSVP-TE signaling extensions.  If
   necessary, discussion is provided to identify potential extensions type of nodes only needs to book the existing RSVP-TE protocol.  It
            + resources and no cross-connection setup
            + command is expected that needed.
   ---------+---------------------------------------------------------
      C2    + Reusing existing resource only on one of the extensions,
   if there are any, will be addressed in separate documents.

3. RSVP-TE Signaling For Restoration LSP Association

   Where GMPLS end-to-end recovery scheme needs interfaces,
            + either input or output interfaces and need to employ restoration
   LSP while keeping resources for use new
            + resource on the working and/or protecting LSPs
   reserved other interface. (node C & E in the network after the failure, restoration LSP is
   signaled with ASSOCIATION Object that has association Figure 3).
            +
            + This type set of nodes needs to
   "Recovery" [RFC4872] with book the association ID set resources and send
            + the re-configuration cross-connection command to its
            + corresponding data plane node on the LSP ID of interfaces where new
            + resources are needed and re-use the
   LSP it is restoring.  For example, when a restoration LSP is signaled
   for a working LSP,
            + existing resources on the ASSOCIATION Object other interfaces.
   ---------+---------------------------------------------------------
       C3   + Using new resources on both interfaces.

            + (node F & G in the restoration LSP
   contains the association ID set Figure 3).
            +
            + This type of nodes needs to book the LSP ID of new resources
            + and send the working LSP.
   Similarly, when a restoration LSP is signaled for a protecting LSP, cross-connection setup
            + command on both interfaces.
   ---------+---------------------------------------------------------

   Depending on whether the ASSOCIATION Object in resource is re-used or not, the restoration node
   behaviors differ.  This deviates from normal LSP contains setup since some
   nodes do not need to re-configure the
   association ID set cross-connection, and it should
   not be viewed as an error.  Also, the judgment whether the control
   plane node needs to send a cross-connection setup/modification
   command to its corresponding data plane node(s) relies on the LSP ID of check
   whether the protecting LSP.

   The procedure for signaling LSPs are sharing resources.

3.3.  LSP Reversion

   If the PROTECTION Object end-to-end LSP recovery is specified revertive, as described in
   [RFC4872].  Specifically, Section
   2, traffic can be reverted from the restoration LSP being used as a to the working LSP
   is signaled with P bit cleared and being used as a or
   protecting LSP after its failure is
   signaled recovered.  The LSP reversion can
   be achieved using two methods:

     1. Make-while-break reversion, where resources associated with P bit set.

   As discussed in Section 2 of this document, [RFC6689] Section 2.2
   reviews the procedure for providing
     working or protecting LSP associations are reconfigured while removing
     reservations for the GMPLS
   end-to-end recovery scheme using restoration LSP LSP.

     2. Make-before-break reversion, where the failed resources associated with
     working LSP and/or or protecting LSP are torn down.

4. RSVP-TE Signaling For Resource Sharing During LSP Setup/Teardown

   For LSP restoration upon failure, as explained in Section 11 of
   [RFC4872], the purpose of using MBB is to re-use existing resources.
   Thus, reconfigured before removing the behavior
     restoration LSP.

   In transport networks, both of the intermediate nodes during rerouting process above reversion methods will not further impact
   result in some traffic since it has been interrupted due to
   the already broken working LSP.  However, for the following two
   cases, the behavior of intermediate nodes may impact disruption when the traffic
   delivery: (1) LSP reversion; (2) restoration LSP re-optimization.

   Another dimension that needs separate attention is how to correlate
   the two LSPs sharing resource.  For the LSPs with the same Tunnel ID,
   [RFC4872] and reviewed in this section.  For the LSPs with different
   Tunnel IDs, signaling procedure is clarified in Section 4.2 of this
   document.

4.1. LSPs with Identical Tunnel ID

   For resource sharing among LSPs with identical Tunnel IDs, SE flag
   and ASSOCIATION Object
   LSP being restored are used together.  The SE flag is to enable
   resource sharing resources and the ASSOCIATION Object with association type
   "Resource Sharing" [RFC4873] is to identify the associated LSPs.

   As a first step, in order cross-connections
   need to allow resource sharing, the original LSP
   setup should explicitly carry the SE flag in the SESSION_ATTRIBUTE
   Object during the initial LSP setup, irrespective of the purpose of
   resource sharing.

   The basic signaling procedure for alternative be reconfigured on intermediate nodes.

3.3.1.  Make-while-break Reversion

   In this reversion method, restoration LSP setup has been
   described is simply requested to be
   deleted by the existing standards.  In [RFC3209], it describes the
   basic MBB signaling flow for MPLS-TE networks.  [RFC4872] adds
   additional information when using MBB head-end.  Removing reservations for restoration LSP rerouting.

   As mentioned before,
   triggers reconfiguration of resources associated with working or
   protecting LSP on every node where resources are shared.  Whenever
   reservation for restoration LSP setup/teardown in GMPLS-controlled
   circuit networks, the network elements along the path need to send
   cross-connection setup/teardown commands to is removed from a node, data plane node(s) either
   during the PATH message forwarding phase
   configuration changes to reflect reservations of working or the RESV message
   forwarding phase.

4.1.1. Restoration LSP Setup

   For
   protection LSP restoration, the complete as signaling flow processes for both progresses.  Eventually, after the whole
   restoration LSP restorations upon failure and is deleted, data plane configuration will fully match
   working or protecting LSP reservations on the whole path.  Thus
   reversion upon link failure
   recovery are described in this section.

            Table 1: Node Behavior during Restoration LSP Setup

   ---------+---------------------------------------------------------
   Category |         Node Behavior during Restoration LSP setup
   ---------+---------------------------------------------------------
      C1    + Reusing existing resource on both input and output
            + interfaces.
            + This type of nodes only needs to book the existing
            + resource when receiving the PATH message and no cross-
            + connection setup command is needed when receiving
            + the RESV message.
   ---------+----------------------------------------------------------
      C2    + Reusing existing resource only on one of the interfaces,
            + either input or output interfaces and need to use new
            + resource on the other interface.
            + This type of nodes needs to book the resources on the
            + interface where new resource are needed and re-use the
            + existing resource on the other interface when it receives
            + the PATH message.  Upon receiving the RESV message, it
            + needs to send the re-configuration the cross-connection
            + command to its corresponding data plane node.
   ---------+---------------------------------------------------------
       C3   + Using new resource on both interfaces.
            + This type of nodes needs to book the new resource when
            + receiving PATH and send the cross-connection setup
            + command upon receiving RESV.
   ---------+---------------------------------------------------------

   For LSP rerouting upon working LSP failure, using the network shown complete.

   Make-while-break, while being relatively simple in Figure 3 its logic, has few
   limitations as an example.

   Working LSP: A-B-C-D-E
   Restoration LSP: A-B-C-F-G-E

   The restoration LSP follows which may be calculated by the head-end node or a Path
   Computation Element (PCE) [RFC4655].  Assuming that the
   cross-connection configuration command is sent by the control plane
   nodes during the RESV forwarding phrase, the node behavior for
   setting up the alternative LSP can be classified into the following
   three categories as shown in Table 1.

    +---+       +---+       +---+       +---+       +---+        +---+
    | A |       | B |       | C |       | F |       | G |        | E |
    +-+-+       +-+-+       +-+-+       +-+-+       +-+-+        +-+-+
      |           |           |           |           |            |
      |   PATH    |           |           |           |            |
   C1 +----------X+ C1        |           |           |            |
      |           |   PATH    |           |           |            |
      |           +----------X+ C2        |           |            |
      |           |           |   PATH    |           |            |
      |           |           +----------X+ C3        |            |
      |           |           |           |   PATH    |            |
      |           |           |           +----------X+ C3         |
      |           |           |           |           |   PATH     |
      |           |           |           |           +-----------X+ C2
      |           |           |           |           |            |
      |           |           |           |           |            |
      |           |           |           |           |   RESV     |
      |           |           |           |        C3 +X-----------+ C2
      |           |           |           |   RESV    |            |
      |           |           |        C3 +X----------+            |
      |           |           |   RESV    |           |            |
      |           |        C2 +X----------+           |            |
      |           |   RESV    |           |           |            |
      |        C1 +X----------+           |           |            |
      |   RESV    |           |           |           |            |
   C1 +X----------+           |           |           |            |

            Figure 4: Restoration LSP Setup Signaling Procedure

   As shown in Figure 4, depending on whether the resource is re-used or
   not, the node behaviors differ.  This deviates from normal LSP setup
   since some nodes do not need to re-configure the cross-connection,
   and thus should not be viewed as an error.  Also, the judgment
   whether the control plane node needs to send a cross-connection
   setup/modification command to its corresponding data plane node(s)
   relies on the check whether the following two cases holds true: (1)
   the PATH message received include a SE reservation style; (2) the
   PATH message identifies a LSP that sharing the same tunnel ID as the
   LSP to share resource with.  For the second point, the processing
   rules and configuration of ASSOCIATION Object defined in [RFC4872]
   are followed.

4.1.2. LSP Reversion

   If the LSP rerouting is revertive, traffic can be reverted to the
   working or protecting LSP after its failure is recovered.  From
   resource sharing perspective reversion can be divided into two types:

      o  Make-while-break reversion, where resources associated with
      working or protecting LSP are reconfigured while removing
      reservations for restoration LSP.

      o  Make-before-break reversion, where resources associated with
      working or protecting LSP are reconfigured before removing
      restoration LSP.

   It is worth mentioning that in GMPLS-controlled circuit OTN networks
   both reversion types will result in a short traffic disruption.

4.1.2.1. Make-while-break Reversion

   In this technique, restoration LSP is simply requested to be deleted.
   Removing reservations for restoration LSP triggers reconfiguration of
   resources associated with working or protecting LSP on every node
   where resources are shared.  Hence, whenever reservation for
   restoration LSP is removed from a node, data plane configuration
   changes to reflect reservations of working or protection LSP as
   signaling progresses.  Eventually, after the whole restoration LSP is
   deleted, data plane configuration will fully match working or
   protecting LSP reservations on the whole path.  Thus reversion is
   complete.

    +---+       +---+       +---+       +---+       +---+       +---+
    | A |       | B |       | C |       | F |       | G |       | E |
    +-+-+       +-+-+       +-+-+       +-+-+       +-+-+       +-+-+
      |           |           |           |           |           |
      | PATHTEAR  |           |           |           |           |
   D1 +----------X+ D1        |           |           |           |
      |           | PATHTEAR  |           |           |           |
      |           +----------X+ D2        |           |           |
      |           |           | PATHTEAR  |           |           |
      |           |           +----------X+ D3        |           |
      |           |           |           | PATHTEAR  |           |
      |           |           |           +----------X+ D3        |
      |           |           |           |           | PATHTEAR  |
      |           |           |           |           +----------X+ D2
      |           |           |           |           |           |

     Figure 5: Signaling Procedure for LSP Make-while-break Reversion

   Figure 5 shows signaling process of make-while-break reversion of LSP
   PathTear message.  For alarm-free LSP deletion, the mechanisms
   described in Section 6 of [RFC4208] should be followed.  Resource
   sharing between working and restoration LSP takes place on nodes A,
   B, C and E.  These are the nodes where reconfiguration of resources
   associated with working LSP can take place.

   Node behavior upon removing reservation for restoration LSP depends
   on how resources are shared with working or protecting LSP:

     Table 2: Node behavior during LSP make-while-break reversion

   ---------+---------------------------------------------------------
   Category |   Node behavior during LSP make-while-break reversion
   ---------+---------------------------------------------------------
      D1    + Working and restoration LSP share resources on both
            + incoming and outgoing interface.
            +
            + CP change: Reservation for restoration LSP is removed.
            + DP change: None, as data plane configuration already
            + reflects working LSP reservation.
   ---------+----------------------------------------------------------
      D2    + Working and restoration LSP share resources on one of the
            + interfaces.
            +
            + CP change: Reservation for restoration LSP is removed.
            + DP change: Resource on the interface that is not shared
            + between working and restoration LSP is freed.
            + Cross-connection is updated to reflect working LSP
            + reservation.
   ---------+----------------------------------------------------------
      D3    + Working and restoration LSP do not share resources.
            +
            + CP change: Reservation for restoration LSP is removed.
            + DP change: Resources associated with restoration LSP are
            + freed.
   ---------+----------------------------------------------------------

   Make-while-break, while being relatively simple in its logic, has a
   few limitations which may be not acceptable in some implementations:

      o No rollback

        Deletion of a LSP is not a revertive process.  If for some
        reason reconfiguration of data plane on one of the nodes to
        match working or protection LSP reservations fails, falling back
        to restoration LSP is no longer an option, as its state might
        have already been removed from other nodes.

      o No completion guarantee

        Deletion of a LSP provides no guarantees of completion.  In
        particular, if RSVP packets are lost due to nodal or DCN
        failures it is probable for a LSP to be only partially deleted.
        To mitigate this, RSVP could maintain soft state reservations
        and hence eventually remove remaining reservations due to
        refresh timeouts.  This approach is not feasible in circuit
        networks however, since control and data channels are often
        separated and hence soft state reservations are not used.

        Finally, one could argue that graceful LSP deletion [RFC3473]
        would provide guarantee of completion.  While this is true for
        most cases, many implementations will timeout graceful deletion
        if LSP is not removed within certain amount of time, e.g. due to
        a transit node fault.  After that, deletion procedures that
        provide no completion guarantees will be attempted.  Hence in
        corner cases completion guarantee cannot be provided.

      o No explicit notification of completion to ingress node

        In some cases it may be useful for ingress node to know when the
        data plane has been reconfigured to match working or protection
        LSP reservations.  This knowledge could be used for initiating
        operations like enabling alarm monitoring, power equalization
        and others.  Unfortunately, for the reasons mentioned above,
        make-while-break reversion lacks such explicit notification.

4.1.2.2. Make-before-break Reversion

   MBB reversion can be used to overcome limitations of make-while-break
   reversion.  It is similar in spirit to MBB concept used for
   restoration.  Instead of relying on deletion of restoration LSP, it
   chooses to establish a new LSP to reconfigure resources on the
   working or protection LSP path.  Only if setup of this LSP is
   successful will other LSPs be deleted.  MBB reversion consists of two
   parts:

     A) Make part:
        Creating a new reversion LSP following working or protection
        LSP's path - see Figure 6.  Reversion LSP is sharing resources
        both with working and restoration LSPs.  As reversion LSP is
        created, resources are reconfigured to match its reservations -
        nodes follow procedures described in Table 1.  Hence after
        reversion LSP is created, data plane configuration essentially
        reflects working or protecting LSP reservations.

     B) Break part:
        After 'make' part is finished, working and restoration LSPs are
        torn down.  Removing reservations for working and restoration
        LSPs does not cause any resource reconfiguration on reversion
        LSP's path - nodes follow same procedures as for 'break' part of
        any MBB operation.  Hence after working and restoration LSPs are
        removed, data plane configuration is exactly the same as before
        starting restoration.  Thus reversion is complete.

     +---+       +---+       +---+       +---+       +---+
     | A |       | B |       | C |       | D |       | E |
     +-+-+       +-+-+       +-+-+       +-+-+       +-+-+
       |           |           |           |           |
       |   PATH    |           |           |           |
    C1 +----------X+ C1        |           |           |
       |           |   PATH    |           |           |
       |           +----------X+ C2        |           |
       |           |           |   PATH    |           |
       |           |           +----------X+ C1        |
       |           |           |           |   PATH    |
       |           |           |           +----------X+ C2
       |           |           |           |           |
       |           |           |           |           |
       |           |           |           |   RESV    |
       |           |           |        C1 +X----------+ C2
       |           |           |   RESV    |           |
       |           |        C2 +X----------+           |
       |           |   RESV    |           |           |
       |        C1 +X----------+           |           |
       |   RESV    |           |           |           |
    C1 +X----------+           |           |           |

     Figure 6: 'Make': Reversion LSP Setup follows Working LSP's Path

   Figure 6 shows signaling process of reversion LSP setup for working
   LSP from Section 4.1.1.  In this example, resource sharing between
   reversion and restoration LSP takes place on nodes A, B, C and E.
   Resource sharing between working and reversion LSP takes place on
   whole working LPS's path, i.e. A, B, C, D and E.  Before reversion
   LSP be acceptable in some networks:

   o No rollback

   Deletion of restoration LSPs is signaled, not a revertive process.  If for some
   reason reconfiguration of data plane configuration on one of the nodes A, B, C and E to match restoration LSP reservations.  On node D data plane
   configuration matches
   working or protection LSP reservations.

   As already mentioned, MBB reversion uses make-before-break
   characteristics to overcome challenges related to make-while-break
   reversion:

     o Rollback

        If 'make' part reservations fails, falling back to
   restoration LSP will still be used to
        carry existing traffic.  Same logic applies here is no longer an option, as for any MBB
        operation failure. its state might have
   already been removed from other nodes.

   o Completion No completion guarantee

   Deletion of an LSP setup provides no guarantees of completion.  In
   particular, if RSVP packets are lost due to nodal or DCN failures it
   is resilient against possible for an LSP to be only partially deleted.  To mitigate
   this, RSVP message loss, as PATH could maintain soft state reservations and
        RESV messages hence
   eventually remove remaining reservations due to refresh timeouts.
   This approach is not feasible in transport networks however, where
   control and data channels are refreshed periodically.  Hence, given often separated and hence soft state
   reservations are not useful.

   Finally, one could argue that
        network recovers its DCN eventually, setup graceful LSP deletion [RFC3473] would
   provide guarantee of completion.  While this is guaranteed true for most cases,
   many implementations will time out graceful deletion if LSP is not
   removed within certain amount of time, e.g. due to
        finish with either success or failure. a transit node
   fault.  After that, deletion procedures which provide no completion
   guarantees will be attempted.  Hence, in corner cases completion
   guarantee cannot be provided.

   o Explicit No explicit notification of completion to ingress head-end node

        Ingress knows that

   In some cases, it may be useful for a head-end node to know when the
   data plane has been reconfigured to match working or protection LSP reservations when it receives RESV
   reservations.  This knowledge could be used for initiating operations
   like enabling alarm monitoring, power equalization and others.
   Unfortunately, for the reasons mentioned above, make-while-break
   reversion LSP.

4.1.3. Re-optimization LSP Setup and lacks such explicit notification.

3.3.2.  Make-before-break Reversion

   For LSP re-optimization where the

   This reversion method can be used to overcome limitations of
   make-while-break reversion.  It is similar in spirit to MBB concept
   used for re-optimization.  Instead of relying on deletion of
   restoration LSP, head-end chooses to establish a new LSP and old LSPs share
   resource, to
   reconfigure resources on the signaling flow for new working or protection LSP setup path, and old LSP teardown
   is similar to those shown in Figures 4 uses
   identical ASSOCIATION and 5.

   The issue that should be noted is PROTECTION objects from the traffic will be disrupted LSP it is
   replacing.  Only if
   the new path setup process changes the cross-connection configuration of the nodes along the old LSP.  If no traffic interruption is
   desirable, it should either ensure that the old and new this LSP do not
   share the resource is successful will other than the source
   (restoration and destination nodes or use
   other mechanisms.  This is out working/protecting) LSPs be deleted by the scope head-end.
    MBB reversion consists of this document.

   Similarly, if LSP re-optimization fails and there is two parts:

   A) Make part:

   Creating a need for new reversion LSP following working or protection LSP's
   path.  Reversion LSP
   reversion, the traffic may be disrupted when resources are shared and
   cross-connections need to be reconfigured and reverted.

4.2. LSPs with Different Tunnel IDs

   For two LSPs with different Tunnel IDs, the ASSOCIATION Object is
   used to specify that they are sharing resource (by setting
   ASSOCIATION type as "Resource Sharing" (value 2) as well as to
   identify these correlated sharing resources both with working and
   restoration LSPs.  There  As reversion LSP is created, resources are two types:

     (1) Sharing the common nodes, such as segment recovery, the source
     and destination nodes of the segment recovery
   reconfigured to match its reservations.  Hence, after reversion LSP
   is the
     intermediate nodes along the created, data plane configuration essentially reflects working LSPs;

     (2) Resource sharing is used in a generalized context (such as
     multi-layer or multi-domain networks); it may result in either
     sharing source nodes in common, or destination nodes in common, or
     non end-points in common, if viewed from one domain's perspective.

   The path computation can either be performed by the source node or
   edge nodes
   protecting LSP reservations.

   B) Break part:

   After "make" part is finished, working and restoration LSPs are torn
   down.  Removing reservations for the path/path segment or carried out by the PCE, such
   as the one explained in [PCEP-RSO].  This document working and restoration LSPs does
   not impose cause any constraint with regard to path computation.

   [RFC4873] considers resource sharing reconfiguration on reversion LSP's path -
   nodes follow same procedures as for LSP segment recovery.  The
   ASSOCIATION Object usage "break" part of any MBB
   operation.  Hence, after working and restoration LSPs are removed,
   data plane configuration is limited.  [RFC6780] extends exactly the usage of
   ASSOCIATION Object to cover generalized resource sharing
   applications.  The extended ASSOCIATION Object same as before starting
   restoration.  Thus reversion is primarily defined
   for MPLS-TP, but it can be applied in a wider scope [RFC6780].  It
   can complete.

   MBB reversion uses make-before-break characteristics to overcome
   challenges related to make-while-break reversion as follow:

   o Rollback

   If "make" part fails, (existing) restoration LSP will still be used in the second types mentioned above.  The configuration
   and processing rules of extended ASSOCIATION Object defined in
   [RFC6780] should be followed.  The only issue that need pay attention
   to carry existing traffic.  Same logic applies here as for any MBB
   operation failure.

   o Completion guarantee

   LSP setup is resilient against RSVP message loss, as Path and Resv
   messages are refreshed periodically.  Hence, given that uniqueness of network
   recovers its DCN eventually, reversion LSP association for the second type should
   be setup is guaranteed when crossing the layer or domain boundary.  The
   mechanisms for how to ensure this are outside the scope of this
   document.

   Other than this, the signaling flow for this type
   finish with either success or failure.

   o Explicit notification of resource sharing
   is similar completion to the description provided in Section 4.1.1.  Similar head-end node

   Head-end knows that data plane has been reconfigured to
   what is discussed in previous sections, the traffic delivery may be
   interrupted.  Depending on whether the short traffic interruption is
   acceptable match working
   or not, additional mechanisms may be needed and are
   outside protection LSP reservations on intermediate nodes when it receives
   Resv for the scope of this document.

5. reversion LSP.

4.  Security Considerations

   This document reviews procedures defined in [RFC3209] [RFC4872]

   [RFC4873] and [RFC6689] and does not define any new procedure.  This
   document does not incur introduce any new security issues other than those
   already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6780].

6. [RFC6689].

5.  IANA Considerations

   This informational document does not make any requests request for IANA
   action.

7.

6.  Acknowledgement

   The authors would like to thank George Swallow for the discussions on
   the GMPLS restoration.

8.

7.  References

8.1.

7.1.  Normative References

   [RFC3209]   D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
               Tunnels", RFC 3209, December 2001.

   [RFC3473]   L. Berger, Ed., "Generalized Multi-Protocol Label
               Switching (GMPLS) Signaling Resource ReserVation
               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
               3473, January 2003.

   [RFC3945]   Mannie, E., "Generalized Multi-Protocol Label Switching
               (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4203]   Kompella, K., and Rekhter, Y., "OSPF Extensions in
               Support of Generalized Multi-Protocol Label Switching
               (GMPLS)", RFC 4203, October 2005.

   [RFC4872]   J.P. Lang et al, "RSVP-TE Extensions in Support of End-
               to-End
               End-to-End Generalized Multi-Protocol Label Switching
               (GMPLS) Recovery", RFC 4872, May 2007.

   [RFC4873]   L. Berger et al, "GMPLS Segment Recovery", RFC 4873, May
               2007.

   [RFC6689]   L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC
               6689, July 2012.

   [RFC6780]   L. Berger et al, "RSVP ASSOCIATION Object Extensions",
               RFC 6780, October 2012.

8.2.

7.2.  Informative References

   [PCEP-RSO]  X. Zhang, et al, "Extensions to Path Computation Element
               Protocol (PCEP) to Support Resource Sharing-based Path
               Computation", work in progress, February 2014.

   [RFC3473]   L. Berger, Ed., "Generalized Multi-Protocol Label
               Switching (GMPLS) Signaling Resource ReserVation
               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
               3473, January 2003.

   [RFC3945]   Mannie, E., "Generalized Multi-Protocol Label Switching
               (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4203]   Kompella, K., and Rekhter, Y., "OSPF Extensions in
               Support of Generalized Multi-Protocol Label Switching
               (GMPLS)", RFC 4203, October 2005.

   [RFC4426]   Lang, J., Rajagopalan, B., and Papadimitriou, D.,
               "Generalized Multiprotocol Label Switching (GMPLS)
               Recovery Functional Specification", RFC 4426, March 2006.

   [RFC4427]   Mannie, E., and Papadimitriou, D., "Recovery (Protection
               and Restoration) Terminology for Generalized Multi-
               Protocol Label Switching", RFC 4427, March 2006.

   [RFC4655]   A. Farrel et al, "A Path Computation Element (PCE)-Based
               Architecture", RFC 4655, August 2006.

   [RFC4208]   Swallow, G., Drake, J., Ishimatsu, H., Rekhter, Y.,
               "Generalized Multiprotocol Label Switching (GMPLS)
               User-Network Interface (UNI): Resource ReserVation
               Protocol-Traffic Engineering (RSVP-TE) Support for the
               Overlay Model", RFC 4208, October 2005.

9.

8.  Authors' Addresses

   Xian Zhang
   Huawei Technologies
   F3-1-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Email: zhang.xian@huawei.com

   Haomian Zheng (editor)
   Huawei Technologies
   F3-1-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Email: zhenghaomian@huawei.com

   Rakesh Gandhi (editor)
   Cisco Systems, Inc.

   Email: rgandhi@cisco.com

   Zafar Ali
   Cisco Systems, Inc.

   Email: zali@cisco.com

   Gabriele Maria Galimberti
   Cisco Systems, Inc.

   Email: ggalimbe@cisco.com

   Pawel Brzozowski
   ADVA Optical

   Email: PBrzozowski@advaoptical.com