PCE Working Group                                              Y. Tanaka
Internet-Draft                                                 Y. Kamite
Intended status: Standards Track                      NTT Communications
Expires: September 8, 2019                                    R. Palleti
                                                                   C. Li
                                                                H. Zheng
                                                     Huawei Technologies
                                                           March 7, 2019


   Make-Before-Break (MBB) MPLS-TE LSP restoration and reoptimization
        procedure using Stateful Path Computation Element (PCE).
                  draft-tanaka-pce-stateful-pce-mbb-08

Abstract

   Stateful Path Computation Element (PCE) and its corresponding
   protocol extensions provide a mechanism that enables PCE to do
   stateful control of Multiprotocol Label Switching (MPLS) Traffic
   Engineering Label Switched Paths (TE LSP).  Stateful PCE supports
   manipulating of the existing LSP's state and attributes (e.g.,
   bandwidth and path) via delegation and also instantiation of new LSPs
   in the network via PCE Initiation procedures.

   In the current MPLS TE network using Resource ReSerVation Protocol
   (RSVP-TE), LSPs are often controlled by Make-before-break (M-B-B)
   signaling by the headend for the purpose of LSP restoration and
   reoptimization.  In most cases, it is an essential operation to
   reroute LSP traffic without any data disruption.

   This document specifies the procedure of applying stateful PCE's
   control to make-before-break RSVP-TE signaling.  In this document,
   two types of restoration/reoptimization procedures are defined,
   implicit mode and explicit mode.  This document also specifies the
   usage and handling of stateful PCEP (PCE Communication Protocol)
   messages, expected behavior of PCC as RSVP-TE headend and necessary
   extensions of additional PCEP objects.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.




Tanaka, et al.          Expires September 8, 2019               [Page 1]


