Internet DRAFT - draft-zhuang-pce-stateful-pce-lsp-scheduling

draft-zhuang-pce-stateful-pce-lsp-scheduling







PCE Working Group                                           H. Chen, Ed.
Internet-Draft                                            Y. Zhuang, Ed.
Intended status: Standards Track                                   Q. Wu
Expires: September 28, 2017                                     D. Dhody
                                                                  Huawei
                                                           D. Ceccarelli
                                                                Ericsson
                                                          March 27, 2017


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

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 as
   stated in [I.D.ietf-teas-scheduled-resources].

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 September 28, 2017.

Copyright Notice

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



Chen, et al.           Expires September 28, 2017               [Page 1]

Internet-Draft               LSP Scheduling                   March 2017


   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 . . . . . . . . . . . . . .   4
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Motivation and Objectives . . . . . . . . . . . . . . . . . .   5
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   5
     4.1.  LSP scheduling Overview . . . . . . . . . . . . . . . . .   5
     4.2.  Support of LSP Scheduling . . . . . . . . . . . . . . . .   6
       4.2.1.  LSP Scheduling  . . . . . . . . . . . . . . . . . . .   7
       4.2.2.  Periodical LSP Scheduling . . . . . . . . . . . . . .   7
       4.2.3.  Stateful PCE Capability TLV . . . . . . . . . . . . .   8
     4.3.  Scheduled LSP creation  . . . . . . . . . . . . . . . . .   9
       4.3.1.  The PCReq message and PCRpt Message . . . . . . . . .  10
       4.3.2.  The PCRep Message . . . . . . . . . . . . . . . . . .  11
       4.3.3.  The PCUpd Message . . . . . . . . . . . . . . . . . .  11
       4.3.4.  LSP Object  . . . . . . . . . . . . . . . . . . . . .  12
     4.4.  Scheduled LSP Updates . . . . . . . . . . . . . . . . . .  15
     4.5.  Scheduled LSP activation and deletion . . . . . . . . . .  15
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   6.  Manageability Consideration . . . . . . . . . . . . . . . . .  16
     6.1.  Control of Function and Policy  . . . . . . . . . . . . .  16
     6.2.  Information and Data Models . . . . . . . . . . . . . . .  16
     6.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  16
     6.4.  Verify Correct Operations . . . . . . . . . . . . . . . .  16
     6.5.  Requirements On Other Protocols . . . . . . . . . . . . .  16
     6.6.  Impact On Network Operations  . . . . . . . . . . . . . .  16
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  PCEP TLV Type Indicators  . . . . . . . . . . . . . . . .  17
     7.2.  LSP-SCHEDULING-CAPABLITY  . . . . . . . . . . . . . . . .  17
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Appendix A.  Scheduled LSP information synchronization  . . . . .  19
   Appendix B.  Contributor Addresses  . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20








Chen, et al.           Expires September 28, 2017               [Page 2]

Internet-Draft               LSP Scheduling                   March 2017


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 usage and allocation of network resources,
   especially bandwidth, 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.  [I-D.ietf-teas-scheduled-
   resources] then provides a framework that describes and discusses the
   problem and propose an appropriate architecture for the scheduled
   reservation of TE resources.

   With the scheduled reservation of TE resources, it allows network
   operators to reserve resources in advance according to the agreements
   with their customers, and allow them to transmit data with scheduling
   such as 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.  Also, for deterministic networks, the scheduled LSP can
   provide a better network resource usage for guaranteed links.  This
   idea can also be applied in segment routing to schedule the network
   resources over the whole network in a centralized manner as well.

   With this in mind, 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 is
   characterized by a starting time and a duration.  When the end of the
   LSP life is reached, it is deleted to free up the resources for other
   LSP (scheduled or not).






Chen, et al.           Expires September 28, 2017               [Page 3]

Internet-Draft               LSP Scheduling                   March 2017


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

