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

Versions: 00 01 02 03 04 05 draft-ietf-pce-stateful-pce-lsp-scheduling

PCE Working Group                                              Y. Zhuang
Internet-Draft                                                     Q. Wu
Intended status: Standards Track                                D. Dhody
Expires: December 31, 2015                                        Huawei
                                                           June 29, 2015


          PCEP Extensions for LSP scheduling with stateful PCE
            draft-zhuang-pce-stateful-pce-lsp-scheduling-00

Abstract

   This document proposes a set of extensions needed to the stateful
   Path Computation Element (PCE) communication Protocol (PCEP), so as
   to enable Labeled Switched Path (LSP) scheduling for path computation
   and LSP setup/deletion based on the actual network resource usage
   duration of a traffic service in a centralized network environment.
   A scheduled LSP can be setup at the its starting time and deleted
   after its usage duration such that LSPs for the other traffic
   services can take over these network resources beyond that period.

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

   This Internet-Draft will expire on December 31, 2015.

Copyright Notice

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



Zhuang, et al.          Expires December 31, 2015               [Page 1]


Internet-Draft               LSP Scheduling                    June 2015


   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
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Motivation and Objectives . . . . . . . . . . . . . . . . . .   4
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   5
     4.1.  LSP scheduling Overview . . . . . . . . . . . . . . . . .   5
     4.2.  Support of LSP Scheduling . . . . . . . . . . . . . . . .   6
       4.2.1.  The Open Message  . . . . . . . . . . . . . . . . . .   6
       4.2.2.  Stateful PCE Capability TLV . . . . . . . . . . . . .   6
     4.3.  Scheduled LSP creation  . . . . . . . . . . . . . . . . .   7
       4.3.1.  The PCRpt Message . . . . . . . . . . . . . . . . . .   8
       4.3.2.  The PCUpd Message . . . . . . . . . . . . . . . . . .   8
       4.3.3.  The PCInitiate Message  . . . . . . . . . . . . . . .   8
       4.3.4.  LSP Object  . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Scheduled LSP information synchronization . . . . . . . .  10
       4.4.1.  The PCRpt Message . . . . . . . . . . . . . . . . . .  10
     4.5.  PCC initiated scheduled LSP . . . . . . . . . . . . . . .  10
     4.6.  Scheduled LSP activation and deletion . . . . . . . . . .  11
       4.6.1.  The PCUpd Message . . . . . . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  Manageability Consideration . . . . . . . . . . . . . . . . .  12
     6.1.  Control of Function and Policy  . . . . . . . . . . . . .  12
     6.2.  Information and Data Models . . . . . . . . . . . . . . .  12
     6.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  12
     6.4.  Verify Correct Operations . . . . . . . . . . . . . . . .  13
     6.5.  Requirements On Other Protocols . . . . . . . . . . . . .  13
     6.6.  Impact On Network Operations  . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  PCEP TLV Type Indicators  . . . . . . . . . . . . . . . .  13
     7.2.  LSP-SCHEDULING-CAPABLITY  . . . . . . . . . . . . . . . .  13
     7.3.  ACTIVATING-LSP  . . . . . . . . . . . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Appendix A.  Appendix A. Contributor Addresses  . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15








Zhuang, et al.          Expires December 31, 2015               [Page 2]


Internet-Draft               LSP Scheduling                    June 2015


1.  Introduction

   The Path Computation Element Protocol (PCEP) defined in [RFC5440] is
   used between a Path Computation Element (PCE) and a Path Computation
   Client (PCC) (or other PCE) to enable computation of Multi-protocol
   Label Switching (MPLS) for Traffic Engineering Label Switched Path
   (TE LSP).

   Further, in order to support use cases described in [I-D.ietf-pce-
   stateful-pce-app], [I-D.ietf-pce-stateful-pce] specifies a set of
   extensions to PCEP to enable stateful control of MPLS-TE and GMPLS
   LSPs via PCEP.

   Traditionally, the network resources, especially bandwidth, usage and
   allocation can be supported by a Network Management System operation
   such as path pre-establishment.  However, this does not provide
   efficient network usage since the established paths exclude the
   possibility of being used by other services even when they are not
   used for undertaking any service.

   With LSP scheduling, it allows network operators to reserve resources
   in advance according to the agreements with their customers, and
   allow them to transmit data with specified starting time and
   duration, for example for a scheduled bulk data replication between
   data centers.  It enables the activation of bandwidth usage at the
   time the service really being used while letting other services
   obtain it in spare time.  The requirement of scheduled LSP provision
   is mentioned in [I-D.ietf-pce-stateful-pce-app] and [RFC7399], so as
   to provide more efficient network resource usage for traffic
   engineering, which hasn't been solved yet.

   This document proposes a set of extensions needed to the stateful
   PCE, so as to enable LSP scheduling for path computation and LSP
   setup/deletion based on the actual network resource usage duration of
   a traffic service.  A scheduled LSP can be setup at the its starting
   time and deleted after its usage duration such that LSPs for the
   other traffic services can take over these network resources beyond
   that period.

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