Internet-Draft           MBB using Stateful PCE               March 2019


   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."

   This Internet-Draft will expire on September 8, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (https://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.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Make-Before-Break LSP procedures  . . . . . . . . . . . . . .   5
     5.1.  Implicit Make-Before-Break Mode . . . . . . . . . . . . .   6
     5.2.  Explicit Make-Before-Break Mode . . . . . . . . . . . . .   8
       5.2.1.  Initiate Association Group for old LSP  . . . . . . .   8
       5.2.2.  Establish new Trial LSP . . . . . . . . . . . . . . .   9
       5.2.3.  Switchover Data Traffic triggered by a PCUpd message   11
   6.  Protocol extension  . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Association group . . . . . . . . . . . . . . . . . . . .  14
     6.2.  Trial LSP TLV in ASSOCIATION Objects  . . . . . . . . . .  14
     6.3.  Optional TLVs . . . . . . . . . . . . . . . . . . . . . .  15
     6.4.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  PCEP TLV Indicators . . . . . . . . . . . . . . . . . . .  16
     8.2.  Association Object Type Indicator . . . . . . . . . . . .  16
   9.  Operational Considerations  . . . . . . . . . . . . . . . . .  16
     9.1.  Operation in multiple PCEs  . . . . . . . . . . . . . . .  16
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  17



Tanaka, et al.          Expires September 8, 2019               [Page 2]


Internet-Draft           MBB using Stateful PCE               March 2019


     11.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   [RFC5440] describes the Path Computation Element Protocol PCEP.  PCEP
   enables the communication between a Path Computation Client (PCC) and
   a Path Control Element (PCE), or between PCE and PCE, for the purpose
   of computation of Multiprotocol Label Switching (MPLS) as well as
   Generalzied MPLS (GMPLS) for Traffic Engineering Label Switched Path
   (TE LSP) characteristics.

   [RFC8231] describes the stateful Path Computation Elements (PCE) and
   defines the extensions to PCEP to enable stateful control of LSPs
   within and across PCEP sessions, further it also describes mechanisms
   to effect LSP state synchronization between PCCs and PCEs, and PCE
   control of timing and sequence of path computations within and across
   PCEP sessions.

   Today, however, there is no detailed procedure specified for
   restoration and reoptimization of MPLS-TE LSP using stateful PCE.  In
   today's MPLS RSVP-TE mechanism, make-before-break (M-B-B) is a widely
   common scheme supported by headend Label Edge Router (LER) in order
   to assure no traffic disruption during restoration and
   reoptimization.  Hence it is naturally desirable for stateful PCE to
   control M-B-B based signaling and forwarding process.

   This document specifies the definite procedures of applying stateful
   PCE's control of the M-B-B procedures.  In this document, two types
   of restoration/reoptimization procedures are defined, Implicit mode
   and Explicit mode.  This document also specifies the usage and
   handling of stateful PCEP (PCE Communication Protocol) messages,
   expected behavior of PCC as RSVP-TE headend and several extensions of
   additional objects.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.








Tanaka, et al.          Expires September 8, 2019               [Page 3]


Internet-Draft           MBB using Stateful PCE               March 2019


3.  Terminology

   This document uses the following terms defined in [RFC5440]: PCC,
   PCE, PCEP Peer.

   This document uses the following terms defined in [RFC3209]: make-
   before-break (M-B-B), Path State Block (PSB).

   This document uses the following terms defined in [RFC4426] and
   [RFC4427]: recovery, protection, restoration.

   According to their definition the term "recovery" is generically used
   to denote both protection and restoration; the specific terms
   "protection" and "restoration" are used only when differentiation is
   required.  The subtle distinction between protection and restoration
   is made based on the resource allocation done during the recovery
   period.  Hence the protection allocates LSP resource in advance of a
   failure, while the restoration allocates LSP resource after a failure
   occur.

4.  Motivation

   As for current MPLS mechanism, make-before-break(M-B-B) concept is
   outlined in [RFC3209], which allows adaptive and smooth RSVP-TE LSP
   rerouting that does not disrupt traffic or adversely impact network
   operations while rerouting is in progress.  M-B-B is applicable for
   reoptimizing LSP's route and resources for several use cases, for
   example, to adopt better path for reversion after failure, to change
   traversing node/links for planned maintenance, to change bandwidth of
   LSPs etc.  M-B-B is also used for global restoration scenario in case
   of failure, which is effective if operators do not want to reserve
   both working and standby LSP's bandwidth in advance.  Once failure
   occur, LSP becomes down, however PSB (Path State Block) of a headend
   node remains and keep resources intact.  Using M-B-B, the headend
   node is able to resignals working LSP while the PSB remains until new
   restoration LSP is successfully established.  In real deployment, it
   can also be operated with local protection scheme FRR (Fast ReRoute).

   Since M-B-B operational scheme is universally common in MPLS network
   today, it is naturally much desirable to utilize it under the
   architecture of stateful PCE.

   The basic procedure of the Make-Before-Break method is outlined as
   follows:



      1.  Establish a new LSP



Tanaka, et al.          Expires September 8, 2019               [Page 4]


Internet-Draft           MBB using Stateful PCE               March 2019


      2.  Transfer data traffic from old LSP onto the new LSP
      3.  Tear down the old LSP (Release old PSB)


   In M-B-B, it is an important behavior that headend node handles the
   sequence of data traffic switchover.  The headend is able to Make one
   or more new LSPs for a particular Tunnel (i.e., it is allowed to
   signal multiple LSPs with different LSP-IDs that share a common
   Tunnel IDs), and the headend will switch the traffic to only one (or
   some) of those LSPs.  In some use cases about stateful PCE, it is
   expected that controller/operators can watch and control when the
   data is switched over and which LSPs are used.  Therefore, this
   document covers such a procedure and related message extensions.

5.  Make-Before-Break LSP procedures

   There are possibly two modes introduced for Make-Before-Break
   procedure under stateful PCE.  The first one is "implicit M-B-B
   mode", where the operation is triggered by a Update Request(PCUpd)
   message from a PCE, and a PCC handles whole Make-Before-Break steps
   (signaling, transferring data traffic and teardown) by itself.  This
   mode utilizes the existing messages and procedures as defined in
   [RFC8231] .

   The second one is "explicit M-B-B mode", where the operation is
   triggered by a PCUpd message with a new TRIAL LSP TLV (defined in
   Section 6.2).  A PCE also controls timing and sequence of the M-B-B
   steps that a PCC takes.  This procedure uses ASSOCIATION Object that
   is defined in [I-D.ietf-pce-association-group].

   Both types of procedure require at least two LSPs residing in a
   single MPLS-TE tunnel, working LSP and trial LSPs.  An ingress node
   is currently transporting data traffic on the working LSP, and then
   it establishes one or more trial LSPs.  As per [RFC3209] Section 2.5.
   "LSP ID" of a restoration LSP, which is newly signaled, differs from
   that of a working LSP in RSVP-TE.  Note that it is also used for LSP-
   ID in LSP Identifiers TLVs in PCEP messages, and it differs from
   PLSP-ID ([RFC8231]).  In this document, LSP ID of a working LSP
   describes "old" and that of a trial LSP describes "new" as a simple
   example.

   Implicit mode has high affinity with most existing MPLS edge node
   implementations which perform entire steps of M-B-B automatically at
   once.  This mode is particularly applicable for migration scenario
   for the existing deployment where service providers want their
   recovery/reoptimization operation be delegated to a centralized PCE.





Tanaka, et al.          Expires September 8, 2019               [Page 5]


Internet-Draft           MBB using Stateful PCE               March 2019


   Explicit mode is much more flexible than Implicit mode since it
   allows PCEs to manage each step of the M-B-B.  Explicit mode is
   applicable to several new use cases that require split control of
   signaling and data switchover.  For example, if end-to-end data path
   is created by connecting multiple individual LSPs across different
   segments (e.g., LSP stitching), in reoptimization scenario, data
   flowing cannot be started unless signaling of all LSPs is completed.
   Similarly, there is a case under Software Defined Networking (SDN)
   applications, where MPLS domain is connected to other non-MPLS
   domains, and the end-to-end data switchover timing should be
   carefully coordinated with various different methods of path/flow
   setup in each domain.

   PCC and PCE can distinguish which mode, implicit mode or explicit
   mode, is to be performed by checking the presence of ASSOCIATION and
   certain TLV in the PCEP messages.  The implementation MAY support
   both modes, but for each restoration/reoptimization operation, either
   one of them SHOULD be exclusively applied.

5.1.  Implicit Make-Before-Break Mode

   This specifies the detailed procedure of M-B-B LSP restoration and
   reoptimization using existing messages which are defined in [RFC8231]
   .  This procedure is based on the existing messages/TLVs and no
   extensions are required.  Once a PCC receives PCUpd message from a
   PCE, the PCC automatically executes the implicit M-B-B procedure as
   described in [RFC8231] Section 6.2.

      First, A PCUpd message is sent from a PCE to trigger M-B-B
      procedure.  Once receiving the PCUpd message, the PCC starts
      signaling a new restoration/reoptimization LSP and it replies back
      to the PCE a PCRpt message with LSP-IDENTIFIERS TLV (with new LSP-
      ID) in the LSP Object to notify the result of signaling.  If the
      new LSP failed to setup, the PCC sends to the PCE the detail of
      the result in a PCErr or PCRpt message with the same SRP (Stateful
      PCE Request Parameters) object as that of the PCUpd message and it
      MAY wait for a next instruction from the PCE.

      Second, once a new LSP is successfully established, a PCC
      transfers data traffic from working LSP to new LSP automatically.
      Finally, when a PCC successfully transferred data traffic to the
      new LSP, the PCC tears down the (previous) working LSP by RSVP-TE
      signaling, then the PCC sends another PCRpt message.  That PCRpt
      message carries a LSP Object with LSP-IDENTIFIERS TLV (with old
      LSP-ID) which indicates the value of RSVP-TE signaling the PCC has
      just torn down.  As per [RFC8231], the message has to have SRP-ID
      set to 0x00000000.




Tanaka, et al.          Expires September 8, 2019               [Page 6]


Internet-Draft           MBB using Stateful PCE               March 2019


   Following Figure 1 illustrates the example of implicit M-B-B
   procedure, in following conditions.  Tunnel ID and LSP ID are
   included in an LSP Identifiers TLV in a LSP Object.

   working LSP :  ERO=a-b, Tunnel ID=T1, LSP ID=old, PLSP-ID=X
   restoration LSP :  ERO=a-c-b, Tunnel ID=T1, LSP ID=new, PLSP-ID=X

                                     __c__
                                    /     \
   PCE               PCC(Ingress)--a-------b---Egress
    |                    |                        |
    |   Data on old LSP  =>)))))))))))))))))))))))|
    |                    |          :             |
    |--PCUpd(PLSP-ID=X,->|          :             |
    |      SRP-ID=Y,     |                        |
    |      ERO=a-c-b)    |---Path(ERO=a-c-b-, --> |
    |                    |       LSP ID new)      |
    |                    |                        |
    |                    | <-----Resv-------------|
    | <- PCRpt(PLSP-ID=X,|                        |
    |      O=Up,         |                        |
    |      SRP-ID=Y,     |                        |
    |      Tunnel ID=T1, |                        |
    |      LSP ID=new)   |                        |
    |                    |                        |
    |                    |                        |
    |   Transfer data    |))))))))))))))))))))))))|
    |   from old to new =>}}}}}}}}}}}}}}}}}}}}}}}}|
    |                    |          :             |
    |                    |          :             |
    |                    |---PathTear(ERO=a-b, -> |
    |                    |         LSP ID old)    |
    | <- PCRpt(PLSP-ID=X,|                        |
    |      O=Dn,R=1,     |                        |
    |      SRP-ID=0,     |                        |
    |      Tunnel ID=T1, |                        |
    |      LSP ID=old)   |                        |

     O flag = Operational flag in LSP object.
     R flag = Remove flag in LSP object.



              Figure 1: Implicit Make-Before-Break Procedure