2.1.  Terminology

   The following terminologies are re-used from existing PCE documents.

   o  Active Stateful PCE [I-D.ietf-pce-stateful-pce];

   o  Delegation [I-D.ietf-pce-pce-initiated-lsp];

   o  PCC [RFC5440], [I-D.ietf-pce-stateful-pce];

   o  PCE [RFC5440], [I-D.ietf-pce-stateful-pce];

   o  TE LSP [RFC5440], [I-D.ietf-pce-stateful-pce];

   o  TED [RFC5440], [I-D.ietf-pce-stateful-pce];

   o  LSP DB [RFC5440], [I-D.ietf-pce-stateful-pce];

   In addition, this document defines the following terminologies.

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

   Scheduled LSP DB:  a database of scheduled LSPs

   Scheduled TED:  Traffic engineering database with the awareness of
      scheduled resources for TE.  This database is generated by the PCE
      from the information in TED and scheduled LSP DB and allows
      knowing, at any time, the amount of available resources (does not
      include failures in the future).

   Starting time(start-time):  This value indicates when the scheduled
      LSP is used and the corresponding LSP must be setup and active.
      In other time(i.e., before the starting time or after the starting
      time plus Duration), the LSP can be inactive to include the
      possibility of the resources being used by other services.

   Duration:  The value indicates the time duration that the LSP is
      undertaken by a traffic flow and the corresponding LSP must be




Chen, et al.           Expires September 28, 2017               [Page 4]

Internet-Draft               LSP Scheduling                   March 2017


      setup and active.  At the end of which, the LSP is teardown and
      removed from the data base.

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 for Packet-switched network, as well
   as the ability 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] as well as discussions in [I-D.ietf-teas-scheduled-
   resources], doing this as a part of PCEP in a centralized manner, 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.

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

   Furthermore, a scheduled TED can be generated from the scheduled LSP
   DB, LSP DB and TED to indicate the network links and nodes with
   resource availability information for now and future.  The scheduled
   TED should be maintained by all PCEs within the network environment.

   In case of implementing PCC-initiated scheduled LSPs, a PCC can
   request a path computation with LSP information of its scheduling
   parameters, including the starting time and the duration.  Upon



Chen, et al.           Expires September 28, 2017               [Page 5]

Internet-Draft               LSP Scheduling                   March 2017


   receiving the request with the scheduled LSP delegation, a stateful
   PCE SHALL check the scheduled TED for the network resource
   availability on network nodes and computes a path for the LSP with
   the scheduling information.

   For a multiple PCE environment, in order to coordinate the scheduling
   request of the LSP path over the network, the PCE needs to send a
   requestmessage with the path information as well as the scheduled
   resource for the scheduled LSP to other PCEs within the network, so
   as to coordinate with their scheduled LSP DBs and scheduled TEDs.
   Once other PCEs receive the request message with the scheduled LSPs
   information, if not conflicting with their scheduled LSP DBs, they
   reply to the requesting PCE with a response message carrying the
   scheduled LSP and update their scheduled LSP DBs and scheduled TEDs.
   After the requesting PCE confirms with all PCEs, the PCE SHALL add
   the scheduled LSP into its scheduled LSP Database and update its
   scheduled TED.

   Then the stateful PCE can response to the PCC with the path for the
   scheduled LSP to notify the result of the computation.  However, the
   PCC should not signal the LSP over the path once receiving these
   messages since the path is not activated yet until its starting time.

   Alternatively, the service can also be initiated by PCE itself.  In
   case of implementing PCE-initiated scheduled LSP, the stateful PCE
   shall check the network resource availability for the traffic and
   computes a path for the scheduled LSP per request in the same way as
   in PCC- Initiated mode and then for a multiple PCE network
   environment, coordinate the scheduled LSP with other PCEs in the
   network in the same way as in the PCC-Initiated mode.

   In both modes, for activation of scheduled LSPs, the stateful PCE can
   send a path computation LSP Initiate (PCInitiate message) with LSP
   information at its starting time to the PCC for signaling the LSP
   over the network nodes as defined in [I-D.ietf-pce-pce- initiated-
   lsp].  Also, in the PCC-initiated mode, with scheduling information
   ,the PCC can activate the LSP itself by triggering over the path at
   its starting time as well.  When the scheduling usage expires, active
   stateful PCE SHALL remove the LSP from the network , as well as
   notify other PCEs to delete the scheduled LSP from the scheduled LSP
   database.