Zhuang, et al.          Expires December 31, 2015               [Page 3]


Internet-Draft               LSP Scheduling                    June 2015


2.1.  Terminology

   The following terminologies are used in this document:

   Active Stateful PCE:  PCE that uses LSP state information learned
      from PCCs to optimize path computations.  Additionally, it
      actively updates delegated LSP states in those PCCs that delegated
      the control.

   Delegation:  An operation to grant a PCE temporary rights to modify a
      subset of LSP parameters on one or more PCC's LSPs.  LSPs are
      delegated from a PCC to a PCE.

   PCC:  Path Computation Client: any client application requesting a
      path computation to be performed by a Path Computation Element.

   PCE:  Path Computation Element.  An entity (component, application,
      or network node) that is capable of computing a network path or
      route based on a network graph and applying computational
      constraints.

   TE LSP:  Traffic Engineering Label Switched Path.

   Scheduled TE LSP:  a LSP that carries traffic flow demand at an
      activation time and last for a certain duration.  The PCE operates
      path computation per LSP availability at the required time and
      duration.

3.  Motivation and Objectives

   A stateful PCE can support better efficiency by using LSP scheduling
   described in the use case of [I-D.ietf-pce-stateful-pce].  This
   requires the PCE to maintain the scheduled LSPs and their associated
   resource usage, e.g. bandwidth, as well as the ability for PCC to
   trigger signaling for the LSP setup/tear-down at the correct time.

   Note that existing configuration tools can be used for LSP
   scheduling, but as highlighted in section 3.1.3 of [I-D.ietf-pce-
   stateful-pce], doing this as a part of PCEP, has obvious advantages.

   The objective of this document is to provide a set of extensions to
   PCEP to enable LSP scheduling for LSPs creation/deletion under the
   stateful PCE control, according to traffic services from customers,
   so as to improve the usage of network resources.







Zhuang, et al.          Expires December 31, 2015               [Page 4]


Internet-Draft               LSP Scheduling                    June 2015


4.  Architecture Overview

4.1.  LSP scheduling Overview

   The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for
   customers' traffic services at its actual usage time, so as to
   improve the network resource efficient utilization.

   For stateful PCE supporting LSP scheduling, there are two types of
   LSP databases used in this document.  One is the LSP-DB defined in
   PCEP [I-D.ietf-pce-stateful-pce], while the other is the scheduled
   LSP database (SLSP- DB, see section 6).  The SLSP-DB records
   scheduled LSPs and is used as a complementary to the TED and LSP-DB
   to show the network resource availability for path computation.  Note
   that the two types of LSP databases can be implemented in one
   physical database or two different databases.  This document does not
   state any preference here.

   In case of implementing PCC-initiated scheduled LSPs, at the time of
   delegation,a PCC can send a path computation LSP State Report message
   (PCRpt message) with LSP information of its starting time and the
   duration.  Upon receiving the PCRpt message with the scheduled LSP
   delegation, a stateful PCE SHALL not only check the current network
   resource availability recorded in the Traffic Engineering Database
   (TED) and LSP-DB, but also consider scheduled resource reservation
   for scheduled LSPs in the SLSP-DB and then the stateful PCE sends the
   path for the scheduled LSP in an LSP Update Request carried in a
   PCUpd message to the PCC.  Note that PCE can either calculate the
   path for scheduled LSP based on current information and update it
   later at any time based on network events or PCE MAY chooses to
   calculate the path closer to the activation time.

   In case of implementing PCE-Initiated Scheduling LSP, the stateful
   PCE can send a path computation LSP Initiate (PCInitiate message)
   with LSP information at its starting time and duration to reserve a
   path.  In addition, the stateful PCE may send PCUpd message at the
   time of activation to activate the path.

   In case of PCE Initiated LSP, it is recommended that PCE send
   PCInitiate at creation time so that these scheduled LSP is known at
   PCC and it can be further syncronized to other PCE as well. . At any
   time, stateful PCE may change the attribute of a scheduled LSP by
   sending the PCUpd message.

   Based on PCUpd or PCInitiate message, a PCC creates a LSP with
   scheduled LSP information.  This scheduled LSP MUST be added into the
   SLSP-DB and synchronized among PCEs and PCC via PCRpt message.  For a