Tanaka, et al.          Expires September 8, 2019               [Page 7]


Internet-Draft           MBB using Stateful PCE               March 2019


5.2.  Explicit Make-Before-Break Mode

   Comparing to the implicit M-B-B mode, explicit M-B-B mode allows a
   PCE to control timing and sequence of subsequent make-before-break
   steps.

   As per [I-D.ietf-pce-association-group], LSPs are associated with
   other LSPs with which they interact by adding them to a common
   association group.  In this draft, this grouping is used to define
   associations between a set of LSPs.  This document define one new
   association type called "Explicit MBB Association Type" of value
   TBD1.

      Prior to start of explicit M-B-B mode, PCE makes an association
      group for the working LSP by including the Association Object
      (defined in [I-D.ietf-pce-association-group]) with "Explicit MBB
      Association Type".  This allows the PCEs to identify the LSP
      belong to a Make-Before-Break association group.  PCE may include
      the TRIAL-LSP TLV that is defined in this document with D(Data
      Switchover) and T(Trial LSP) flags set to 0 in Association Object.
      This is a pre-requisite for the explicit M-B-B.
      First step of the explicit M-B-B, the PCE triggers signaling of a
      new LSP at the PCC by sending a PCUpd/PCInitiate message with T
      flag in TRIAL-LSP TLV set to 1, in the ASSOCIATION Object.  The
      PCC sends a PCRpt message back to the PCE to notify the result of
      the signaling of the new LSP.
      Second, the PCE instructs the PCC to transfer data traffic from
      old LSP to new LSP by sending a PCUpd message with D flag in
      TRIAL-LSP TLV set to 1, in the ASSOCIATION Object.  The PCC
      automatically tears down the (previous) working LSP once the
      traffic switchover successfully is executed.  Then it sends back
      to the PCE a PCRpt message to notify the result of the switchover.
      [Editor's Note - The operator may want to separate the second step
      into traffic switchover and tearing down old LSP.  It is further
      study about the separate operation of third step.]

   The following subsections specify each Explicit Make-Before-Break
   step in detail.

