Skip to main content

PCEP Extensions for LSP scheduling with stateful PCE
draft-ietf-pce-stateful-pce-lsp-scheduling-16

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8934.
Authors Huaimo Chen , Yan Zhuang , Qin Wu , Daniele Ceccarelli
Last updated 2020-06-12
Replaces draft-zhuang-pce-stateful-pce-lsp-scheduling
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Adrian Farrel
Shepherd write-up Show Last changed 2020-03-04
IESG IESG state Became RFC 8934 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Deborah Brungard
Send notices to Adrian Farrel <adrian@olddog.co.uk>
IANA IANA review state IANA - Not OK
draft-ietf-pce-stateful-pce-lsp-scheduling-16
PCE Working Group                                           H. Chen, Ed.
Internet-Draft                                                 Futurewei
Intended status: Standards Track                          Y. Zhuang, Ed.
Expires: December 14, 2020                                         Q. Wu
                                                                  Huawei
                                                           D. Ceccarelli
                                                                Ericsson
                                                           June 12, 2020

          PCEP Extensions for LSP scheduling with stateful PCE
             draft-ietf-pce-stateful-pce-lsp-scheduling-16

Abstract

   This document defines 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 and
   the duration of a traffic service in a centralized network
   environment as stated in RFC 8413.

Status of This Memo

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

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

   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 14, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Chen, et al.            Expires December 14, 2020               [Page 1]
Internet-Draft               LSP Scheduling                    June 2020

   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.  Procedures and Mechanisms . . . . . . . . . . . . . . . . . .   5
     4.1.  LSP Scheduling Overview . . . . . . . . . . . . . . . . .   5
     4.2.  Support of LSP Scheduling . . . . . . . . . . . . . . . .   7
       4.2.1.  LSP Scheduling  . . . . . . . . . . . . . . . . . . .   7
       4.2.2.  Periodical LSP Scheduling . . . . . . . . . . . . . .   7
     4.3.  Scheduled LSP creation  . . . . . . . . . . . . . . . . .   9
     4.4.  Scheduled LSP Modifications . . . . . . . . . . . . . . .  10
     4.5.  Scheduled LSP activation and deletion . . . . . . . . . .  11
   5.  PCEP Objects and TLVs . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Stateful PCE Capability TLV . . . . . . . . . . . . . . .  11
     5.2.  LSP Object  . . . . . . . . . . . . . . . . . . . . . . .  12
       5.2.1.  SCHED-LSP-ATTRIBUTE TLV . . . . . . . . . . . . . . .  12
       5.2.2.  SCHED-PD-LSP-ATTRIBUTE TLV  . . . . . . . . . . . . .  15
   6.  The PCEP Messages . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  The PCRpt Message . . . . . . . . . . . . . . . . . . . .  16
     6.2.  The PCUpd Message . . . . . . . . . . . . . . . . . . . .  16
     6.3.  The PCInitiate Message  . . . . . . . . . . . . . . . . .  17
     6.4.  The PCReq message . . . . . . . . . . . . . . . . . . . .  17
     6.5.  The PCRep Message . . . . . . . . . . . . . . . . . . . .  17
     6.6.  The PCErr Message . . . . . . . . . . . . . . . . . . . .  17
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .  18
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   9.  Manageability Consideration . . . . . . . . . . . . . . . . .  19
     9.1.  Control of Function and Policy  . . . . . . . . . . . . .  19
     9.2.  Information and Data Models . . . . . . . . . . . . . . .  19
     9.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  19
     9.4.  Verify Correct Operations . . . . . . . . . . . . . . . .  20
     9.5.  Requirements On Other Protocols . . . . . . . . . . . . .  20
     9.6.  Impact On Network Operations  . . . . . . . . . . . . . .  20
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     10.1.  PCEP TLV Type Indicators . . . . . . . . . . . . . . . .  20
       10.1.1.  Opt Field in SCHED-PD-LSP-ATTRIBUTE TLV  . . . . . .  20
       10.1.2.  Schedule TLVs Flag Field . . . . . . . . . . . . . .  21
     10.2.  STATEFUL-PCE-CAPABILITY TLV Flag field . . . . . . . . .  21
     10.3.  PCEP-Error Object  . . . . . . . . . . . . . . . . . . .  21
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  22