Zhuang, et al.          Expires December 31, 2015               [Page 5]


Internet-Draft               LSP Scheduling                    June 2015


   scheduled LSP, a PCC MUST not trigger signaling for LSP setup at its
   creation time but wait until its starting time.

   For setup/activation of scheduled LSPs, PCC MAY activate the LSP at
   the starting time or PCE MAY control the activation, with active
   stateful PCE notifies the PCC that the status of the scheduled LSP
   has been changed and it SHOULD trigger signaling for the LSP setup.
   When the requested usage duration expires, PCC or active stateful PCE
   removes the LSP from the data base.

   The following terms are used in this document:

   o  Scheduled LSP: A LSP with the scheduling attributes, that is
      activated in future and last for a duration.  The PCE operates
      path computation per resource availability at the required time
      and duration.

   o  Starting time: This value indicates when the scheduled LSP is used
      and the corresponding LSP must be setup and active.  In other
      time, the LSP can be inactive to include the possibility of the
      resources being used by other services.

   o  Duration: the value indicates the time duration that the LSP is
      undertaken by a traffic flow and the corresponding LSP must be
      setup and active.  At the end of which, the LSP is teardown and
      removed from the data base.

4.2.  Support of LSP Scheduling

4.2.1.  The Open Message

   After a TCP connection for a PCEP session has been established, the
   PCE or the PCC can send an Open Message with the B flag in Stateful
   PCE Capability TLV set to 1 described in [section 4.2] to indicate
   that it supports LSP scheduling to its peer.  The definition of the
   Open message (see [RFC5440]) is unchanged.

4.2.2.  Stateful PCE Capability TLV

   A PCC and a PCE indicates its ability to support LSP scheduling
   during the PCEP session establishment phase.  The Open Object in the
   Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in [I-
   D.ietf-pce-stateful-pce].  A new flag is defined for the STATEFUL-
   PCE-CAPABILITY TLV defined in [I-D.ietf-pce-stateful-pce] and updated
   in [I-D.ietf-pce-pce-initiated-lsp] and [I-D.ietf-pce-stateful-sync-
   optimizations].





Zhuang, et al.          Expires December 31, 2015               [Page 6]


Internet-Draft               LSP Scheduling                    June 2015


   A new bit B (SCHED-LSP-CAPABLITY) flag is added in this document to
   indicate the support of LSP scheduling.

   B (LSP-SCHEDULING-CAPABILITY - 1 bit):  If set to 1 by a PCC, the B
      Flag indicates that the PCC allows LSP scheduling; if set to 1 by
      a PCE, the B Flag indicates that the PCE is capable of LSP
      scheduling.  The B bit MUST be set by both PECP peers in order to
      support LSP scheduling for path computation.

4.3.  Scheduled LSP creation

   In order to realize scheduled LSP in a centralized network
   environment, a PCC has to separate the setup of a LSP into two steps.
   The first step is to create a LSP but not signal it over the network.
   The second step is to signal the scheduled LSP over the LSRs (Labeled
   switched Router) at its starting time.

   For PCC Initiated scheduled LSPs, a PCC can send a path computation
   LSP report (PCRpt) message (see section 4.3.1) including its demanded
   resources with the starting time and its usage duration and
   delegation to a stateful PCE.

   Upon receiving the delegation via PCRpt message, the stateful PCE
   computes the path for the scheduled LSP per its starting time and
   duration based on the network resource availability from traffic
   engineering database (TED) (defined in [RFC5440]) and LSP-DB (defined
   in [I-D.ietf-pce-stateful-pce]), as well as scheduled resource
   reservation in the SLSP-DB (see section 6).

   If a resultant path is found, the stateful PCE will send a PCUpd
   message (see section 5.x) with path information back to the PCC as
   defined in [I-D.ietf-pce-stateful-pce].

   For PCE-Initiated Scheduled LSP, the stateful PCE can send a path
   computation LSP Initiate (PCInitiate message) with LSP information at
   its starting time and duration to reserve a path.

   Upon receiving the PCInitiate or PCUpd message for scheduled LSP from
   PCEs, tThe PCC then creates a scheduled LSP including the scheduled
   LSP information for the traffic but not trigger signaling for the LSP
   setup on LSRs.

   Note that PCE can either calculate the path for scheduled LSP based
   on current information and update it later at any time based on
   network events or PCE MAY chooses to calculate the path closer to the
   activation time.  In any case, stateful PCE can update the Sheduled
   LSP parameters on any network events using the PCUpd message.