5.2.1.  Initiate Association Group for old LSP

   As a pre-requisite before starting explicit M-B-B, PCE makes an
   association group for working LSP by sending PCUpd message that
   contains ASSOCIATION object with TRIAL-LSP TLV with both D and T
   flags set to zero.  TRIAL-LSP TLV is optional in the ASSOCIATION
   object at this step.





Tanaka, et al.          Expires September 8, 2019               [Page 8]


Internet-Draft           MBB using Stateful PCE               March 2019


   Figure 2 illustrates an example of working LSP (PLSP-ID P1, Tunnel ID
   T1, LSP-ID old, Association Group ID G1 and ERO Ingress-a-b-Egress).


                                     __c__
                                    /     \
   PCE               PCC(Ingress)--a-------b---Egress
    |   data traffic on old LSP                   |
    |                    |))))))))))))))))))))))))|
    |--PCUpd      ------>|          :             |
    |   LSP Object       |          :             |
    |    PLSP-ID=P1      |          :             |
    |    SRP-ID=S1       |          :             |
    |    LSP ID=old      |                        |
    |   ASSOC Object     |                        |
    |    Assoc-Type=MBB  |                        |
    |    Assoc-ID=G1     |                        |
    |    +TRIAL-LSP TLV  |                        |
    |      D-Flag=0      |                        |
    |      T-Flag=0      |                        |
    |                    |                        |



              Figure 2: Initiate Associate Group for old LSP