Chen, et al.            Expires December 14, 2020               [Page 2]
Internet-Draft               LSP Scheduling                    June 2020

   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     12.2.  Informative References . . . . . . . . . . . . . . . . .  23
   Appendix A.  Contributors Addresses . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

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 path computation of Multi-
   protocol Label Switching (MPLS) Traffic Engineering Label Switched
   Paths (TE LSPs).

   [RFC8231] describes a set of extensions to PCEP to provide stateful
   control.  A stateful PCE has access to not only the information
   carried by the network's Interior Gateway Protocol (IGP) but also the
   set of active paths and their reserved resources for its
   computations.  The additional state allows the PCE to compute
   constrained paths while considering individual LSPs and their
   interactions.

   Traditionally, the usage and allocation of network resources,
   especially bandwidth, can be supported by a Network Management System
   (NMS) operation such as path pre-establishment.  However, this does
   not provide efficient usage of network resources.  The established
   paths reserve the resources forever, which can not be used by other
   services even when they are not used for transporting any service.
   [RFC8413] then provides a framework that describes and discusses the
   problem, and defines an appropriate architecture for the scheduled
   reservation of TE resources.

   The scheduled reservation of TE resources allows network operators to
   reserve resources in advance according to the agreements with their
   customers, and allows them to transmit data about scheduling such as
   a specified start 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 use it when this service is not using it.  The
   requirement of scheduled LSP provision is mentioned in [RFC8231] and
   [RFC7399].  A solution for providing more efficient network resource
   usage for traffic engineering is desired.  Also, for deterministic
   networks [I-D.ietf-detnet-architecture], the scheduled LSP or
   temporal LSP can provide a better network resource usage for
   guaranteed links.  This idea can also be applied in segment routing
   [RFC8402] to schedule the network resources over the whole network in
   a centralized manner as well.

Chen, et al.            Expires December 14, 2020               [Page 3]
Internet-Draft               LSP Scheduling                    June 2020

   With this in mind, this document defines a set of extensions needed
   to PCEP used for stateful PCEs 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
   LSPs (scheduled or not).

2.  Conventions used in this document

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

2.1.  Terminology

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

   o  Active Stateful PCE [RFC8231];

   o  Passive Stateful PCE [RFC8231];

   o  Delegation [RFC8231];

   o  PCE-Initiated LSP [RFC8281];

   o  PCC [RFC5440], [RFC8231];

   o  PCE [RFC5440], [RFC8231];

   o  TE LSP [RFC5440], [RFC8231];

   o  TED [RFC5440], [RFC8231];

   o  LSP-DB [RFC8231];

   In addition, this document defines the following terminologies.

   Scheduled TE LSP (or Scheduled LSP for short):  an LSP with the
      scheduling attributes, that carries traffic flow demand at a
      starting time and lasts for a certain duration (or from a starting
      time to an ending time, where the ending time is the starting time
      plus the duration).  A scheduled LSP is also called a temporal
      LSP.  The PCE operates path computation per LSP availability for
      the required time and duration.

Chen, et al.            Expires December 14, 2020               [Page 4]
Internet-Draft               LSP Scheduling                    June 2020

   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:  This 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 torn down and
      removed from the database.

3.  Motivation and Objectives

   A stateful PCE [RFC8231] can support better efficiency by using LSP
   scheduling described in the use case of [RFC8051].  This requires the
   PCE to maintain the scheduled LSPs and their associated resource
   usage, e.g.  bandwidth for Packet-switched network, as well as have
   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 [RFC8231] as well
   as discussions in [RFC8413], doing this as a part of PCEP in a
   centralized manner, has obvious advantages.

   This document provides a set of extensions to PCEP to enable LSP
   scheduling for LSP creation/deletion under the stateful control of a
   PCE and according to traffic service requests from customers, so as
   to improve the usage of network resources.

4.  Procedures and Mechanisms

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