Zhuang, et al.          Expires December 31, 2015               [Page 7]


Internet-Draft               LSP Scheduling                    June 2015


4.3.1.  The PCRpt Message

   After scheduled LSP capability negotiation and for PCC Initiated
   scheduled LSPs, PCC can send a PCRpt message including the SCHED-LSP-
   ATTRIBUTE TLV (see section 4.3.3.1) carried in the LSP Object (see
   section 4.3.3) body to indicate the requested LSP scheduling
   parameters for a customer's traffic service with the delegation bit
   set to 1 in LSP Object.  The value of requested bandwidth is taken
   via the existing 'Requested Bandwidth with BANDWIDTH Object- Type as
   1' defined in [RFC5440].

   The definition of the PCRpt message to carry LSP objects (see [I-
   D.ietf-pce-stateful-pce]) remains unchanged.

4.3.2.  The PCUpd Message

   To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL compute
   the path for the scheduled LSP carried on PCRpt message based on
   network resource availability recorded in TED, LSP-DB and SLSP-DB.

   If the request can be satisfied and an available path is found, the
   stateful PCE SHALL send a PCUpd Message including the SCHED- LSP-
   ATTRIBUTE TLV in the LSP Object body.

   Note that, the stateful PCE can update the Sheduled LSP parameters
   later as well based on any network events using the same PCUpd
   message.

4.3.3.  The PCInitiate Message

   To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL compute
   the path for the requesting traffic based on network resource
   availability recorded in TED, LSP-DB and SLSP-DB.

   If the request can be satisfied the stateful PCE SHALL send a
   PCInitiate Message including the SCHED-LSP-ATTRIBUTE TLV in the LSP
   Object body to request PCC to create a scheduled LSP.

   PCE can either calculate the path at initiation and update it later
   at any time based on network events or PCE MAY chooses to calculate
   the path closer to the activation time.

4.3.4.  LSP Object

   The LSP object is defined in [I-D.ietf-pce-stateful-pce].  This
   document add an optional SCHED-LSP-ATTRIBUTE TLV.





Zhuang, et al.          Expires December 31, 2015               [Page 8]


Internet-Draft               LSP Scheduling                    June 2015


   The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates
   that this LSP is requesting scheduled parameters.  The TLV MUST be
   present in LSP Object for each scheduled LSP carried in the
   PCInitiate message, the PCRpt message and the PCUpd message.