5.2.2.  Establish new Trial LSP

   As a first step of M-B-B procedure, a PCC establishes a new LSP for
   restoration once PCC receives a PCInitiate/PCUpd message with T flag
   (in TRIAL-LSP TLV) set to 1, in a ASSOCIATION Object from a PCE.  We
   call this newly established LSPs for restoration "trial LSP".  A
   trial LSP is signaled the same RSVP-TE Tunnel ID but different LSP ID
   from active working LSP, and both the active working LSP and new
   trial LSPs MUST be signaled with Shared Explicit style as describes
   in [RFC3209].

   When a new trial LSP was signaled successfully, the PCC sends a PCRpt
   message toward the PCE to notify the result.  The PCRpt message from
   the PCC MUST have the LSP object with LSP-IDENTIFIERS TLV that
   indicates RSVP-TE Tunnel ID and LSP ID the PCC has just established.

   If a new trial LSP failed to be established by some reason of RSVP-TE
   signaling, the PCC MUST send to the PCE a PCRpt message carrying LSP-
   IDENTIFIERS TLV and RSVP-ERROR-SPEC TLV as defined in [RFC8231]
   Section 7.3.4.





Tanaka, et al.          Expires September 8, 2019               [Page 9]


Internet-Draft           MBB using Stateful PCE               March 2019


   A PCC SHOULD accept multiple PCInitiate/PCUpd messages with TRIAL-LSP
   TLV in a ASSOCIATION Object.  And a PCC SHOULD establish as many
   trial lsps as the number of PCInitiate/PCUpd messages it receives.  A
   PCC may also choose to implement a limit on the number of such
   PCInitiate/PCUpd message.

   Figure 3 illustrates a example, working LSP(PLSP-ID P1, Tunnel ID T1,
   LSP-ID old, ERO Ingress-a-b-Egress), trial LSP(PLSP-ID P1, Tunnel ID
   T1, LSP-ID new, ERO Ingress-a-c-b-Egress).










































Tanaka, et al.          Expires September 8, 2019              [Page 10]