4.2.  Support of LSP Scheduling








Chen, et al.           Expires September 28, 2017               [Page 6]

Internet-Draft               LSP Scheduling                   March 2017


4.2.1.  LSP Scheduling

   For a scheduled LSP, a user configures it with an arbitrary
   scheduling duration time Ta to time Tb, which may be represented as
   [Ta, Tb].

   When an LSP is configured with arbitrary scheduling duration [Ta,
   Tb], a path satisfying the constraints for the LSP in the scheduling
   duration is computed and the LSP along the path is set up to carry
   traffic from time Ta to time Tb.

4.2.2.  Periodical LSP Scheduling

   In addition to LSP Scheduling at an arbitrary time period, there are
   also periodical LSP Scheduling.

   A periodical LSP Scheduling represents Scheduling LSP every time
   interval.  It has a scheduling duration such as [Ta, Tb], a number of
   repeats such as 10 (repeats 10 times), and a repeat cycle/time
   interval such as a week (repeats every week).  The scheduling
   interval: "[Ta, Tb] repeats n times with repeat cycle C" represents
   n+1 scheduling intervals as follows:

   [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC]

   When an LSP is configured with a scheduling interval such as "[Ta,
   Tb] repeats 10 times with a repeat cycle a week" (representing 11
   scheduling intervals), a path satisfying the constraints for the LSP
   in each of the scheduling intervals represented by the periodical
   scheduling interval is computed and the LSP along the path is set up
   to carry traffic in each of the scheduling intervals.

4.2.2.1.  Elastic Time LSP Scheduling

   In addition to the basic LSP scheduling at an arbitrary time period,
   another option is elastic time intervals, which is represented as
   within -P and Q, where P and Q is an amount of time such as 300
   seconds.  P is called elastic range lower bound and Q is called
   elastic range upper bound.

   For a simple time interval such as [Ta, Tb] with an elastic range,
   elastic time interval: "[Ta, Tb] within -P and Q" means a time period
   from (Ta+X) to (Tb+X), where -P <= X <= Q.  Note that both Ta and Tb
   may be shifted the same X.

   When an LSP is configured with elastic time interval "[Ta, Tb] within
   -P and Q", a path is computed such that the path satisfies the
   constraints for the LSP in the time period from (Ta+X) to (Tb+X)



Chen, et al.           Expires September 28, 2017               [Page 7]

Internet-Draft               LSP Scheduling                   March 2017


   and |X| is the minimum value from 0 to max(P, Q).  That is that
   [Ta+X, Tb+X] is the time interval closest to time interval [Ta, Tb]
   within the elastic range.  The LSP along the path is set up to carry
   traffic in the time period from (Ta+X) to (Tb+X).

   Similarly, for a recurrent time interval with an elastic range,
   elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C
   within -P and Q" represents n+1 simple elastic time intervals as
   follows:

   [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn]
                             where -P <= Xi <= Q, i = 0, 1, 2, ..., n.

   If a user wants to keep the same repeat cycle between any two
   adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n
   times with repeat cycle C within -P and Q SYNC" may be used, which
   represents n+1 simple elastic time intervals as follows:

   [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X]
                             where -P <= X <= Q.

