[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                          Y. Tanaka
Internet-Draft                                                 Y. Kamite
Intended status: Standards Track                      NTT Communications
Expires: August 22, 2013                                    Feb 18, 2013


 Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure
                           using Stateful PCE
                  draft-tanaka-pce-stateful-pce-mbb-00

Abstract

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

   In the current MPLS TE network using RSVP-TE, LSPs are often
   controlled by "make-before-break (M-B-B)" signaling by 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, one-
   stroke mode and granular 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.

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 http://datatracker.ietf.org/drafts/current/.

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




Tanaka & Kamite          Expires August 22, 2013                [Page 1]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


   This Internet-Draft will expire on August 22, 2013.

Copyright Notice

   Copyright (c) 2013 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.



































Tanaka & Kamite          Expires August 22, 2013                [Page 2]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Make-Before-Break LSP procedures . . . . . . . . . . . . . . .  6
     5.1.  One Stroke Make-Before-Break Mode  . . . . . . . . . . . .  7
     5.2.  Granular Make-Before-Break Mode  . . . . . . . . . . . . .  8
       5.2.1.  Establish new LSP triggered by a PCCreate message  . .  9
       5.2.2.  Transfer Data Traffic triggered by a PCUpd message . . 10
       5.2.3.  Tear Down old LSP triggered by a PCUpd message . . . . 11
   6.  Objects and TLV Formats  . . . . . . . . . . . . . . . . . . . 12
     6.1.  DATA-CONTROL TLV in LSP Objects  . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  PCEP TLV Indicators  . . . . . . . . . . . . . . . . . . . 13
     7.2.  PCEP Error Objects . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15




























Tanaka & Kamite          Expires August 22, 2013                [Page 3]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


1.  Introduction

   [I-D.ietf-pce-stateful-pce] describes the Stateful Path Computation
   Elements(PCE).  Stateful PCE defines the extensions to PCEP to enable
   stateful control of LSPs between and across PCEP sessions, and 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.

   [I-D.crabbe-pce-stateful-pce-protection] describes the extensions for
   the setup and management of MPLS-TE LSP path protection by PCE.  This
   specification is focused on the control of protection path, making
   protection paths which are pre-signaled ahead of the failure or set
   up after the failure.  The proposed extension is beneficial for PCEs
   to place several act/standby LSPs for protection purposes in MPLS
   network.

   Today, however, there is no detailed procedure specified as to how to
   restore and reoptimize one particular 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 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 to M-B-B method.  In this document, two types of
   restoration/reoptimization procedures are defined, one-stroke mode
   and granular 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", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119[RFC2119].


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.



Tanaka & Kamite          Expires August 22, 2013                [Page 4]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


   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 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.  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 LSPs' bandwidth in advance.  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 basicprocedure of Make-Before-Break is outlined as follows,

      1.  Establish a new LSP
      2.  Transfer data traffic from old LSP onto the new LSP
      3.  Tear down the old LSP

   In M-B-B, it is an important behavior that headend node treats 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 RSVP sessions with different LSP-IDs that share a
   common Tunnel IDs), and the headend will switch the traffic upon only
   one (or some) of those LSPs.  In some use cases about stateful PCE,
   it is expected that 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.





Tanaka & Kamite          Expires August 22, 2013                [Page 5]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