Internet-Draft           MBB using Stateful PCE               March 2019


                                     __c__
                                    /     \
   PCE               PCC(Ingress)--a-------b---Egress
    |   data traffic on old LSP                   |
    |                    |                        |
    |  PCInitiate/       |))))))))))))))))))))))))|
    |--PCUpd      ------>|          :             |
    |   LSP Object       |          :             |
    |    PLSP-ID=P1      |          :             |
    |    SRP-ID=S2       |          :             |
    |    Tunnel ID=T1    |                        |
    |    LSP ID=0        |                        |
    |   ASSOC Object     |                        |
    |    Assoc-Type=MBB  |                        |
    |    Assoc-ID=G1     |                        |
    |    +TRIAL-LSP TLV  |                        |
    |      D-Flag=0      |                        |
    |      T-Flag=1      |                        |
    |   ERO Obj=a-c-b    |                        |
    |                    |                        |
    |                    |---Path(LSP ID=new, --> |
    |                    |       ERO=a-c-b)       |
    |                    |                        |
    |                    | <----- Resv------------|
    |<--PCRpt   ---------|                        |
    |    LSP Object      |          :             |
    |     PLSP-ID=P1     |))))))))))))))))))))))))|
    |     SRP-ID=S2      |          :             |
    |     Tunnel ID=T1   |          :             |
    |     LSP ID=new     |          :             |
    |   ASSOC Object     |          :             |
    |    Assoc-Type=MBB  |          :             |
    |    Assoc-ID=G1     |          :             |
    |    +TRIAL-LSP TLV  |          :             |
    |      D-Flag=0      |          :             |
    |      T-Flag=1      |          :             |
    |    RRO Obj=a-c-b   |          :             |
    |                    |                        |



                        Figure 3: Establish new LSP

5.2.3.  Switchover Data Traffic triggered by a PCUpd message

   As a second step, the PCC(Ingress) transfers data traffic from a
   working LSP to a trial LSP.  To specify desired LSP for transferring




Tanaka, et al.          Expires September 8, 2019              [Page 11]


Internet-Draft           MBB using Stateful PCE               March 2019


   data traffic, a PCUpd message from a PCE MUST have a TRIAL-LSP TLV
   set D flag to 1, in a ASSOCIATION Object.

   Data switchover happens from old LSP to new trial LSP, once PCC
   receives a PCUpd message with D flag in TRIAL-LSP TLV set to 1 in the
   ASSOCIATION object from a PCE.

   The PCC SHOULD tear down the old working LSP and other trial LSPs
   which the data traffic is no longer used immediately once the data
   traffic successfully switched over (See Figure 4).

   [Editor's Note - Another option would be, a PCC tears down old lsp
   separately using mechanism in [RFC8281] for PCE-Initiated LSPs.]

   The PCC sends to the PCE a PCRpt message to notify the removal of
   both old LSP and other trial LSPs, which SRP-ID is set to 0x00000000.



































Tanaka, et al.          Expires September 8, 2019              [Page 12]


Internet-Draft           MBB using Stateful PCE               March 2019


                                     __c__
                                    /     \
   PCE               PCC(Ingress)--a-------b---Egress
    |                    |                        |
    |                    |))))))))))))))))))))))))|  data on old LSP
    |--PCUpd     ------> |))))))))))))))))))))))))|
    |   LSP Object       |}}}}}}}}}}}}}}}}}}}}}}}}|  data on new LSP
    |    PLSP ID=P1      |}}}}}}}}}}}}}}}}}}}}}}}}|
    |    SRP ID=S3       |}}}}}}}}}}}}}}}}}}}}}}}}|
    |    Tunnel ID=T1    |          :             |
    |    LSP ID=new      |          :             |
    |   ASSOC Object     |          :             |
    |    Assoc-Type=MBB  |                        |
    |    Assoc-ID=G1     |                        |
    |    +TRIAL-LSP TLV  |                        |
    |      D-Flag=1      |                        |
    |      T-Flag=0      |                        |
    |                    |                        |
    | <-- PCRpt  --------|                        |
    |   LSP Object       |                        |
    |    PLSP ID=P1      |                        |
    |    SRP ID=S3       |                        |
    |    Tunnel ID=T1    |                        |
    |    LSP ID=new      |                        |
    |                    |--PathTear(ERO a-b,  -->|  Tear down old
    |                    | Tunnel=T1,LSP ID=old)  |   automatically
    |                    |                        |
    | <-- PCRpt(O=Dn,R=1,|                        |
    |   PLSP ID=P1       |                        |
    |   SRP ID=0         |                        |
    |   Tunnel ID=T1     |                        |
    |   LSP-ID=old)      |                        |
    |                    |                        |
    |                    |                        |

            O flag = Operational flag in LSP object.
            R flag = Remove flag in LSP object.



          Figure 4: Transfer data traffic from old LSP to new LSP