4.2.2.2.  Graceful Periods

   Besides the stated time scheduling, a user may want to have some
   graceful periods for each or some of the time intervals for the LSP.
   Two graceful periods may be configured for a time interval.  One is
   the graceful period before the time interval, called grace-before,
   which extends the lifetime of the LSP for grace-before (such as 30
   seconds) before the time interval.  The other is the one after the
   time interval, called grace-after, which extends the lifetime of the
   LSP for grace-after (such as 60 seconds) after the time interval.

   When an LSP is configured with a simple time interval such as [Ta,
   Tb] with graceful periods such as grace-before GB and grace-after GA,
   a path is computed such that the path satisfies the constraints for
   the LSP in the time period from Ta to Tb.  The LSP along the path is
   set up to carry traffic in the time period from (Ta-GB) to (Tb+GA).
   During graceful periods from (Ta-GB) to Ta and from Tb to (Tb+GA),
   the LSP is up to carry traffic (maybe in best effort).

4.2.3.  Stateful PCE Capability TLV

   After a TCP connection for a PCEP session has been established, a PCC
   and a PCE indicates its ability to support LSP scheduling during the
   PCEP session establishment phase.  For a multiple-PCE environment,
   the PCEs should also establish PCEP session and indicate its ability
   to support LSP scheduling among PCEP peers.  The Open Object in the
   Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in [I-



Chen, et al.           Expires September 28, 2017               [Page 8]

Internet-Draft               LSP Scheduling                   March 2017


   D.ietf-pce-stateful-pce].  Note that the STATEFUL- PCE-CAPABILITY TLV
   is 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].  In this document, we define a new flag bit B (SCHED-
   LSP-CAPABLITY) flag for the STATEFUL- PCE-CAPABILITY TLV to indicate
   the support of LSP scheduling and another flag bit PD (PD-LSP-
   CAPABLITY) to indicate the support of LSP periodical 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 PCEP peers in order to
      support LSP scheduling for path computation.

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

4.3.  Scheduled LSP creation

   In order to realize PCC-Initiated 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 request and get 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
   request (PCReq) message (see section 4.3.1) or a path computation LSP
   report (PCRpt) message (see section 4.3.1) including its demanded
   resources with the scheduling information 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 stored in
   scheduled TED (see section 4.1).

   If a resultant path is found, the stateful PCE will send a PCReq
   message with the path information as well as the scheduled resource
   information for the scheduled LSP to other PCEs within the network if
   there is any, so as to keep their scheduling information
   synchronized.

   Once other PCEs receive the PCReq message with the scheduled LSP, if
   not conflicts with their scheduled LSP DBs, they will reply to the



Chen, et al.           Expires September 28, 2017               [Page 9]

Internet-Draft               LSP Scheduling                   March 2017


   requesting PCE with a PCRep message carrying the scheduled LSP and
   update their scheduled LSP DBs and scheduled TEDs.  After the
   requesting PCE confirms with all PCEs, the PCE SHALL add the
   scheduled LSP into its scheduled LSP DB and update its scheduled TED.
   If conflicts happen or no path available is found, the requesting PCE
   SHALL return a PCRep message with NO PATH back to the PCC.
   Otherwise, the stateful PCE will send a PCRep message or PCUpd
   message (see section 4.3.3) with the path information back to the PCC
   as confirmation.

   For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path
   for the scheduled LSP per requests from network management systems
   automatically based on the network resource availability in the
   scheduled TED and coordinate with other PCEs on the scheduled LSP in
   the same way as in the PCC- Initiated mode.

   In both modes:

   o  the stateful PCE is required to update its local scheduled LSP DB
      and scheduled TED with the scheduled LSP.  Besides, it shall send
      a PCReq message with the scheduled LSP to other PCEs within the
      network, so as to achieve the scheduling traffic engineering
      information synchronization.

   o  Upon receiving the PCRep message or PCUpd message for scheduled
      LSP from PCEs with a found path, the PCC knows that it gets a
      scheduled path for the LSP but not trigger signaling for the LSP
      setup on LSRs.

   o  In any case, stateful PCE can update the Scheduled LSP parameters
      on any network events using the PCUpd message to PCC as well as
      other PCEs.

   o  When it is time (i.e., at the start time) for the LSP to be set
      up, the delegated PCE sends a PCEP Initiate request to the head
      end LSR providing the path to be signaled.