5.  Make-Before-Break LSP procedures

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

   The second one is "granular M-B-B mode", where the operation is
   triggered by a LSP Create Request(PCCreate) message from a PCE, and a
   PCE also controls timing and sequence of each granular step that a
   PCC takes.  This procedure additionally uses a new extended TLV that
   is defined in Section 6.1

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

   One-stroke 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 operation be delegated to centralized PCE.

   Granular mode is much more flexible than One-stroke mode since it
   allows PCEs to manage each LSP step-by-step.  Granular 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 all signaling of all LSPs are
   completed.  Similarly, there is a case under Software Defined Network
   (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, one stroke mode or granular
   mode, is to be performed by checking the type of PCEP messages that
   are exchanged.  The implementation MAY support both modes, but for



Tanaka & Kamite          Expires August 22, 2013                [Page 6]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


   each restoration/reoptimization operation, either one of them SHOULD
   be exclusively selected.

5.1.  One Stroke Make-Before-Break Mode

   This specifies the detailed procedure of M-B-B LSP restoration and
   reoptimization using exsisting messages which are defined in
   [I-D.ietf-pce-stateful-pce] and
   [I-D.crabbe-pce-stateful-pce-protection].  This procedure is based on
   the current existing messages/TLVs and no extended TLV is used.  Once
   a PCC receives PCUpd message from a PCE, the PCC automatically
   executes the one stroke M-B-B procedure.

   First, A PCUpd message is sent from PCE to trigger M-B-B procecure.
   This PCUpd message MUST carry a LSP Object with LSP Identifiers TLV.
   LSP Identifiers TLV format is specified in
   [I-D.crabbe-pce-stateful-pce-mpls-te].  This TLV contains the value
   for a desired new LSP ID.

   If the specified LSP ID value is a non-zero and is not currently used
   by the exsisting RSVP-TE sessions about the corresponding tunnel
   owned by the PCC, that value MUST be used for next signaling by PCC
   as headend, i.e., "make" a new LSP for restoration.  If the value is
   already used in the existing network in the specified tunnel, a PCC
   replies a PCEP Error message as defined in
   [I-D.ietf-pce-stateful-pce] with Error-type-19(Invalid Operation) and
   Error-Value=[TBD](Value already in use).

   If the specified LSP ID value is zero, the PCC MUST automatically
   assign a new LSP ID to signal restoration LSP.

   A PCC replies PCEP Error message to a PCE if a PCUpd does not carry
   LSP Identifiers TLV nor SYMBOLIC-PATH-NAME TLV.  Error-type-
   6(Mandatory Object Missing) and Error-Value=[TBD](See Section 7.2).

   If LSP Identifiers TLV or SYMBOLIC-PATH-NAME TLV in a PCUpd message
   is specifying non-delegated LSP, the PCC sends PCErr as defined in
   [I-D.ietf-pce-stateful-pce].

   Second, once a restoration LSP is successfully established, a PCC
   transfers data traffic from working LSP to restoration LSP.  If the
   restoration LSP failed in setup, the PCC MAY retry RSVP-TE signaling
   with possibly different attributes.

   Finally, when a PCC successfully transfered data traffic to
   restoration LSP, the PCC tears down the (previous) working LSP by
   RSVP-TE signaling, then the PCC MUST send a PCRpt message.  That
   PCRpt message MUST carry a LSP Object with LSP Identifiers TLV which



Tanaka & Kamite          Expires August 22, 2013                [Page 7]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


   indicates the value of RSVP-TE signaling the PCC has just
   established.

   Following Figure 1 illustrates the example of one stroke M-B-B
   procedure, in following conditions.
   working LSP :  ERO=a-b, Tunnel ID=T1, LSP ID=old
   restoration LSP :  ERO=a-c-b, Tunnel ID=T1, LSP ID=new

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

     O flag = Operational flag in LSP object.

     Figure 1: One Stroke Make-Before-Break Procedure


                                 Figure 1

5.2.  Granular Make-Before-Break Mode

   Compareing to the one stroke M-B-B mode, Granular M-B-B mode allows a
   PCE to control timing and sequence of subsequent make-before-break
   steps as follows.

   First, the PCE initiates PCC's signaling of a new LSP by sending a
   LSP Create Request(PCCreate) message.  Second, the PCE instructs the
   PCC to transfer data traffic from old LSP to new LSP by sending a PC



Tanaka & Kamite          Expires August 22, 2013                [Page 8]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


   Update Request(PCUpd) message with extension TLV that are defined in
   this document.  Third, the PCE instructs the PCC to tear down the old
   LSP by sending a PCUpd message indicating LSP removal.

   Note that this procedure uses not only PC Update Request(PCUpd) but
   also LSP Create Request(PCCreate) message that are defined in
   [I-D.crabbe-pce-pce-initiated-lsp].

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

5.2.1.  Establish new LSP triggered by a PCCreate message

   As a first step of M-B-B procedure, a PCC establishes a restoration
   LSP once PCC receives PCCreate message from a PCE.  This document
   defines a PCCreate message MUST have a LSP Object with LSP
   Identifiers TLV, which is used to specify Tunnel ID and the new LSP
   ID that the PCC must establish.

   [I-D.crabbe-pce-pce-initiated-lsp] defines that PCCreate message MUST
   contain LSPA object with SYMBOLIC-PATH-NAME TLV.  Regarding SYMBOLIC-
   PATH-NAME TLV, [I-D.crabbe-pce-pce-initiated-lsp] describes that
   SYMBOLIC-PATH-NAME TLV is mandatory and that value must not have
   conflict with LSP name of any existing LSP in the PCC.  If this
   specification is applied directly, PCE has to allocate different
   symbolic path name for every signaling of "make" procedure.  If
   conflict happens, it leads to PCEP Error from PCC. (authors' note: it
   needs further study about treatment of SYMBOLIC-PATH-NAME TLV
   particularly if there is a requirement for using the same symbolic
   path name for reoptimization and restoration.)

   When a new LSP was signaled successfully, the PCC sends a PCRpt
   message toward the PCE to notify the result by setting Operational
   flag 1 in the LSP object.  A PCRpt message from the PCC MUST have the
   LSP object with LSP Identifiers TLV that indicates Tunnel ID and LSP
   ID the PCC has just established.

   If a new LSP failed to be established by some reason of RSVP-TE
   signaling, the PCC MUST send PCRpt message carrying LSP Identifiers
   TLV and RSVP-ERROR-SPEC TLV as defined in [I-D.ietf-pce-stateful-pce]
   Section 7.2.2. to the PCE.

   Figure 2 illustrates a example, working LSP(Tunnel ID T1, LSP-ID old,
   ERO Ingress-a-b-Egress), restoration LSP(Tunnel ID T1, LSP-ID new,
   ERO Ingress-a-c-b-Egress).






Tanaka & Kamite          Expires August 22, 2013                [Page 9]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


                                     __c__
                                    /     \
   PCE               PCC(Ingress)--a-------b---Egress
    |   data traffic on old LSP                   |
    |                    |))))))))))))))))))))))))|
    |--PCCreate      --->|          :             |
    |  (tunnel ID=T1,    |          :             |
    |   LSP ID=new,      |                        |
    |   ERO=a-c-b )      |---Path(LSP ID=new, --> |
    |                    |       ERO=a-c-b)       |
    |                    |                        |
    |                    | <----- Resv------------|
    | <-- PCRpt(O=1, ----|                        |
    |      tunnel ID=T1, |))))))))))))))))))))))))|
    |      LSP ID=new,   |          :             |
    |      RRO=a-c-b)    |          :             |
    |                    |                        |

                 Figure 2: Establish new LSP


                                 Figure 2