6.  Protocol extension








Tanaka, et al.          Expires September 8, 2019              [Page 13]


Internet-Draft           MBB using Stateful PCE               March 2019


6.1.  Association group

   As per [I-D.ietf-pce-association-group], LSPs are associated with
   other LSPs with which they interact by adding them to a common
   association group.  The Association ID will be used to identify the
   MBB group a set of LSPs belongs to.  This document defines a new
   Association type, based on the generic Association object -

   o  Association type = TBD1 ("Explicit MBB Association Type").

   [I-D.ietf-pce-association-group] specify the mechanism for the
   capability advertisement of the association types supported by a PCEP
   speaker by defining a ASSOC-Type-List TLV to be carried within an
   OPEN object.  This capability exchange for the association type
   described in this document (i.e.  Explicit MBB Association Type) MUST
   be done before using the policy association, i.e., the PCEP speaker
   MUST include the Explicit MBB Association Type (TBD1) in the ASSOC-
   Type-List TLV before using this association type in the PCEP
   messages.

   This Association-Type is dynamic in nature and created by the PCC or
   PCE for the LSPs belonging to the same TE tunnel (as described in
   [RFC3209]) originating at the same head node and terminating at the
   same destination.  These associations are conveyed via PCEP messages
   to the PCEP peer.  Operator-configured Association Range MUST NOT be
   set for this association-type and MUST be ignored.

6.2.  Trial LSP TLV in ASSOCIATION Objects

   This document defines a new TLV named TRIAL-LSP TLV which can be
   optionally carried in the ASSOCIATION object.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type=TBD2           |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Flags                         |D|T|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                      Figure 5: TRIAL-LSP TLV format

   TRIAL-LSP TLV is an optional TLV of the ASSOCIATION Object and is
   used in a PCInitiate/PCUpd message especially to perform explicit
   mode M-B-B.  A PCC signals a trial LSP once it receives a PCUpd in
   which ASSOCIATION object has a TRIAL-LSP TLV.



Tanaka, et al.          Expires September 8, 2019              [Page 14]


Internet-Draft           MBB using Stateful PCE               March 2019


   T(Trial LSP - 1 bit):   This field MUST be set to 1 in a PCInitiate/
      PCUpd message when a PCE requests a PCC to signal new trial LSP.
      It MUST be zero for a working LSP.
   D(Data switchover - 1 bit):   This field MUST be set to 1 in a PCUpd
      message when a PCE requests a PCC to switchover data traffic for
      new trial LSP.  It MUST be zero otherwise.
   Flags:   None defined.  MUST be set to zero.  Ignored on receipt.

6.3.  Optional TLVs

   The MBB association group MAY carry some optional TLVs including but
   not limited to:

   o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor
   specific behavioral information,, described in [RFC7470].

6.4.  Error Handling

   As per the processing rules specified in section 5.4 of
   [I-D.ietf-pce-association-group], if a PCEP speaker does not support
   this association-type, it would return a PCErr message with Error-
   Type 26 (Early allocation by IANA) "Association Error" and Error-
   Value 1 "Association-type is not supported".

   All LSPs (new or old) within this association MUST belong to the same
   TE Tunnel (as described in [RFC3209]) and have the same source and
   destination.  If a PCEP speaker attempts to add an LSP to this
   association and the Tunnel ID (as carried in LSP-IDENTIFIERS TLV
   [RFC8231], with description as per [RFC3209]) or source or
   destination of the LSP is different from the LSP(s) in the PPAG, the
   PCC MUST send PCErr with Error-Type= 29 (Early allocation by IANA)
   (Association Error) [I-D.ietf-pce-association-group] and Error-Value
   = TBD (Tunnel ID or End points mismatch).

   All processing as per section 5.4 of [I-D.ietf-pce-association-group]
   continue to apply.

7.  Security Considerations

   This document defines one new type for association, which do not add
   any new security concerns beyond those discussed in [RFC5440],
   [RFC8231] and [I-D.ietf-pce-association-group] in itself.

8.  IANA Considerations