4.3.1.  The PCReq message and PCRpt Message

   After scheduled LSP capability negotiation, for PCC-Initiated mode, a
   PCC can send a PCReq message or a PCRpt message including the SCHED-
   LSP- ATTRIBUTE TLV (see section 4.3.4.1) or SCHED-PD-LSP-ATTRIBUTE
   TLV (see section 4.3.4.2) carried in the LSP Object (see section
   4.3.4) 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].



Chen, et al.           Expires September 28, 2017              [Page 10]

Internet-Draft               LSP Scheduling                   March 2017


   Meanwhile, for both modes (PCC-Initiated and PCE-Initiated), the
   delegated PCE shall distribute the scheduling information to other
   PCEs in the environment by sending a PCReq message with the SCHED-
   LSP-ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV, as well as the
   Bandwith Object and RRO for the found path.

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

4.3.2.  The PCRep Message

   To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL compute
   the path for the scheduled LSP carried on PCReq message based on
   network resource availability recorded in scheduled TED which is
   generated from the scheduled LSP-DB and TED and also synchronize the
   scheduling with other PCEs in the environment by using PCReq message
   with path and resource information for the scheduled LSP.

   If no conflict exists, other PCEs SHALL send a PCRep message with the
   SCHED-LSP-ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV, as well as the
   Bandwith Object and RRO back to the requesting PCE.

   If the LSP request can be satisfied and an available path is found,
   the stateful PCE SHALL send a PCRep Message including the SCHED- LSP-
   ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV in the LSP Object body,
   as well as the Bandwith Object and RRO for the found path back to the
   PCC as a successful acknowledge.

   If conflicts happen or no path available is found, the requesting PCE
   SHALL return a PCRep message with NO PATH back to the PCC.

4.3.3.  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 scheduled TED which is
   generated from the scheduled LSP-DB, LSP DB and TED.

   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 or SCHED-PD-LSP-ATTRIBUTE TLV in the LSP Object body to
   the PCC Note that, the stateful PCE can update the Scheduled LSP
   parameters later as well based on any network events using the same
   PCUpd message.

   If conflicts happen or no path available is found, the requesting PCE
   SHALL return a PCUpd message with ERO empty.




Chen, et al.           Expires September 28, 2017              [Page 11]

Internet-Draft               LSP Scheduling                   March 2017


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 for normal LSP
   scheduling and an optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical
   LSP scheduling.

   The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates
   that this LSP is requesting scheduled parameters while the SCHED-PD-
   LSP-ATTRIBUTE TLV indicates that this scheduled LSP is periodical.
   The scheduled LSP attribute TLV MUST be present in LSP Object for
   each scheduled LSP carried in the PCReq message, the PCRpt message
   and the PCUpd message.  For periodical LSPs, the SCHED-PD-LSP-
   ATTRIBUTE TLV can be used in LSP Object.

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 to carry traffic and the corresponding LSP
      must be setup and activated.


   Duration (32 bits):  The value in minutes, indicates the duration
      that the LSP is undertaken by a traffic flow and the corresponding



Chen, et al.           Expires September 28, 2017              [Page 12]

Internet-Draft               LSP Scheduling                   March 2017


      LSP must be up to carry traffic.  At the expiry of this duration,
      the LSP is tear down and deleted.


   Note, that the values of starting 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.

   Editor Note 1: As described in [I-D.zhuang-teas-scheduled-
   resources],the encoding of the resource state information could also
   be expressed as a start time and end time.  Multiple periods,
   possibly of different lengths, may be associated with one reservation
   request, and a reservation might repeat on a regular cycle.

   Editor Notes2: The time stated in this section and in section 4.3.4.2
   may be a relative time or an absolute time, which need more
   discussions.

   Editor Note3: the elastic interval and graceful interval may also be
   applied to the random LSP scheduling which need more discussion.