5.2.2.  Transfer Data Traffic triggered by a PCUpd message

   As a second step, PCC(Ingress) transfers data traffic from primary
   LSP to restoration LSP.  To specify transferring data traffic, this
   document introduces a new TLV, called Data Contro TLV.

   PCUpd carries the Data Control TLV, which is used for transferring
   data traffic from one LSP to another(See Section 6.1).  And PCUpd
   also carries a LSP Identifiers TLV to specify the Tunnel ID and LSP
   ID that data traffic will get onto.

   Once the PCC receives the PCUpd message with LSP Identifier TLV and
   Data Control TLV in LSP Object, the PCC MSUT transfer data traffic
   from old LSP to new LSP immediately.(See Figure 3)

   If the LSP Identifiers TLV in the PCUpd message specifies invalid
   LSP, PCErr MUST be sent out from the PCC to the PCE.  The error
   message with Error-Type-19 (Invalid Operation) and Error-
   Value[TBD](See Section 7.2.









Tanaka & Kamite          Expires August 22, 2013               [Page 10]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


                                     __c__
                                    /     \
   PCE               PCC(Ingress)--a-------b---Egress
    |                    |                        |
    |                    |))))))))))))))))))))))))|  data on old LSP
    |--PCUpd     ------> |))))))))))))))))))))))))|
    |  (tunnel ID=T1,    |}}}}}}}}}}}}}}}}}}}}}}}}|  data on new LSP
    |   LSP ID=new,      |}}}}}}}}}}}}}}}}}}}}}}}}|
    |  +Data Control TLV)|          :             |
    |                    |          :             |
    |                    |                        |
    |                    |                        |
    | <-- PCRpt(O=1    --|                        |
    |      LSP ID=new,   |                        |
    |      RRO=a-c-b)    |                        |
    |                    |                        |

            O flag = Operational flag in LSP object.

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



                                 Figure 3

5.2.3.  Tear Down old LSP triggered by a PCUpd message

   As a final step of Make-Before-Break procedure, the PCC tears down
   the primary LSP which the data traffic is no longer used, by the
   PCUpd message from the PCE server.

   The PCC MUST tear down the LSP immediately once the PCC receives the
   PCUpd message setting Remove(R) flag 1.  The PCUpd message MUST carry
   LSP Identifiers TLV specifing Tunnel ID and LSP ID that will be torn
   down in the LSP Object.(See Figure 4).  Note that the PCC MUST tear
   down only the LSP that is specified in LSP Identifiers TLV.