4.3.4.1.  SCHED-LSP-ATTRIBUTE TLV

   The SCHED-LSP-ATTRIBUTE TLV can be included as an optional TLV within
   the LSP object for LSP scheduling for the requesting traffic service.

   This TLV SHOULD be included only if both PCEP peers have set the B
   (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV
   carried in open message.

   The format of the SCHED-LSP-ATTRIBUTE TLV is shown in the following
   figure:

    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              |         Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Start Time (minutes)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Duration (minutes)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The type of the TLV is [TBD] and it has a fixed length of 8 octets.

   The fields in the format are:

   Start Time (32 bits):  This value in minutes, indicates when the
      scheduled LSP is used and the corresponding LSP must be setup and
      activated.  At the expiry of this time, the LSP is setup.
      Otherwise, the LSP is inactive to include the possibility of the
      resources to be used by other services.  The


   Duration (32 bits):  The value in minutes, indicates the duration
      that the LSP is undertaken by a traffic flow and the corresponding
      LSP must be up to carry traffic.  At the expiry of this time after
      setup, the LSP is tear down and deleted.


   Note, that the values of start time and duration is from the
   perspective of the PCEP peer that is sending the message, also note
   the unit of time is minutes, and thus the time spent on transmission
   on wire can be easily ignored.



Zhuang, et al.          Expires December 31, 2015               [Page 9]


Internet-Draft               LSP Scheduling                    June 2015


4.4.  Scheduled LSP information synchronization

   As for a stateful PCE, it maintains a database of LSPs (LSP-DB) that
   are active in the network, so as to reveal the available network
   resources and place new LSPs more cleverly.

   With the scheduled LSPs, they are not activated while creation, but
   should be considered when operating future path computation.  Hence,
   a scheduled LSP Database (SLSP-DB) is suggested to maintain all
   scheduled LSP information.

   The information of SLSP-DB MUST be shared and synchronized among all
   PCEs within the centralized network.  In order to synchronize the
   scheduled LSP information in SLSP-DB among PCEs and PCCs, the PCRpt
   Message is used as before.

4.4.1.  The PCRpt Message

   It is the responsibility of PCC to report the scheduled LSPs to all
   PCEs via a PCRpt message.  The message shall include the SCHED-LSP-
   ATTRIBUTE TLV within the LSP Object.

   Since the scheduled LSP is not signaled over the path yet, the
   mandatory LSP identifiers TLV should be all zero as defined in [I-
   D.ietf-pce-stateful-pce] but with the PLSP-ID for the LSP specified
   in the LSP object.

   Upon receiving the PCRpt message with scheduled LSP information, the
   PCE SHALL update the scheduled LSP information with its PLSP-ID into
   the SLSP-DB for further path computation.

4.5.  PCC initiated scheduled LSP

   In case of PCC initiated scheduled LSP, the PCC MAY delegate the
   scheduled LSP to an active stateful PCE via the PCRpt message with
   the D Flag set to 1 as stated in [I-D.ietf-pce-stateful-pce].  The
   scheduled LSP is created but not signaled over the LSRs.

   The stateful PCE MAY send a PCUpd Message including the SCHED- LSP-
   ATTRIBUTE TLV in the LSP Object body with the path now or later
   closer to the setup time.

   Note that, the stateful PCE can update the Sheduled LSP parameters at
   any time based on any network events using the same PCUpd message.







Zhuang, et al.          Expires December 31, 2015              [Page 10]


Internet-Draft               LSP Scheduling                    June 2015


4.6.  Scheduled LSP activation and deletion

   The PCC itself MAY activate the scheduled LSP at the starting time
   indicated in the SCHED-LSP-ATTRIBUTE TLV carried on PCUpd message or
   PCInitiate message by signaling the LSP over LSRs.  Alternatively,
   the active stateful PCE MAY activate the scheduled LSP immediately by
   using PCUpd message with A flag set (see section 4.5.2) to request
   the PCC to setup/activate the LSP.

   After the scheduled duration expires, the PCC itself MAY delete the
   LSP and release the resources and report the same to the PCEs.  Or,
   the active stateful PCE SHALL notify the PCC to delete the LSP and
   release the resources immediately via a PCUpd message with the R Flag
   set to 1 and the A Flag set to zero in the SRP object(see section
   4.5.2).  Upon receiving this message, the PCC shall trigger tear down
   to delete the LSP over the network.  Moreover, it SHALL notify all
   PCEs of deletion of this LSP via a PCRpt Message.

   Note that, the stateful PCE can update the Sheduled LSP parameters at
   any time based on any network events using the PCUpd message
   including SCHED-LSP-ATTRIBUTE TLV in the LSP Object body.

4.6.1.  The PCUpd Message

   PCC can activate and delete the scheduled LSP on its own based on the
   parameters in the SCHED-LSP-ATTRIBUTE TLV, but in some case PCE may
   override it and request PCC to activate or remove the LSP
   immediately.

   When the scheduled LSP needs to be activated, the active stateful PCE
   MAY send a PCUpd message with the A Flag set to 1 in the SRP
   object(see section 8.1) as well as ERO of the path for the LSP.  Upon
   receiving this PCUpd message, the PCC MUST trigger signaling to setup
   the LSP over the network nodes immediately.

   When the scheduled LSP needs to be removed, the active stateful PCE
   SHALL request the PCC to delete the LSP and release the resources for
   it via a PCUpd message with the R Flag set to 1 and the A Flag set to
   zero in the SRP object(see section 4.4.2).

4.6.1.1.  SRP Object

   The SRP Object is defined in [I-D.ietf-pce-stateful-pce] and a new
   flag is added to indicate activation of a scheduled LSP:







Zhuang, et al.          Expires December 31, 2015              [Page 11]


Internet-Draft               LSP Scheduling                    June 2015


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Flags                            |A|R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SRP-ID-number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Optional TLVs                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The R bit in flags field is defined in [I-D.  ietf-pce-pce-initiated-
   lsp].

   A (ACTIVATING-LSP - 1 bit):  On a PCUpd message , the A Flag set to 1
      indicates that this scheduled LSP SHALL be activated, which means
      it shall be up and ready to carry traffic.  The A Flag set to zero
      indicates no operation for this LSP.  For non-scheduled LSPs, this
      A flag shall set to zero.

5.  Security Considerations

   This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED- LSP-
   ATTRIBUTE TLV which does not add any new security concerns beyond
   those discussed in [RFC5440] and [I-D.ietf-pce-stateful-pce].

6.  Manageability Consideration

6.1.  Control of Function and Policy

   The LSP-Scheduling feature MUST BE controlled per tunnel by the
   active stateful PCE, the values for parameters like starting time,
   duration SHOULD BE configurable by customer applications and based on
   the local policy at PCE.

6.2.  Information and Data Models

   [RFC7420] describes the PCEP MIB, there are no new MIB Objects for
   this document.

6.3.  Liveness Detection and Monitoring

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440].