4.3.4.2.  SCHED-PD-LSP-ATTRIBUTE TLV

   The periodical LSP is a special case of LSP scheduling.  The traffic
   service happens in a series of repeated time intervals.  The SCHED-
   PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the
   LSP object for this periodical LSP scheduling.

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

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
















Chen, et al.           Expires September 28, 2017              [Page 13]

Internet-Draft               LSP Scheduling                   March 2017


      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 (3)           |         Length                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Start-Time                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Duration                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Repeat-time-length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Options |       Number-repeats          |    Reserved (0)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                GrB            |             GrA               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Elastic-Lower-Bound      |      Elastic-Upper-Bound      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Start-Time (32 bits):  This value in minutes, indicates the time when
      the scheduled LSP is used to carry traffic and the corresponding
      LSP must be setup and activated.

   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.

   Repeat-time-length:  The time length in minutes after which LSP
      starts to carry traffic again for (Start Time-End Time).

   Options:   Indicates a way to repeat.

         Options = 1: repeat every day;

         Options = 2: repeat every week;

         Options = 3: repeat every month;

         Options = 4: repeat every year;

         Options = 5: repeat every Repeat-time-length.

   Number-repeats:  The number of repeats.  In each of repeats, LSP
      carries traffic.

   In addition, it contains an non zero grace-before and grace-after if
   graceful periods are configured.  It includes an non zero elastic
   range lower bound and upper bound if there is an elastic range
   configured.



Chen, et al.           Expires September 28, 2017              [Page 14]

Internet-Draft               LSP Scheduling                   March 2017


   o  GrB (Grace-Before): The graceful period time length in seconds
      before the starting time.

   o  GrA (Grace-After): The graceful period time length in seconds
      after time interval [starting time, starting time + duration].

   o  Elastic-Lower-Bound: The maximum amount of time in seconds that
      time interval can shift to lower/left.

   o  Elastic-Upper-Bound: The maximum amount of time in seconds that
      time interval can shift to upper/right.

4.4.  Scheduled LSP Updates

   After a scheduled LSP is configured, a user may change its parameters
   including the requested time as well as the bandwidth.

   In PCC-Initiated case, the PCC can send a PCRpt message for the
   scheduled LSP with updated bandwidth as well as scheduled information
   included in the SCHED-LSP-ATTRIBUTE TLV (see section 4.3.4.1) or
   SCHED-PD-LSP-ATTRIBUTE TLV carried in the LSP Object.  The PCE should
   calculate the updated resources and synchronized with other PCEs.  If
   the updates can be satisfied, PCE shall return a PCUpd message to PCC
   as described in section 4.3.3.  If the requested updates cannot be
   met, PCE shall return a PCUpd message with the original reserved
   attributes carried in the LSP Object.

   The stateful PCE can update the Scheduled LSP parameters to other
   PCEs and the requested PCC at any time based on any network events
   using the PCUpd message including SCHED-LSP-ATTRIBUTE TLV or SCHED-
   PD-LSP-ATTRIBUTE TLV in the LSP Object body.

4.5.  Scheduled LSP activation and deletion

   In PCC-Initiated LSP scheduling, the PCC itself MAY activate the
   scheduled LSP at the starting time.  Alternatively, the stateful PCE
   MAY activate the scheduled LSP at its scheduled time by send a
   PCInitiated message.

   After the scheduled duration expires, the PCE shall send a PCUpd
   message with R flag set to the PCC to delete the LSP over the path,
   as well as to other PCEs to remove the scheduled LSP in the
   databases.  Additionally, it shall update its scheduled LSP DB and
   scheduled TED.

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