Tanaka & Kamite          Expires August 22, 2013               [Page 11]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


                                     __c__
                                    /     \
   PCE               PCC(Ingress)--a-------b---Egress
    |              data on new LSP                |
    |                    |}}}}}}}}}}}}}}}}}}}}}}}}|
    |                    |          :             |
    |--PCUpd(R=1,   ---->|          :             |
    |   tunnel ID=T1,    |--PathTear(ERO a-b,  -->|  new LSP remains up
    |   LSP ID=old)      |   Tunnel=T1,LSP ID=old)|
    |                    |                        |
    |                    |                        |
    | <-- PCRpt(O=0,  ---|                        |
    |      Tunnel ID=T1, |                        |
    |      LSP ID=old)   |                        |
    |                    |                        |
    |                    |                        |

         R flag = Remove flag in LSP object.

            Figure 4: Tear down old LSP


                                 Figure 4


6.  Objects and TLV Formats

6.1.  DATA-CONTROL TLV in LSP Objects

   This document defines a new TLV named DATA-CONTROL TLV.


      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=TBD            |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          MUST be Zero         |        Flags                |D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Load Balance TLV (Optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5: DATA-CONTROL TLV format



                                 Figure 5




Tanaka & Kamite          Expires August 22, 2013               [Page 12]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


   LSP Identifiers TLV is mandatory in the LSP Object to use DATA-
   CONTROL TLV, which means DATA-CONTROL TLV requires the target to
   manipulate data plane.  The type of the TLV is [TBD] and it has a
   fixed length of 8 octets.  The value contains the following fields:

   Flags

      D (Data traffic - 1 bit):  Data traffic(D) bit indicates the Data
         traffic MUST get onto the LSP.  PCUpd message for Granular
         M-B-B mode uses this flag.  If there are multiple LSPs in a
         single Tunnel, all data traffic will go through only the LSP
         that is specified by LSP Object which contains this TLV, and
         stop data traffic through the other LSPs.

   Load Balance TLV(Optional TLV)
      This field is used for load balancing and is available only when
      the Data(D) flag is positive.
      Load Balance type - 7 bit :  This field indicates the type of load
         balance.(i.e.  Hash function, Round-Robin, ToS base)
      Continue flag - 1 bit :  If this flag set to 1, it indicates the
         next LSP Object in the PCUpd has also Load Balance TLV.  If
         this flag set to 0, it indicates no more LSP Object continues
         and load balance calculation will be completed, then Load
         Balance MUST be activated.
      Type of Service - 8 bit:  This field is used when the Load Balance
         type specifies ToS base.  Otherwise, this field is to be Zero.
      Percentage field - 16 bit :  This field specifies ratio of load
         balance.  The sum of this field across subsequent LSP Object
         has to be hundred percent.


7.  IANA Considerations

7.1.  PCEP TLV Indicators

   This document defines the following new PCEP TLVs:

     Value     Meaning              Reference
       TBD     DATA-CONTROL         This document



7.2.  PCEP Error Objects

   This document defines new Error-Type and Error-Value for the
   following new error conditions:





Tanaka & Kamite          Expires August 22, 2013               [Page 13]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


    Error-Type  Meaning
       6        Mandatory Object missing
                 Error-value=TBD:  LSP Identifiers TLV missing

       19       Invalid operation
                 Error-value=TBD:  Value already in use.
                                    for one stroke mode
                 Error-value=TBD:  Specified LSP is not existing.
                                    for granular mode
                 Error-value=TBD:  Specified LSP is not operational.
                                    for granular mode



8.  Security Considerations

   TBD


9.  Acknowledgments


10.  References

10.1.  Normative References

   [I-D.crabbe-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-crabbe-pce-pce-initiated-lsp-00 (work in
              progress), October 2012.

   [I-D.crabbe-pce-stateful-pce-mpls-te]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "Stateful
              PCE extensions for MPLS-TE LSPs",
              draft-crabbe-pce-stateful-pce-mpls-te-00 (work in
              progress), October 2012.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
              Extensions for Stateful PCE",
              draft-ietf-pce-stateful-pce-02 (work in progress),
              October 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element



Tanaka & Kamite          Expires August 22, 2013               [Page 14]


Internet-Draft     M-B-B procedure using Stateful PCE           Feb 2013


              (PCE) Communication Protocol (PCEP)", RFC 5440,
              March 2009.

10.2.  Informative References

   [I-D.crabbe-pce-stateful-pce-protection]
              Crabbe, E., Medved, J., Minei, I., and R. Torvi, "PCEP
              Extensions for MPLS-TE LSP protection with stateful PCE",
              draft-crabbe-pce-stateful-pce-protection-00 (work in
              progress), October 2012.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

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

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


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 & Kamite          Expires August 22, 2013               [Page 15]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/