Zhuang, et al.          Expires December 31, 2015              [Page 12]


Internet-Draft               LSP Scheduling                    June 2015


6.4.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operation
   verification requirements in addition to those already listed in
   [RFC5440].

6.5.  Requirements On Other Protocols

   Mechanisms defined in this document do not imply any new requirements
   on other protocols.

6.6.  Impact On Network Operations

   Mechanisms defined in this document do not have any impact on network
   operations in addition to those already listed in [RFC5440].

7.  IANA Considerations

7.1.  PCEP TLV Type Indicators

   This document defines the following new PCEP TLV; IANA is requested
   to make the following allocations from this registry.

   Value     Meaning                         Reference
    TBD  SCHED-LSP-ATTRIBUTE            This document

7.2.  LSP-SCHEDULING-CAPABLITY

   This document requests that a registry is created to manage the Flags
   field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object.  New
   values are to be assigned by Standards Action [RFC5226].  Each bit
   should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   The following values are defined in this document:

   Bit    Description                                    Reference
    28    LSP-SCHEDULING-CAPABILITY (B-bit)   This document








Zhuang, et al.          Expires December 31, 2015              [Page 13]


Internet-Draft               LSP Scheduling                    June 2015


7.3.  ACTIVATING-LSP

   This document requests that a registry is created to manage the Flags
   field in the SRP object.  New values are to be assigned by Standards
   Action [RFC5226].  Each bit should be tracked with the following
   qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   The following values are defined in this document:

             Bit    Description               Reference
             30     ACTIVATING-LSP          This document

8.  References

8.1.  Normative References

   [I-D.ietf-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-ietf-pce-pce-initiated-lsp-04 (work in
              progress), April 2015.

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

   [I-D.ietf-pce-stateful-sync-optimizations]
              Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
              and D. Dhody, "Optimizations of Label Switched Path State
              Synchronization Procedures for a Stateful PCE", draft-
              ietf-pce-stateful-sync-optimizations-02 (work in
              progress), January 2015.

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

8.2.  Informative References







Zhuang, et al.          Expires December 31, 2015              [Page 14]


Internet-Draft               LSP Scheduling                    June 2015


   [I-D.ietf-pce-stateful-pce-app]
              Zhang, X. and I. Minei, "Applicability of a Stateful Path
              Computation Element (PCE)", draft-ietf-pce-stateful-pce-
              app-04 (work in progress), April 2015.

Appendix A.  Appendix A.  Contributor Addresses

      Zitao Wang
      Huawei
      101 Software Avenue, Yuhua District
      Nanjing, Jiangsu  210012
      China

      Email: wangzitao@huawei.com

      Xian Zhang
      Huawei Technologies
      Research Area F3-1B,
      Huawei Industrial Base,
      Shenzhen, 518129, China

      Email: zhang.xian@huawei.com

Authors' Addresses

   Yan Zhuang
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: zhuangyan.zhuang@huawei.com


   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com










Zhuang, et al.          Expires December 31, 2015              [Page 15]


Internet-Draft               LSP Scheduling                    June 2015


   Dhruv Dhody
   Huawei
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560037
   India

   Email: dhruv.ietf@gmail.com












































Zhuang, et al.          Expires December 31, 2015              [Page 16]


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