Chen, et al.           Expires September 28, 2017              [Page 15]

Internet-Draft               LSP Scheduling                   March 2017


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

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








Chen, et al.           Expires September 28, 2017              [Page 16]

Internet-Draft               LSP Scheduling                   March 2017


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
    TBD  SCHED-PD-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
    29    PD-LSP-CAPABLITY (PD-bit)                This document

8.  Acknowledgments

   This work has benefited from the discussions of resource scheduling
   on the mailing list and with Huaimo chen, author of [I-D.chen-pce-
   tts] since Prague meeting.  We gratefully acknowledge the
   contributions of Huaimo Chen.  The authors of this document would
   also like to thank Rafal Szarecki,Adrian Farrel, Cyril Margaria, Xian
   Zhang for the review and comments.

9.  References

9.1.  Normative References

   [I-D.dhody-pce-stateful-pce-auto-bandwidth]
              Dhody, D., Palle, U., Singh, R., Gandhi, R., and L. Fang,
              "PCEP Extensions for MPLS-TE LSP Automatic Bandwidth
              Adjustment with Stateful PCE", draft-dhody-pce-stateful-
              pce-auto-bandwidth-09 (work in progress), November 2016.





Chen, et al.           Expires September 28, 2017              [Page 17]

Internet-Draft               LSP Scheduling                   March 2017


   [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-09 (work in
              progress), March 2017.

   [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-18 (work in progress), December 2016.

   [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-10 (work in
              progress), March 2017.

   [I-D.ietf-teas-scheduled-resources]
              Zhuangyan, Z., Wu, Q., Chen, H., and A. Farrel,
              "Architecture for Scheduled Use of Resources", draft-ietf-
              teas-scheduled-resources-02 (work in progress), January
              2017.

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

9.2.  Informative References

   [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-08 (work in progress), October 2016.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.






Chen, et al.           Expires September 28, 2017              [Page 18]

Internet-Draft               LSP Scheduling                   March 2017


   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "Path Computation Element Communication Protocol
              (PCEP) Management Information Base (MIB) Module",
              RFC 7420, DOI 10.17487/RFC7420, December 2014,
              <http://www.rfc-editor.org/info/rfc7420>.

Appendix A.  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 by using PCReq message, PCRep
   message with scheduled LSP information.  In order to synchronize the
   scheduled LSP information in SLSP-DB among PCEs, the PCReq message
   and PCRep Message is used as described in section 4.3.1 and section
   4.3.2.

   To achieve the synchronization, the PCE should generate and maintain
   a scheduled TED based on LSP DB, scheduled LSP DB and TED, which is
   used to indicate the network resource availability on network nodes
   for LSP path computation.

Appendix B.  Contributor Addresses





















Chen, et al.           Expires September 28, 2017              [Page 19]

Internet-Draft               LSP Scheduling                   March 2017


      Xufeng Liu
      Ericsson
      USA
      Email: xliu@kuatrotech.com

      Mehmet Toy
      Verizon
      USA
      Email: mehmet.toy@verizon.com

      Vic Liu
      China Mobile
      No.32 Xuanwumen West Street, Xicheng District
      Beijing,   100053
      China
      Email: liu.cmri@gmail.com

      Lei Liu
      Fujitsu
      USA
      Email: lliu@us.fujitsu.com

      Khuzema Pithewan
      Infinera
      Email: kpithewan@infinera.com


      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







Chen, et al.           Expires September 28, 2017              [Page 20]

Internet-Draft               LSP Scheduling                   March 2017


   Huaimo Chen  (editor)
   Huawei
   Boston, MA
   USA

   Email: huaimo.chen@huawei.com


   Yan Zhuang (editor)
   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


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

   Email: dhruv.ietf@gmail.com


   Daniele Ceccarelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: daniele.ceccarelli@ericsson.com









Chen, et al.           Expires September 28, 2017              [Page 21]