Tanaka, et al.          Expires September 8, 2019              [Page 15]


Internet-Draft           MBB using Stateful PCE               March 2019


8.1.  PCEP TLV Indicators

   This document defines the following new PCEP TLVs:

     Value     Meaning              Reference
       TBD2    TRIAL-LSP TLV        This document



8.2.  Association Object Type Indicator

   This document defines the following new association type originally
   defined in [I-D.ietf-pce-association-group].

     Value     Name                           Reference
       TBD1    MBB Association Type        This document



9.  Operational Considerations

9.1.  Operation in multiple PCEs

   In addition to basic operations under multiple PCEs as described in
   [RFC8231], a PCC supports both types of M-B-B operations.

   Implicit mode M-B-B requires only one PCUpd message to trigger M-B-B
   process, therefore a PCC accepts a message from a primary PCE whom
   the PCC delegates the LSPs to.  An attempt to update parameters of a
   non-delegated LSP results in the PCC sending a PCErr message as
   defined in [RFC8231].

   Explicit mode M-B-B requires at least three PCUpd messages(1. for new
   Association-Group creation, 2. for trial-LSP signaling, 3. for
   traffic switchover) to trigger each subsequent step.  All steps MUST
   be taken by one primary PCE because state synchronization of trial-
   LSPs between the primary and backup PCE may be complex.  If the PCC
   revokes LSP delegations after a Redelegation Timeout Interval, the
   PCC MUST tear down all trial-LSPs and redelegate a working LSP to
   alternate PCE.  An attempt to trigger either step of explicit mode
   M-B-B of a non-delegated LSP results in the PCC sending the same
   PCErr as implicit mode M-B-B.

10.  Acknowledgments

   Many thanks to Ina Minei, Adrian Farrel, Yimin Shen, and Xian Zhang
   for their ideas and feedback in documentation.




Tanaka, et al.          Expires September 8, 2019              [Page 16]


Internet-Draft           MBB using Stateful PCE               March 2019


11.  References

11.1.  Normative References

   [I-D.ietf-pce-association-group]
              Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
              Dhody, D., and Y. Tanaka, "PCEP Extensions for
              Establishing Relationships Between Sets of LSPs", draft-
              ietf-pce-association-group-08 (work in progress), March
              2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

11.2.  Informative References

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.








Tanaka, et al.          Expires September 8, 2019              [Page 17]


Internet-Draft           MBB using Stateful PCE               March 2019


   [RFC4426]  Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
              Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
              Recovery Functional Specification", RFC 4426,
              DOI 10.17487/RFC4426, March 2006,
              <https://www.rfc-editor.org/info/rfc4426>.

   [RFC4427]  Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
              (Protection and Restoration) Terminology for Generalized
              Multi-Protocol Label Switching (GMPLS)", RFC 4427,
              DOI 10.17487/RFC4427, March 2006,
              <https://www.rfc-editor.org/info/rfc4427>.

   [RFC7470]  Zhang, F. and A. Farrel, "Conveying Vendor-Specific
              Constraints in the Path Computation Element Communication
              Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
              <https://www.rfc-editor.org/info/rfc7470>.

Appendix A.  Contributors

   Dhruv Dhody
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   Email: dhruv.ietf@gmail.com

Authors' Addresses

   Yosuke Tanaka
   NTT Communications Corporation
   Granpark Tower
   3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan

   Email: yosuke.tanaka@ntt.com


   Yuji Kamite
   NTT Communications Corporation
   Granpark Tower
   3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan

   Email: y.kamite@ntt.com




Tanaka, et al.          Expires September 8, 2019              [Page 18]


Internet-Draft           MBB using Stateful PCE               March 2019


   Ramanjaneya Reddy Palleti
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   Email: ramanjaneya.palleti@huawei.com


   Cheng Li
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: chengli13@huawei.com


   Haomian Zheng
   Huawei Technologies
   H1-1-A043S Huawei Industrial Base, Songshanhu
   Dongguan, Guangdong  523808
   China

   Email: zhenghaomian@huawei.com


























Tanaka, et al.          Expires September 8, 2019              [Page 19]