Chen, et al.            Expires December 14, 2020               [Page 5]
Internet-Draft               LSP Scheduling                    June 2020

   PCEP [RFC8231], while the other is the scheduled LSP database (SLSP-
   DB, see section 6).  The SLSP-DB records scheduled LSPs and is used
   in conjunction with 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 is an implementation matter and this
   document does not state any preference.

   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, before a PCC
   delegates a scheduled LSP, it MAY use the PCReq/PCRep messages to
   learn the path for the scheduled LSP.  A PCC MUST delegate a
   scheduled LSP with information of its scheduling parameters,
   including the starting time and the duration using PCRpt message.
   Since the LSP is not yet signaled, at the time of delegation the LSP
   would be in down state.  Upon receiving the delegation of the
   scheduled LSP, 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 and update to the PCC as
   per the active stateful PCE techniques [RFC8231].

   Note that the active stateful PCE can update to the PCC with the path
   for the scheduled LSP at any time.  However, the PCC should not
   signal the LSP over the path on receiving these messages since the
   path is not active yet; PCC signals the LSP at the starting time.

   For a multiple PCE environment, a PCE MUST synchronize to other PCEs
   within the network, so as to keep their scheduling information
   synchronized.  There are many ways that this could be achieved: one
   such mechanism is described in [I-D.litkowski-pce-state-sync].  Which
   way is used to achieve this is out of scope for this document.  The
   scheduled TED can be determined from the synchronized SLSP-DB.  The
   PCE with delegation for the scheduled LSP would report the scheduled
   LSP to other PCEs, any future update to the scheduled LSP is also
   updated to other PCEs.  This way the state of all scheduled LSPs are
   synchronized among the PCEs.  [RFC7399] discusses some
   synchronization issues and considerations, that are also applicable
   to the scheduled databases.

   The scheduled LSP 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 and initiate a scheduled LSP at the PCC
   and synchronize the scheduled LSP to other PCEs.  Note that, the PCC
   could be notified immediately or at the starting time of the

Chen, et al.            Expires December 14, 2020               [Page 6]
Internet-Draft               LSP Scheduling                    June 2020

   scheduled LSP based on the local policy.  For the former SCHED-LSP-
   ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the message
   where as for the latter SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be
   included.  Either way the synchronization to other PCEs should be
   done when the scheduled LSP is created.

   In both modes, for activation of scheduled LSPs, the PCC could
   initiate the setup of scheduled LSP at the start time by itself or
   wait for the PCE to update the PCC to initiate the setup of LSP.
   Similarly on the scheduling usage expires, the PCC could initiate the
   removal by itself or wait for the PCE to request the removal of the
   LSP.  This is based on the Flag set in SCHED-LSP-ATTRIBUTE TLV.

4.2.  Support of LSP Scheduling

4.2.1.  LSP Scheduling

   For a scheduled LSP, a user configures it with an arbitrary
   scheduling duration from 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 means an LSP has multiple time intervals
   and the LSP is set up to carry traffic in 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 every interval represented by the periodical scheduling interval
   is computed once.  And then the LSP along the path is set up to carry
   traffic in each of the scheduling intervals.  If there is no path

Chen, et al.            Expires December 14, 2020               [Page 7]
Internet-Draft               LSP Scheduling                    June 2020

   satisfying the constraints for some of the intervals, the LSP will
   not be set up at all.

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
   is shifted by 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)
   and |X| is the minimum value from 0 to max(P, Q).  That is, [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.  Grace Periods

   Besides the stated time scheduling, a user may want to have some
   grace periods (short for graceful time periods) for each or some of
   the time intervals for the LSP.  Two grace periods may be configured
   for a time interval.  One is the grace 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

Chen, et al.            Expires December 14, 2020               [Page 8]
Internet-Draft               LSP Scheduling                    June 2020

   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 grace 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 grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the
   LSP is up to carry traffic (maybe in best effort).

4.3.  Scheduled LSP creation

   In order to realize PCC-Initiated scheduled LSPs in a centralized
   network environment, a PCC has to separate the setup of an LSP into
   two steps.  The first step is to request/delegate and get an LSP but
   not signal it over the network.  The second step is to signal the
   scheduled LSP over the LSRs (Label Switching Router) at its starting
   time.

   For PCC-Initiated scheduled LSPs, a PCC can delegate the scheduled
   LSP by sending a path computation report (PCRpt) message by including
   its demanded resources with the scheduling information to a stateful
   PCE.  Note the PCC MAY use the PCReq/PCRep with scheduling
   information before delegating.

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

   The stateful PCE will send a PCUpd message with the scheduled path
   information as well as the scheduled resource information for the
   scheduled LSP to the PCC.  The PCE SHOULD add the scheduled LSP into
   its scheduled LSP-DB and update its scheduled TED.

   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, send a PCInitiate message with the path information
   back to the PCC.  Based on the local policy, the PCInitiate message
   could be sent immediately to ask PCC to create a scheduled LSP (as
   per this document) or the PCInitiate message could be sent at the
   start time to the PCC to create a normal LSP (as per [RFC8281]).

   For both PCC-Initiated and PCE-Initiated Scheduled LSPs:

Chen, et al.            Expires December 14, 2020               [Page 9]
Internet-Draft               LSP Scheduling                    June 2020

   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 PCRpt 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 PCUpd message or PCInitiate message for the
      scheduled LSP from PCEs with a found path, the PCC knows that it
      is a scheduled path for the LSP and does not trigger signaling for
      the LSP setup on LSRs immediately.

   o  The stateful PCE can update the Scheduled LSP parameters on any
      network events using the PCUpd message to PCC.  These changes are
      also synchronized to other PCEs.

   o  Based on the configuration (and the C flag in scheduled TLVs),
      when it is time (i.e., at the start time) for the LSP to be set
      up, either the PCC triggers the LSP to be signaled or the
      delegated PCE sends a PCUpd message to the head end LSR providing
      the updated path to be signaled (with A flag set to indicate LSP
      activation).

4.4.  Scheduled LSP Modifications

   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 parameters as well as scheduled
   information included in the SCHED-LSP-ATTRIBUTE TLV (see
   Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2)
   carried in the LSP Object.  The PCE would take the updated resources
   and schedule into considerations and update the new path for the
   scheduled LSP to the PCC as well as synchronize to other PCEs in the
   network.  In case path cannot be set based on new requirements, the
   previous LSP will not be impacted and the same should be conveyed by
   the use of empty ERO in the PCEP messages.

   In PCE-Initiated case, the Stateful PCE would recompute the path
   based on updated parameters as well as scheduled information.  In
   case it has already conveyed to the PCC this information by sending a
   PCInitiate message, it should update the path and other scheduling
   and resource information by sending a PCUpd message.

Chen, et al.            Expires December 14, 2020              [Page 10]
Internet-Draft               LSP Scheduling                    June 2020

4.5.  Scheduled LSP activation and deletion

   In PCC-Initiated case, based on the configuration (and the C flag in
   scheduled TLVs), when it is time (i.e., at the start time) for the
   LSP to be set up, either the PCC triggers the LSP to be signaled or
   the delegated PCE sends a PCUpd message to the head end LSR providing
   the updated path to be signaled (with A flag set to indicate LSP
   activation).  The PCC would report the status of the active LSP as
   per the procedures in [RFC8231] and at this time the LSP MUST be
   considered as part of the LSP-DB.  The A flag MUST be set in the
   scheduled TLVs to indicate that the LSP is active now.  After the
   scheduled duration expires, based on the C flag, the PCC triggers the
   LSP deletion on itself or the delegated PCE sends a PCUpd message to
   the PCC to delete the LSP as per the procedures in [RFC8231].

   In PCE-Initiated case, based on the local policy, if the scheduled
   LSP is already conveyed to the PCC at the time of creation, the
   handling of LSP activation and deletion is handled in the same way as
   PCC-Initiated case as per the setting of C flag.  In other case, the
   PCE would send the PCInitiate message at the start time to the PCC to
   create a normal LSP without the scheduled TLVs and remove the LSP
   after the duration expires as per [RFC8281].

5.  PCEP Objects and TLVs

5.1.  Stateful PCE Capability TLV

   After 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 [RFC8231].  Note
   that the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and
   updated in [RFC8281] and [RFC8232]".  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) [Bit Position - TBD3]:  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.

Chen, et al.            Expires December 14, 2020              [Page 11]
Internet-Draft               LSP Scheduling                    June 2020

   PD (PD-LSP-CAPABLITY - 1 bit): [Bit Position - TBD4]  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.  Setting PD bit requires setting
      B bit as specified in 5.2.2.

5.2.  LSP Object

   The LSP object is defined in [RFC8231].  This document adds 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 PCEP messages.  For periodical
   LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in LSP Object for
   each periodic scheduled LSP carried in the PCEP messages.

   Only one of these TLV SHOULD be present in the LSP object.  In case
   more than one scheduling TLV is found, the first instance is
   processed and others ignored.

5.2.1.  SCHED-LSP-ATTRIBUTE TLV

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

   This TLV MUST NOT be included unless both PCEP peers have set the B
   (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV
   carried in the Open message.

   The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1.

Chen, et al.            Expires December 14, 2020              [Page 12]
Internet-Draft               LSP Scheduling                    June 2020

    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 (TBD1)       |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Flags |R|C|A|               Reserved (0)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Start-Time                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Duration                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                GrB            |             GrA               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Elastic-Lower-Bound      |      Elastic-Upper-Bound      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: SCHED-LSP-ATTRIBUTE TLV

   The type of the TLV is [TBD1] and the TLV has a fixed length of 20
   octets.

   The fields in the format are:

   Flags (8 bits):  Following flags are defined in this document

      R (1 bit):  Set to 1 to indicate the Start-Time is a relative
         time, which is the number of seconds from the current time.  It
         is necessary to synchronize the clocks of the PCEs and PCCs
         when relative time is used.  When the transmission delay from a
         PCE or PCC to another PCE or PCC is too big such as greater
         than 1 second, the scheduling interval represented is not
         accurate if the delay is not considered.  Set to 0 to indicate
         that the 32-bit Start-Time is an absolute time, which is the
         number of seconds since the epoch.  The epoch is 1 January 1970
         at 00:00 UTC.  It wraps around every 2^32 seconds, which is
         roughly 136 years.  The next wraparound will occur in the year
         2106.  After the wraparound, the value of the 32-bit Start-Time
         is the number of seconds from the time of wraparound because
         the Start-Time is always a future time.  Just before the
         wraparound, if the time at which the LSP is to be activated is
         after the wraparound, the time is represented by the number of
         seconds from the time of wraparound in the 32-bit Start-Time.

      C (1 bit):  Set to 1 to indicate the PCC is responsible to setup
         and remove the scheduled LSP based on the Start-Time and
         duration.

Chen, et al.            Expires December 14, 2020              [Page 13]
Internet-Draft               LSP Scheduling                    June 2020

      A (1 bit):  Set to 1 to indicate the scheduled LSP has been
         activated and should be considered as part of LSP-DB (instead
         of Scheduled LSP-DB).

   Reserved (24 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Start-Time (32 bits):  This value in seconds, indicates when the
      scheduled LSP is used to carry traffic and the corresponding LSP
      must be setup and activated.  Value of 0 MUST NOT be used in
      Start-Time.  Note that the transmission delay SHOULD be considered
      when R=1 and the value of Start-Time is small.

   Duration (32 bits):  The value in seconds, 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 duration,
      the LSP is torn down and deleted.  Value of 0 MUST NOT be used in
      Duration since it does not make any sense.

   The Start-Time indicates a time at or before which the scheduled LSP
   must be set up.  The value of the Start-Time represents the number of
   seconds since the epoch when R bit is set to 0.  When R bit is set to
   1, it represents the number of seconds from the current time.

   In addition, it contains an non zero grace-before and grace-after if
   grace periods are configured.  It includes an non zero elastic range
   lower bound and upper bound if there is an elastic range configured.
   A TLV can configure a non-zero grace period or elastic range, but it
   MUST NOT provide both for an LSP.

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

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

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

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

Chen, et al.            Expires December 14, 2020              [Page 14]
Internet-Draft               LSP Scheduling                    June 2020

5.2.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 MUST NOT be included unless 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 Figure 2.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type (TBD2)        |         Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Flags  |R|C|A| Opt   |           NR          |  Reserved (0) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Start-Time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Duration                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Repeat-time-length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                GrB            |             GrA               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Elastic-Lower-Bound      |      Elastic-Upper-Bound      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: SCHED-PD-LSP-ATTRIBUTE TLV

   The type of the TLV is [TBD2] and the TLV has a fixed length of 24
   octets.  The description, format and meaning of the Flags (R, C and A
   bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and
   Elastic-Upper-Bound fields remains same as SCHED-LSP-ATTRIBUTE TLV.

   The following fields are new :

   Opt: (4 bits)  Indicates options to repeat.  A new registry "Opt"
      under SCHED-PD-LSP-ATTRIBUTE is created.  When a PCE receives a
      TLV with a Opt value not defined, it does not compute any path for
      the LSP.

         Options = 1: repeat every day;

         Options = 2: repeat every week;

Chen, et al.            Expires December 14, 2020              [Page 15]
Internet-Draft               LSP Scheduling                    June 2020

         Options = 3: repeat every month;

         Options = 4: repeat every year;

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

   NR: (12 bits)  The number of repeats.  In each of repeats, LSP
      carries traffic.

   Reserved (8 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Repeat-time-length: (32 bits)  The time in seconds between the start-
      time of one repetition and the start-time of the next repetition.

6.  The PCEP Messages

6.1.  The PCRpt Message

   Path Computation State Report (PCRpt) is a PCEP message sent by a PCC
   to a PCE to report the status of one or more LSPs as per [RFC8231].
   Each LSP State Report in a PCRpt message contains the actual LSP's
   path, bandwidth, operational and administrative status, etc.  An LSP
   Status Report carried on a PCRpt message is also used in delegation
   or revocation of control of an LSP to/from a PCE.  In case of
   scheduled LSP, the scheduled TLVs MUST be carried in the LSP object
   and the ERO conveys the intended path for the scheduled LSP.  The
   scheduled LSP MUST be delegated to a PCE.  This message is also used
   to synchronize the scheduled LSPs to other PCE as described in
   [RFC8231]

6.2.  The PCUpd Message

   Path Computation Update Request (PCUpd) is a PCEP message sent by a
   PCE to a PCC to update LSP parameters, on one or more LSPs as per
   [RFC8231].  Each LSP Update Request on a PCUpd message contains all
   LSP parameters that a PCE wishes to be set for a given LSP.  In case
   of scheduled LSP, the scheduled TLVs MUST be carried in the LSP
   object and the ERO conveys the intended path for the scheduled LSP.
   In case no path can be found, an empty ERO is used.  The A bit is
   used in PCUpd message to indicate the activation of the scheduled LSP
   in case the PCE is responsible for the activation (as per the C bit).

Chen, et al.            Expires December 14, 2020              [Page 16]
Internet-Draft               LSP Scheduling                    June 2020

6.3.  The PCInitiate Message

   An LSP Initiate Request (PCInitiate) message is a PCEP message sent
   by a PCE to a PCC to trigger LSP instantiation or deletion as per
   [RFC8281].  In case of scheduled LSP, based on the local policy, PCE
   MAY convey the scheduled LSP to the PCC by including the scheduled
   TLVs in the LSP object.  Or the PCE would initiate the LSP only at
   the start time of the scheduled LSP as per the [RFC8281] without the
   use of scheduled TLVs.

6.4.  The PCReq message

   The Path Computation Request (PCReq) message is a PCEP message sent
   by a PCC to a PCE to request a path computation [RFC5440] and it may
   contain the LSP object [RFC8231] to identify the LSP for which the
   path computation is requested.  In case of scheduled LSP, the
   scheduled TLVs MUST be carried in the LSP object in PCReq message to
   request the path computation based on scheduled TED and LSP-DB.  A
   PCC MAY use PCReq message to obtain the scheduled path before
   delegating the LSP.

6.5.  The PCRep Message

   The Path Computation Reply (PCRep) message is a PCEP message sent by
   a PCE to a PCC in reply to a path computation request [RFC5440] and
   it may contain the LSP object [RFC8231] to identify the LSP for which
   the path is computed.  A PCRep message can contain either a set of
   computed paths if the request can be satisfied, or a negative reply
   if not.  The negative reply may indicate the reason why no path could
   be found.  In case of scheduled LSP, the scheduled TLVs MUST be
   carried in the LSP object in PCRep message to indicate the path
   computation based on scheduled TED and LSP-DB.  A PCC and PCE MAY use
   PCReq and PCRep message to obtain the scheduled path before
   delegating the LSP.

6.6.  The PCErr Message

   The Path Computation Error (PCErr) message is a PCEP message as
   described in [RFC5440] for error reporting.  The current document
   defines new error values for several error types to cover failures
   specific to scheduling and reuse the applicable error types and error
   values of [RFC5440] and [RFC8231] wherever appropriate.

   The PCEP extensions for scheduling MUST NOT be used if one or both
   PCEP speakers have not set the corresponding bits in the STATEFUL-
   PCE-CAPABILITY TLV in their respective OPEN message.  If the PCEP
   speaker supports the extensions of this specification but did not
   advertise this capability, then upon receipt of LSP object with the

Chen, et al.            Expires December 14, 2020              [Page 17]
Internet-Draft               LSP Scheduling                    June 2020

   scheduled TLV, it MUST generate a PCEP Error (PCErr) with Error-
   type=19 (Invalid Operation) and error-value TBD6 (Attempted LSP
   Scheduling if the scheduling capability was not advertised), and it
   SHOULD ignore the TLV.  As per Section 7.1 of [RFC5440], a legacy
   PCEP implementation that does not understand this specification,
   would consider the scheduled TLVs as unknown and ignore them.

   If the PCC decides that the scheduling parameters proposed in the
   PCUpd/PCInitiate message are unacceptable, it MUST report this error
   by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error-
   value="Unacceptable parameters" in the LSP object (with scheduled
   TLVs) in the PCRpt message to the PCE.

   The scheduled TLVs MUST be included in the LSP object for the
   scheduled LSPs, if the TLV is missing, the receiving PCEP speaker
   MUST send a PCErr message with Error-type=6 (Mandatory Object
   missing) and Error-value TBD5 (Scheduled TLV missing).

7.  Implementation Status

   [NOTE TO RFC EDITOR : This whole section and the reference to RFC
   7942 is to be removed before publication as an RFC]

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC7942], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   At the time of posting the -09 version of this document, there are no
   known implementations of this mechanism.  It is believed that two
   vendors/organizations are considering prototype implementations, but
   these plans are too vague to make any further assertions.

Chen, et al.            Expires December 14, 2020              [Page 18]
Internet-Draft               LSP Scheduling                    June 2020

8.  Security Considerations

   This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED-LSP-
   ATTRIBUTE TLV, the security considerations discussed in [RFC5440],
   [RFC8231], and [RFC8281] continue to apply.  In some deployments the
   scheduling information could provide details about the network
   operations that could be deemed as extra sensitive.  Additionally,
   snooping of PCEP messages with such data or using PCEP messages for
   network reconnaissance may give an attacker sensitive information
   about the operations of the network.  A single PCEP message can now
   instruct a PCC to set up and tear down an LSP every second for a
   number of times.  That single message could have a significant effect
   on the network.  Thus, such deployment should employ suitable PCEP
   security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925]
   or [RFC8253].  The procedure based on Transport Layer Security (TLS)
   in [RFC8253] is considered a security enhancement and thus is much
   better suited for the sensitive information.  PCCs may also need to
   apply some form of rate limit to the processing of scheduled LSPs.

9.  Manageability Consideration

9.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.  The suggested default values for starting
   time and duration are one day in seconds from the current time and
   one year in seconds respectively.  One day has 86,400 seconds.  One
   year has 31,536,000 seconds.

   When configuring the parameters about time, a user SHOULD consider
   leap-years and leap-seconds.

9.2.  Information and Data Models

   An implementation SHOULD allow the operator to view the capability
   defined in this document.  To serve this purpose, the PCEP YANG
   module [I-D.ietf-pce-pcep-yang] could be extended.

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

Chen, et al.            Expires December 14, 2020              [Page 19]
Internet-Draft               LSP Scheduling                    June 2020

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

9.5.  Requirements On Other Protocols

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

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

10.  IANA Considerations

10.1.  PCEP TLV Type Indicators

   This document defines the following new PCEP TLVs.  IANA maintains a
   sub-registry "PCEP TLV Type Indicators" in the "Path Computation
   Element Protocol (PCEP) Numbers" registry.  IANA is requested to make
   the following allocations from this sub-registry.

   Value     Meaning                         Reference
    TBD1 SCHED-LSP-ATTRIBUTE                 This document
    TBD2 SCHED-PD-LSP-ATTRIBUTE              This document

10.1.1.  Opt Field in SCHED-PD-LSP-ATTRIBUTE TLV

   IANA is requested to create and maintain a new registry "Opt" under
   SCHED-PD-LSP-ATTRIBUTE (TLV Type: TBD2).  Initial values for the
   registry are given below.  New values are assigned by Standards
   Action [RFC8126].

     Value    Name                              Reference
     -----    ----                              ----------
      0       Reserved
      1       REPEAT-EVERY-DAY                  This document
      2       REPEAT-EVERY-WEEK                 This document
      3       REPEAT-EVERY-MONTH                This document
      4       REPEAT-EVERY-YEAR                 This document
      5       REPEAT-EVERY-REPEAT-TIME-LENGTH   This document
      6-14    Unassigned
      15      Reserved

Chen, et al.            Expires December 14, 2020              [Page 20]
Internet-Draft               LSP Scheduling                    June 2020

10.1.2.  Schedule TLVs Flag Field

   IANA is requested to create a new sub-registry, named "Schedule TLVs
   Flag Field", within the "Path Computation Element Protocol (PCEP)
   Numbers" registry to manage the Flag field in the SCHED-LSP-ATTRIBUTE
   and SCHED-PD-LSP-ATTRIBUTE TLVs.  New values are assigned by
   Standards Action [RFC8126].  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
   0-4    Unassigned
   5      R-bit                                          This document
   6      C-bit                                          This document
   7      A-bit                                          This document

10.2.  STATEFUL-PCE-CAPABILITY TLV Flag field

   This document defines new bits in the Flags field in the STATEFUL-
   PCE-CAPABILITY TLV in the OPEN object.  IANA maintains a sub-registry
   "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "Path Computation
   Element Protocol (PCEP) Numbers" registry.  IANA is requested to make
   the following allocations from this sub-registry.

   The following values are defined in this document:

   Bit    Description                                 Reference
    TBD3   LSP-SCHEDULING-CAPABILITY (B-bit)          This document
    TBD4   PD-LSP-CAPABLITY (PD-bit)                  This document

10.3.  PCEP-Error Object

   IANA is requested to allocate the following new error types to the
   existing error values within the "PCEP-ERROR Object Error Types and
   Values" subregistry of the "Path Computation Element Protocol (PCEP)
   Numbers" registry:

Chen, et al.            Expires December 14, 2020              [Page 21]
Internet-Draft               LSP Scheduling                    June 2020

      Error-Type  Meaning
         6        Mandatory Object missing

                   Error-value
                   TBD5:  Scheduled TLV missing

         19       Invalid Operation

                   Error-value
                   TBD6: Attempted LSP Scheduling if the scheduling
                         capability was not advertised

11.  Acknowledgments

   The authors of this document would also like to thank Rafal Szarecki,
   Adrian Farrel, Cyril Margaria for the review and comments.

12.  References

12.1.  Normative References

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

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

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

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

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

Chen, et al.            Expires December 14, 2020              [Page 22]
Internet-Draft               LSP Scheduling                    June 2020

   [RFC8232]  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", RFC 8232,
              DOI 10.17487/RFC8232, September 2017,
              <https://www.rfc-editor.org/info/rfc8232>.

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

12.2.  Informative References

   [I-D.ietf-detnet-architecture]
              Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", draft-ietf-
              detnet-architecture-13 (work in progress), May 2019.

   [I-D.ietf-pce-pcep-yang]
              Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
              YANG Data Model for Path Computation Element
              Communications Protocol (PCEP)", draft-ietf-pce-pcep-
              yang-13 (work in progress), October 2019.

   [I-D.litkowski-pce-state-sync]
              Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter
              Stateful Path Computation Element (PCE) Communication
              Procedures.", draft-litkowski-pce-state-sync-07 (work in
              progress), January 2020.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC7399]  Farrel, A. and D. King, "Unanswered Questions in the Path
              Computation Element Architecture", RFC 7399,
              DOI 10.17487/RFC7399, October 2014,
              <https://www.rfc-editor.org/info/rfc7399>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

Chen, et al.            Expires December 14, 2020              [Page 23]
Internet-Draft               LSP Scheduling                    June 2020

   [RFC8051]  Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
              Stateful Path Computation Element (PCE)", RFC 8051,
              DOI 10.17487/RFC8051, January 2017,
              <https://www.rfc-editor.org/info/rfc8051>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8413]  Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework
              for Scheduled Use of Resources", RFC 8413,
              DOI 10.17487/RFC8413, July 2018,
              <https://www.rfc-editor.org/info/rfc8413>.

Appendix A.  Contributors Addresses

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

      Email: dhruv.ietf@gmail.com

      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

Chen, et al.            Expires December 14, 2020              [Page 24]
Internet-Draft               LSP Scheduling                    June 2020

      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

   Huaimo Chen  (editor)
   Futurewei
   Boston, MA
   USA

   Email: huaimo.chen@futurewei.com

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

   Email: zhuangyan.zhuang@huawei.com

Chen, et al.            Expires December 14, 2020              [Page 25]
Internet-Draft               LSP Scheduling                    June 2020

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

   Email: bill.wu@huawei.com

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

   Email: daniele.ceccarelli@ericsson.com

Chen, et al.            Expires December 14, 2020              [Page 26]