<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="draft-ietf-pce-stateful-pce-lsp-scheduling-27"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?> number="8934"
     ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
     category="std" consensus="true" xml:lang="en" tocInclude="true"
     symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="LSP Scheduling">PCEP abbrev="PCEP Extensions for LSP scheduling Scheduling">PCE
    Communication Protocol (PCEP) Extensions for Label Switched Path (LSP)
    Scheduling with
    stateful Stateful PCE</title>
    <seriesInfo name="RFC" value="8934"/>
    <author fullname="Huaimo Chen " initials="H." role="editor"
	    surname="Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street/>
          <city>Boston</city>
          <region>MA</region>
          <code/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>huaimo.chen@futurewei.com</email>
      </address>
    </author>
    <author fullname="Yan Zhuang" initials="Y." role="editor"
	    surname="Zhuang">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street> Avenue</street>
          <extaddr>Yuhua District</extaddr>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>zhuangyan.zhuang@huawei.com</email>
      </address>
    </author>
    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street> Avenue</street>
          <extaddr>Yuhua District</extaddr>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>bill.wu@huawei.com</email>
      </address>
    </author>

<!--
    <author fullname="Dhruv Dhody" initials="D." surname="Dhody" role="editor">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>Divyashree Techno Park, Whitefield</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560066</code>

          <country>India</country>
        </postal>

        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>
-->
    <author fullname="Daniele Ceccarelli" initials="D." surname="Ceccarelli">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Via A. Negrone 1/A</street>
          <city>Genova - Sestri Ponente</city>
          <country>Italy</country>
        </postal>
        <email>daniele.ceccarelli@ericsson.com</email>
      </address>
    </author>
    <date year="2020"/> year="2020" month="October" />
    <area>Routing Area</area>
    <workgroup>PCE Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>
    <keyword>Path Computation Element</keyword>
    <abstract>

      <t>This document defines a set of extensions needed to the stateful
      Path Computation Element (PCE) communication
      PCE Communication Protocol (PCEP), so as (PCEP) to
      enable Labeled Label Switched Path (LSP) path computation,
      activation, setup setup, and deletion based on scheduled time intervals for
      the LSP and
      the actual network resource usage
      in a centralized network environment environment, as stated in
      RFC 8413.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Path Computation Element PCE Communication Protocol (PCEP) defined in
      <xref target="RFC5440"/> target="RFC5440" format="default"/> is used between a Path
      Computation Element (PCE) and a Path Computation Client (PCC) (or other
      PCE) to enable path computation of Multi-protocol Multiprotocol Label Switching (MPLS)
      Traffic Engineering Label Switched Paths (TE LSPs).</t>
      <t><xref target="RFC8231"/> target="RFC8231" format="default"/> 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. </t>
      <t>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 so they cannot be used by other services even
      when they are not used
      for transporting any service. <xref target="RFC8413"/> target="RFC8413" format="default"/>
      then
      provides a framework that describes and discusses the problem, problem and
      defines an appropriate architecture for the scheduled reservation of TE
      resources.</t>
      <t>
      The scheduled reservation of TE resources allows network operators to
      reserve resources in advance according to the agreements with their
      customers,
      customers and allows them to transmit data about scheduling scheduling, such as
      a specified start time and duration, for example duration (for example, for a scheduled
      bulk data replication between data centers. centers).

   It enables the activation of
   bandwidth usage at the time the service is really being used while
   letting other services use it the bandwidth when this service it is not using it. being used by this
   service.
      The requirement of
      scheduled LSP provisioning is mentioned in <xref target="RFC8231"/> target="RFC8231"
      format="default"/>
      and <xref target="RFC7399"/>. target="RFC7399" format="default"/>.
      Also, for
      deterministic networks <xref target="I-D.ietf-detnet-architecture"/>, target="RFC8655" format="default"/>,
      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 <xref target="RFC8402"/> target="RFC8402" format="default"/>
      to schedule the network resources over the whole network
      in a centralized manner as well.</t> manner.</t>
      <t>With this in mind, this document defines a set of extensions needed extensions
      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
      start 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).</t>
    </section>
    <section title="Conventions used numbered="true" toc="default">
      <name>Conventions Used in this document"> This Document</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref
      target="RFC2119"></xref> target="RFC2119"/> <xref
      target="RFC8174"></xref> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

      <section title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>The following terminology is re-used reused from existing PCE
        documents.<list style="symbols">
            <t>Active
        documents.</t>
        <ul spacing="normal">
          <li>Active Stateful PCE <xref target="RFC8051"/></t>

            <t>Delegation target="RFC8051"
	  format="default"/></li>
          <li>Delegation <xref target="RFC8051"/></t>

            <t>PCE-Initiated target="RFC8051" format="default"/></li>
          <li>PCE-initiated LSP <xref target="RFC8281"/></t>

            <t>PCC target="RFC8281" format="default"/></li>
          <li>PCC <xref target="RFC5440"/></t>

            <t>PCE target="RFC5440" format="default"/></li>
          <li>PCE <xref target="RFC5440"/></t>

            <t>TE target="RFC5440" format="default"/></li>
          <li>TE LSP <xref target="RFC5440"/></t>

            <t>TED target="RFC5440" format="default"/></li>
          <li>TED (Traffic Engineering Database) <xref target="RFC5440"/></t>

            <t>LSP-DB target="RFC5440"
	  format="default"/></li>
          <li>LSP-DB (LSP State Database) <xref target="RFC8051"/></t>
          </list>In target="RFC8051"
	  format="default"/></li>
        </ul>
        <t>In addition, this document defines the following
        terminologies.<list style="hanging">
            <t hangText="Scheduled
        terminologies.</t>
        <dl newline="false" spacing="normal">
          <dt>Scheduled TE LSP (or Scheduled LSP for short):">
            an short):</dt>
          <dd>
            An LSP with the scheduling
            attributes,
            attributes that carries traffic flow demand at a starting start time and
            lasts for a certain duration (or from a starting start time to an ending end time,
            where the ending end time is the starting start time plus the duration).
            A scheduled LSP is also called a temporal LSP. "temporal LSP".
            The PCE operates path computation per
            LSP availability for the required time and duration.</t>

            <t hangText="Scheduled LSP-DB:">a duration.</dd>
          <dt>Scheduled LSP-DB (SLSP-DB):</dt>
          <dd>A database of scheduled LSPs.</t>

            <t hangText="Scheduled TED:">Traffic LSPs.</dd>
          <dt>Scheduled TED:</dt>
          <dd>Traffic engineering database with the
            awareness of scheduled resources for TE. This database is
            generated by the PCE from the information in the TED and scheduled LSP-DB
            and
	    LSP-DB;
            it allows knowing, at any time,
            the expected amount of available resources (discounting
            the possibility of failures in the future).</t>

            <t hangText="Starting future).</dd>
          <dt>Start time (start-time):">This (Start-Time):</dt>
          <dd>This value indicates when
            the scheduled LSP is used and the corresponding LSP must be setup set up
            and active. In At other time times (i.e., before the starting start time or after
            the starting start time plus Duration), duration), the LSP can be inactive to
            include the possibility of the resources being used by other
            services.</t>

            <t hangText="Duration:">This
            services.</dd>
          <dt>Duration:</dt>

          <dd>This value indicates the length of time that
            the LSP is undertaken by carries a traffic flow and the corresponding LSP
            must be setup set up and active. At the end of which, the duration, the LSP is
	    torn down
            and removed from the database.</t>
          </list></t> database.</dd>
        </dl>
      </section>
    </section>
    <section title="Motivation numbered="true" toc="default">
      <name>Motivation and Objectives"> Objectives</name>
      <t>A stateful PCE <xref target="RFC8231"/> target="RFC8231" format="default"/> can support
      better efficiency
      by using LSP scheduling
      described in the use case of <xref target="RFC8051"/>. target="RFC8051" format="default"/>.
      This requires the PCE to
      maintain the scheduled LSPs and their associated resource usage, e.g. usage (e.g.,
      bandwidth for Packet-switched network, packet-switched network) as well as have the ability to
      trigger signaling for the LSP setup/tear-down at the correct time.</t>
      <t>Note that existing configuration tools can be used for LSP
      scheduling, but as highlighted in section 3.1.3 of <xref target="RFC8231"/>
      target="RFC8231" sectionFormat="of" section="3.1.3"/>
      as well as discussions in
      <xref target="RFC8413"/>, target="RFC8413" format="default"/>, doing this as a part of PCEP
      in a
      centralized manner, manner has obvious advantages.</t>
      <t>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.</t>
    </section>
    <section title="Procedures and Mechanisms">
      <section title="LSP numbered="true" toc="default">
      <name>Procedures and Mechanisms</name>
      <section anchor="LSPSchedulingOverview" numbered="true" toc="default">
        <name>LSP Scheduling Overview" anchor="LSPSchedulingOverview">
        <t>The LSP Overview</name>
        <t>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 utilization efficiency.</t>

        <t>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
        <xref target="RFC8231"/>, target="RFC8231" format="default"/>, while the other is the
	scheduled LSP database (SLSP-DB, see
        section 6). (SLSP-DB). 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 matter, and this document does
	not state any preference.</t>
        <t>Furthermore, a scheduled TED can be generated from the scheduled
        LSP-DB, LSP-DB LSP-DB, and TED to indicate the network links and nodes with
        resource availability information for now and the future. The
	scheduled
        TED MUST <bcp14>MUST</bcp14> be maintained by all PCEs within the network
        environment.</t>

        <!--<t>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
        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 compute a path for the LSP with the
        scheduling information.</t>-->

        <t>In the case of implementing PCC-initiated scheduled LSPs, when
        delegating a scheduled LSP, a PCC MUST <bcp14>MUST</bcp14> include its that
        LSP's scheduling parameters (see <xref target="SCHED-LSP-ATTRIBUTE"/>), target="SCHED-LSP-ATTRIBUTE"
        format="default"/>), including the starting start time and the duration duration, using PCRpt a
        Path Computation State Report (PCRpt) message.  Since the LSP is not
        yet signaled, at the time of delegation delegation, the LSP would be in down
        state.  Upon receiving the delegation of the scheduled LSP, a stateful
        PCE MUST <bcp14>MUST</bcp14> check whether the parameters are valid. If
        they are valid, it SHALL <bcp14>SHALL</bcp14> check the scheduled TED for
        the network resource availability on network nodes and nodes, compute a path for
        the LSP with the scheduling information information, and update to the PCC as per
        the active stateful PCE techniques <xref target="RFC8231"/>.</t> target="RFC8231"
        format="default"/>.</t>
        <t>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 after receiving these messages since the
        path is not active yet; the PCC signals the LSP at the starting start time.</t>

        <!--<t>For a multiple PCE environment, in order to coordinate

        <t>In the
        scheduling request case of the LSP path over the network, multiple PCEs within a single domain, the PCE needs to
        send a request message 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.</t>-->

        <!--<t>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.
   Which way is used to achieve this is out of scope for this document.

          In one way, the scheduled TED is determined from the SLSP-DB.
          The PCE with delegation for the scheduled LSP reports 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. <xref target="RFC7399"/> discusses some synchronization issues and considerations,
          that are also applicable to the scheduled databases. </t>-->

        <!--<t>For a scheduled LSP
          crossing multiple domains from an ingress domain to an egress domain.
          There is a PCE responsible for each of these domains.
          The PCE for the ingress domain is called ingress PCE.
          The PCE for the egress domain is called egress PCE.
          The state of the LSP MUST be synchronized among these PCEs.

          After a path for the LSP is computed, a PCRpt message with the
          scheduled LSP information MUST be sent to every PCE along the path
          from the ingress PCE to the egress PCE.
          After receiving the PCRpt message,
          the PCE MUST update its SLSP-DB according to the scheduled LSP information.

          The ingress PCE acting as a PCC sends its next hop PCE the PCRpt message.
          After receiving the PCRpt message, the next hop PCE acting as a PCC sends
          its next hop PCE the PCRpt message. This continues until the egress
          PCE receives the PCRpt message.</t> -->

        <t>In case of multiple PCEs within a single domain, the PCE would need would
        need to synchronize their scheduling information with other PCEs
        within the domain.

This could be achieved by proprietary database
   synchronization database-synchronization techniques or
via a possible PCEP extension
   [I-D.litkowski-pce-state-sync]. (see <xref
target="I-D.litkowski-pce-state-sync"/>). The technique used to synchronize an
SLSP-DB is out of scope for this document.  When the scheduling information is
out of synchronization among some PCEs, some of scheduled LSPs may not be set up
successfully. </t>
        <t>The scheduled LSP can also be initiated by a PCE itself.  In the
        case of implementing a PCE-initiated scheduled LSP, the stateful PCE
        SHALL
        <bcp14>SHALL</bcp14> check the network resource availability for the traffic and
        traffic, compute a path for the scheduled LSP LSP, and initiate a
        scheduled LSP at the PCC and synchronize the scheduled LSP to other
        PCEs. Note that, that the PCC could be notified immediately or at the
        starting start
        time of the scheduled LSP LSP, based on the local policy.  In the former
        case, the SCHED-LSP-ATTRIBUTE TLV (see <xref target="SCHED-LSP-ATTRIBUTE"/>)
        MUST
        target="SCHED-LSP-ATTRIBUTE" format="default"/>) <bcp14>MUST</bcp14>
        be included in the message whereas, message, whereas for the latter latter, the
        SCHED-LSP-ATTRIBUTE TLV SHOULD NOT <bcp14>SHOULD NOT</bcp14> be included.  Either way
        way, the synchronization to other PCEs MUST <bcp14>MUST</bcp14> be done
        when the scheduled LSP is created.</t>
        <t>In both modes, for activation of scheduled LSPs, the PCC MUST
	<bcp14>MUST</bcp14>
          initiate the setup of the scheduled LSP at the start time.
          Similarly
          Similarly, on the scheduled usage expiry, the PCC MUST
	  <bcp14>MUST</bcp14>
	    initiate the removal of the LSP
          based on the Flag flag set in the SCHED-LSP-ATTRIBUTE TLV.</t>

          <!--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 <xref target="RFC8281"/>.
        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.</t>-->
	</section>
      <section title="Support numbered="true" toc="default">
        <name>Support of LSP Scheduling"> Scheduling</name>
        <section title="LSP Scheduling"> numbered="true" toc="default">
          <name>LSP Scheduling</name>
          <t>For a scheduled LSP, a user configures it with an arbitrary
          scheduling duration period from time Ta to time Tb, which may be
          represented as [Ta, Tb].</t>
          <t>When an LSP is configured with arbitrary scheduling duration period [Ta,
          Tb], a path satisfying the constraints for the LSP in the scheduling
          duration
          period is computed computed, and the LSP along the path is set up to carry
          traffic from time Ta to time Tb.</t>
        </section>
        <section title="Periodical numbered="true" toc="default">
          <name>Periodical LSP Scheduling"> Scheduling</name>
          <t>In addition to LSP Scheduling scheduling at an arbitrary time period, there
          are
          is also periodical LSP Scheduling.</t>

          <t>A periodical scheduling.</t>
          <t>Periodical LSP Scheduling 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 period 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:
          interval "[Ta, Tb] repeats n times with repeat cycle C" represents
          n+1 scheduling intervals as follows:<figure>
              <artwork>[Ta, follows:</t>

          <t indent="3">
[Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC]</artwork>
            </figure></t> Tb+nC]</t>

          <t>When an LSP is configured with a scheduling interval such as
          "[Ta, Tb] repeats 10 times with a repeat cycle of 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.  Note that the path
          computed for one recurrence may be different from the path for
          another recurrence.  And then the LSP along the path is set up to
          carry traffic in each of the scheduling intervals. If there is no
          path satisfying the constraints for some of the intervals, the LSP MUST NOT
          <bcp14>MUST NOT</bcp14> be set up at all.

          It MUST <bcp14>MUST</bcp14> generate a PCEP Error (PCErr) with
          Error-type
          Error-Type = 29 (Path computation failure) and
          Error-value = TBD7 (Path 5 (Constraints could not be found met for some intervals).
          </t>
          <section title="Elastic numbered="true" toc="default">
            <name>Elastic Time LSP Scheduling"> Scheduling</name>
            <t>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 are amounts of time
            such as 300 seconds. P is called the elastic range lower bound bound,
	    and Q
            is called the elastic range upper bound.</t>
            <t>For a simple time interval such as [Ta, Tb] with an elastic
            range, elastic time interval: interval "[Ta, Tb] within -P and Q" means a
            time period from (Ta+X) to (Tb+X), where -P &lt;= X &lt;= Q. Note
            that both Ta and Tb are shifted by the same 'X'. X.

            This elastic time interval is suitable for the case where
            a user wants to have a scheduled LSP up to carry the traffic
            in time interval [Ta, Tb] and has some flexibility on shifting
            the time interval a little bit bit, such as up to P seconds
	    earlier/left or
            some time such as up to Q seconds later/right.</t>
            <t>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+Xv) to
            (Tb+Xv)
            (Tb+Xv), and an optimization is performed on Xv from -P to Q.
            The optimization makes
            [Ta+Xv, Tb+Xv] to be 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+Xv) to
	    (Tb+Xv).</t>
            <t>Similarly, for a recurrent time interval with an elastic range,
            elastic time interval: interval "[Ta, Tb] repeats n times with repeat cycle
            C within -P and Q" represents n+1 simple elastic time intervals as
            follows:<figure>
                <artwork>[Ta+X0,
            follows:</t> <t indent="3"> [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1],
            ..., [Ta+nC+Xn, Tb+nC+Xn] Tb+nC+Xn], where -P &lt;= Xi &lt;= Q, i = 0, 1, 2,
            ..., n. </artwork>
              </figure></t> n.</t>
            <t>If a user wants to keep the same repeat cycle between any two
            adjacent time intervals, elastic time interval: 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:<figure>
                <artwork>[Ta+X, follows:</t> <t
            indent="3"> [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X]
            Tb+nC+X], where -P &lt;= X &lt;= Q. </artwork>
              </figure></t> Q.</t>
          </section>
          <section title="Grace Periods"> numbered="true" toc="default">
            <name>Grace Periods</name>

            <t>Besides the stated time scheduling, a user may want to have
            some grace periods (short for graceful "graceful time periods) 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, "Grace-Before", which extends the lifetime
            of the LSP for
            grace-before by an amount of time (such as 30 seconds)
            before the time interval. The other grace period is the one after the
            time interval, interval and is called grace-after,
            which "Grace-After"; it extends the lifetime
            of the LSP for grace-after by an amount of time (such as 60 seconds)
            after the time interval.  Note that no network resources such as
            link bandwidth will be reserved for the LSP during the grace
            periods.</t>
            <t>When an LSP is configured with a simple time interval such as
            [Ta, Tb] with grace periods such as grace-before GB Grace-Before GrB and
            grace-after GA,
            Grace-After GrA, 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) (Ta-GrB) to (Tb+GA). (Tb+GrA).

During grace periods from (Ta-GB) (Ta-GrB) to Ta and from Tb to (Tb+GA), (Tb+GrA), the LSP is
up to carry traffic in best effort.</t>
          </section>
        </section>
      </section>
      <section title="Scheduled numbered="true" toc="default">
        <name>Scheduled LSP creation"> Creation</name>
        <t>In order to realize PCC-Initiated PCC-initiated scheduled LSPs in a centralized
        network environment, a PCC MUST <bcp14>MUST</bcp14> 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 Label Switching Router) Routers (LSRs) at its starting start time.</t>
        <t>For PCC-Initiated PCC-initiated scheduled LSPs, a PCC MUST <bcp14>MUST</bcp14>
	delegate the scheduled LSP
        by sending a path computation
        report (PCRpt) PCRpt
        message by including its demanded
        resources with the scheduling information to a stateful
        PCE. Note that the PCC MAY <bcp14>MAY</bcp14> use the PCReq/PCRep Path Computation
	Request (PCReq) and Path Computation Reply (PCRep) messages with
	scheduling information before delegating.</t>
        <t>Upon receiving the delegation via PCRpt message, the stateful PCE
        MUST
        <bcp14>MUST</bcp14> compute a path for the scheduled LSP per its starting start
	time and
        duration based on the network resource availability stored in the
        scheduled TED (see <xref target="LSPSchedulingOverview"/>).</t>

        <!--<t>If a resultant path is found, the stateful PCE will send a PCRpt
        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.</t>

        <t>Once other PCEs receive the PCRpt message with the scheduled LSP,
        if not conflicts with their scheduled LSP-DBs, they will 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 with the path information back to the PCC as
        confirmation.</t>-->

        <!-- target="LSPSchedulingOverview"
	format="default"/>).</t>
        <t>The stateful PCE will send a PCUpd Path Computation Update Request
	(PCUpd)
        message with the scheduled path information as well as the scheduled resource
        information for the scheduled LSP to the PCC.
        The PCE MUST add the scheduled LSP into its
        scheduled LSP-DB and update its scheduled TED.</t> -->

        <t>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 stateful PCE MUST <bcp14>MUST</bcp14> update its local scheduled LSP-DB
      and
      scheduled TED with the scheduled LSP and would need to synchronize the
      scheduling information with other PCEs in the domain.  </t>
        <t>For PCE-Initiated Scheduled a PCE-initiated scheduled LSP, the stateful PCE MUST
        <bcp14>MUST</bcp14> automatically compute a path for the scheduled LSP
        per requests from network management
        systems automatically systems, based on the network
        resource availability in the scheduled TED TED, and send a PCInitiate an LSP Initiate
        Request (PCInitiate) message with the path information back to the
        PCC. Based on the local policy, the PCInitiate message could be sent
        immediately to ask the PCC to create a scheduled LSP (as per this document)
        document), or the PCInitiate message could be sent at the start time
        to the PCC to create a normal LSP (as per <xref target="RFC8281"/>). target="RFC8281"
        format="default"/>).
        </t>
        <t>For both PCC-Initiated PCC-initiated and PCE-Initiated PCE-initiated Scheduled LSPs:<list style="symbols">
            <t>The LSPs:</t>
        <ul spacing="normal">
          <li>The stateful PCE MUST <bcp14>MUST</bcp14> update its local scheduled
	  LSP-DB
            and scheduled TED with the scheduled LSP.</t>

            <t>Upon LSP.</li>
          <li>Upon receiving the PCUpd message or PCInitiate message for the
	  scheduled
            LSP from PCEs with a found path, the PCC determines that it is a
            scheduled path for the LSP by the
            SCHED-LSP-ATTRIBUTE TLV (see <xref target="SCHED-LSP-ATTRIBUTE"/>) target="SCHED-LSP-ATTRIBUTE"
	    format="default"/>) or
            SCHED-PD-LSP-ATTRIBUTE TLV (see <xref target="SCHED-PD-LSP-ATTRIBUTE"/>)
	    target="SCHED-PD-LSP-ATTRIBUTE" format="default"/>)
            in the message, message and
            does not trigger signaling for the LSP
            setup on LSRs immediately.</t>

            <t>The immediately.</li>
          <li>The stateful PCE MUST <bcp14>MUST</bcp14> update the Scheduled scheduled LSP
            parameters on any network events using the PCUpd message to the
	    PCC. These
            changes are also synchronized to other PCEs.</t>

            <t>When PCEs.</li>
          <li>When it is time for the LSP to be set up
            (i.e., at the start time), based on the value of the C flag for
	    the
            scheduled TLV,
            either the PCC MUST <bcp14>MUST</bcp14> trigger the LSP to be signaled
	    or the delegated
            PCE MUST <bcp14>MUST</bcp14> send a PCUpd message to the head
            end head-end LSR
	        providing the updated path to be signaled
            (with the A flag set to indicate LSP activation).</t>
          </list></t> activation).</li>
        </ul>
      </section>
      <section title="Scheduled anchor="lsp-modify" numbered="true" toc="default">
        <name>Scheduled LSP Modifications" anchor="lsp-modify"> Modifications</name>
        <t>After a scheduled LSP is configured, a user may change its
        parameters
        parameters, including the requested time as well as and the bandwidth.
        For a periodic scheduled periodic-scheduled LSP, its unused recurrences can be modified
        or cancelled. canceled.
        For a scheduled LSP that is currently active, its duration (the
	lifetime)
        can be reduced.</t>
        <t>In the PCC-Initiated PCC-initiated case, the PCC MUST <bcp14>MUST</bcp14> send the PCE
        a PCRpt message for the scheduled LSP with updated parameters parameters, as well
        as scheduled information included in the SCHED-LSP-ATTRIBUTE TLV (see
        <xref target="SCHED-LSP-ATTRIBUTE"/>) target="SCHED-LSP-ATTRIBUTE" format="default"/>) or
        SCHED-PD-LSP-ATTRIBUTE TLV (see <xref target="SCHED-PD-LSP-ATTRIBUTE"/>) target="SCHED-PD-LSP-ATTRIBUTE"
        format="default"/>) carried in the LSP Object. object.  The PCE SHOULD
        <bcp14>SHOULD</bcp14> take the updated resources and schedule into considerations
        consideration, and update the new path for the scheduled LSP to the PCC as well as
        PCC, and synchronize to other PCEs in the network. In case

If the path cannot be set based on new requirements, the previous LSP will not
be impacted impacted, and the same MUST this <bcp14>MUST</bcp14> be conveyed by the use of an empty ERO
Explicit Route Object (ERO) in the PCEP messages.</t>
        <t>In the PCE-Initiated PCE-initiated case, the Stateful stateful PCE would recompute the
	path based on
         updated parameters as well as and scheduled information. In case If it has
         already conveyed this information to the PCC this information by sending a PCInitiate
         message, it SHOULD <bcp14>SHOULD</bcp14> update the path and other
	 scheduling and resource
         information by sending a PCUpd message.</t>

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

   In the 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 via PCRpt message and the requested PCC via PCUpd message at any
   time based on any network events including SCHED-LSP-ATTRIBUTE TLV or
   SCHED-PD-LSP-ATTRIBUTE TLV in the LSP Object body.-->
      </section>
      <section title="Scheduled numbered="true" toc="default">
        <name>Scheduled LSP activation Activation and deletion"> Deletion</name>
        <t>In the PCC-Initiated PCC-initiated case, when it is time for the LSP to be set up
        (i.e., at the start time), based on the value of the C flag for the
        scheduled TLV, either the PCC MUST <bcp14>MUST</bcp14> trigger the LSP to
        be signaled signaled, or the delegated PCE
            MUST <bcp14>MUST</bcp14> send a PCUpd
        message to the head
            end head-end LSR providing the updated path to be signaled
        (with the A flag set to indicate LSP activation).  The PCC MUST
        <bcp14>MUST</bcp14> report the status of the active LSP as per the
        procedures in <xref target="RFC8231"/> target="RFC8231" format="default"/>, and at this time
        time, the LSP
            MUST <bcp14>MUST</bcp14> be considered as part of the LSP-DB.
        The A flag MUST <bcp14>MUST</bcp14> be set in the scheduled TLV to indicate
        that the LSP is active now. After the scheduled duration expires,
        based on the C flag, the PCC MUST <bcp14>MUST</bcp14> trigger the LSP
        deletion on itself itself, or the delegated PCE MUST <bcp14>MUST</bcp14> send a
        PCUpd message to the PCC to delete the LSP as per the procedures in
        <xref target="RFC8231"/>. target="RFC8231" format="default"/>.
        </t>
        <t>In the PCE-Initiated 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. Otherwise, the PCE MUST send the PCInitiate message
             at the start time to the PCC to create a normal LSP without the scheduled TLV
             and remove the LSP after the duration expires as per <xref target="RFC8281"/>.</t>
<!--
            <t>Additionally, the scheduled databases SHALL be updated and synchronization to other PCEs MUST be done
	     PCC-initiated case,
             as per <xref target="I-D.litkowski-pce-state-sync"/>.</t>
-->
        <!--<t>In PCC-Initiated LSP scheduling, the PCC itself MAY activate the
        scheduled LSP at the starting time. Alternatively, in PCE-Initiated
        case, the stateful PCE MAY activate the scheduled LSP at its scheduled
        time by sending a PCInitiated message. </t>

        <t>After the scheduled duration expires, setting of the C flag. Otherwise, the PCE shall
	          <bcp14>MUST</bcp14> send a PCUpd the PCInitiate message with R flag set
             to the PCC to delete the LSP over at the path, as
        well as to other PCEs start time to remove the scheduled create a normal LSP in without the databases.
        Additionally, it shall update its
	     scheduled LSP-DB TLV
             and scheduled
        TED.</t>

        <t>Note that, the stateful PCE can update remove the Scheduled LSP parameters
        at any time based on any network events using the PCUpd message
        including SCHED-LSP-ATTRIBUTE TLV in after the LSP Object body.</t>--> duration expires, as per <xref
	          target="RFC8281" format="default"/>.</t>
      </section>
    </section>

    <section title="PCEP numbered="true" toc="default">
      <name>PCEP Objects and TLVs"> TLVs</name>
      <section title="Stateful numbered="true" toc="default">
        <name>Stateful PCE Capability TLV"> TLV</name>
        <t>A PCC and a PCE indicate their ability to support LSP scheduling
        during their PCEP session establishment phase. For a multiple-PCE
          environment, an environment with
        multiple PCEs, the PCEs SHOULD <bcp14>SHOULD</bcp14> also establish a PCEP
        session and indicate its ability to support LSP scheduling among PCEP
        peers. The
          Open Object OPEN object in the Open message contains the
        STATEFUL-PCE-CAPABILITY TLV. Note that the STATEFUL-PCE-CAPABILITY TLV
        is defined in <xref target="RFC8231"/> target="RFC8231" format="default"/> and updated in
        <xref target="RFC8281"/> target="RFC8281" format="default"/> and <xref target="RFC8232"/>". target="RFC8232"
        format="default"/>.  In this document, we define a new flag bit B (SCHED-LSP-CAPABLITY)
        (LSP-SCHEDULING-CAPABILITY) in the Flags field of the
        STATEFUL-PCE-CAPABILITY TLV to indicate the support of LSP scheduling and
        scheduling. We also define another flag bit PD (PD-LSP-CAPABLITY) (PD-LSP-CAPABILITY) to
        indicate the support of LSP periodical scheduling.</t>

          <t><list style="hanging">
              <t hangText="B
        <dl newline="false" spacing="normal">

          <dt>B (LSP-SCHEDULING-CAPABILITY) - 1 bit [Bit (Bit Position - TBD3]:">If 22):</dt>
          <dd>If set to 1
              by a PCC, the B Flag flag indicates that the PCC allows LSP
              scheduling; if set to 1 by a PCE, the B Flag flag indicates that the
              PCE is capable of LSP scheduling. The B bit MUST <bcp14>MUST</bcp14>
	      be set by both
              PCEP peers in order to support LSP scheduling for path
              computation.</t>

              <t hangText="PD (PD-LSP-CAPABLITY)
              computation.</dd>

          <dt>PD (PD-LSP-CAPABILITY) - 1 bit: [Bit bit (Bit Position - TBD4]"> 21):</dt>
          <dd>
              If set to 1 by a
              PCC, the PD Flag flag indicates that the PCC allows LSP scheduling
              periodically; if set to 1 by a PCE, the PD Flag flag indicates that
              the PCE is capable of periodical LSP scheduling. Both the PD bit
	      and
              the B bit
              MUST
              <bcp14>MUST</bcp14>
              be set to 1 by both PCEP peers in order to support periodical
	      LSP
              scheduling for path computation.

              If the PD bit or B bit is 0, then
              the periodical LSP scheduling capability MUST <bcp14>MUST</bcp14> be ignored.</t>
            </list></t>
	  ignored.</dd>
        </dl>
      </section>
      <section title="LSP Object"> numbered="true" toc="default">
        <name>LSP Object</name>
        <t>The LSP object is defined in <xref target="RFC8231"/>. target="RFC8231"
	format="default"/>.
          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 LSP Object object for a scheduled LSP MUST NOT <bcp14>MUST
	  NOT</bcp14> include
          these two TLVs. Only one scheduling, either normal or periodical,
          is allowed for a scheduled LSP. </t>
        <t>The presence of the SCHED-LSP-ATTRIBUTE TLV in the LSP object
          indicates that this LSP is normal scheduling while the
          SCHED-PD-LSP-ATTRIBUTE TLV indicates that this scheduled LSP is
          periodical. The SCHED-LSP-ATTRIBUTE TLV MUST <bcp14>MUST</bcp14> be
	    present in the LSP
          Object object for each normal scheduled normal-scheduled LSP carried in
	      the PCEP messages. The
          SCHED-PD-LSP-ATTRIBUTE TLV MUST <bcp14>MUST</bcp14> be used in the LSP Object
	  object for each periodic
          scheduled periodic-scheduled LSP carried in the PCEP
	  messages.</t>
        <t>Only one SCHED-LSP-ATTRIBUTE TLV SHOULD <bcp14>SHOULD</bcp14> be present
	in the LSP object.
             In case
             If more than one SCHED-LSP-ATTRIBUTE TLV is found,
             the first instance is processed and others ignored.

             The SCHED-PD-LSP-ATTRIBUTE TLV is the same as the
             SCHED-LSP-ATTRIBUTE TLV regarding with regard to its presence in the LSP
	object.</t>
        <section title="SCHED-LSP-ATTRIBUTE TLV" anchor="SCHED-LSP-ATTRIBUTE"> anchor="SCHED-LSP-ATTRIBUTE" numbered="true" toc="default">
          <name>SCHED-LSP-ATTRIBUTE TLV</name>
          <t>The SCHED-LSP-ATTRIBUTE TLV MAY <bcp14>MAY</bcp14> be included as an
	  optional TLV
            within the LSP object for LSP scheduling for the requesting
            traffic service.</t>
          <t>This TLV MUST NOT <bcp14>MUST NOT</bcp14> be included unless both PCEP
	  peers have set the B
            (LSP-SCHEDULING-CAPABILITY) bit in the STATEFUL-PCE-CAPABILITY TLV
            carried in the Open message to one.
            If the TLV is received by a peer when both peers
            didn't set the B bit to one, the peer MUST <bcp14>MUST</bcp14> generate
            a PCEP Error (PCErr) with a PCEP-ERROR object
            having Error-type Error-Type = 19 (Invalid Operation) and
            Error-value = TBD6 15 (Attempted LSP Scheduling if scheduling while the scheduling
            capability was not advertised).</t>
          <t>The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1.</t> <xref
	    target="sched-lsp-attr-tlv"/>.</t>

          <figure anchor="sched-lsp-attr-tlv"
                 title="SCHED-LSP-ATTRIBUTE TLV">
              <artwork> anchor="sched-lsp-attr-tlv">
            <name>SCHED-LSP-ATTRIBUTE TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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) (49)         |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |R|C|A|G|               Reserved (0)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Start-Time                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Duration                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   GrB / Elastic-Lower-Bound   |   GrA / Elastic-Upper-Bound   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
]]></artwork>
          </figure>

          <t>The type of the TLV is [TBD1] 49, and the TLV has a fixed length of
            16 octets.</t>
          <t>The fields in the format are:<list style="hanging">
                <t hangText="Flags are:</t>
          <dl newline="false" spacing="normal">
            <dt>Flags (8 bits):">The bits):</dt>
            <dd>
              <t>The following flags are defined in this document
                  <list style="hanging">
                <t hangText="R document.
              </t>
              <dl newline="false" spacing="normal">
                <dt>R (1 bit):"> bit):</dt>
                <dd>
                  <t>
                Set to 1 to indicate that the Start-Time is a relative time,
		which is the number of seconds from the
                current time.
                The PCEs and PCCs MUST synchronized <bcp14>MUST</bcp14> synchronize their clocks
                when relative time is used.
                It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the Network Time
		Protocol
                <xref target="RFC5905"/> target="RFC5905" format="default"/>
                be used to synchronize clocks among them.
                When the transmission delay from a PCE or PCC to another PCE
		or PCC
                is too big such (such as greater than 1 second, 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.
         The received Start-Time is considered after the
         wraparound if the resulting value is less than the current time.
         In which that case, the value of the 32-bit Start-Time is considered
         as the number of seconds from the time of wraparound (because
         the Start-Time is always a future time).

<!--
                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.
                Before the wraparound and
                within a constant RANGE-START-TIME to reach 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.
                RANGE-START-TIME = 2*365*86400 seconds (about 2 years).
-->
<!--
                If the value of the Start-Time is greater than a constant
                MAX-AWAY-TIME to reach the time of the next wraparound and
                within of the range 32-bit Start-Time is considered
         to be the number of start time limit RANGE-START-TIME,
                it represents seconds from the time before of wraparound (because
         the wraparound,
                where MAX-AWAY-TIME = 100 seconds,
                RANGE-START-TIME = 2*365*86400 seconds.
-->
                <vspace blankLines="1"/></t>

                <t hangText="C Start-Time is always a future time).
                  </t>
                  <t/>
                </dd>
                <dt>C (1 bit):">Set bit):</dt>
                <dd>
                  <t>Set to 1 to indicate that the
                PCC is responsible to setup set up and remove the scheduled LSP
		based on the
                Start-Time and duration. Duration.
                The PCE holds these responsibilities when the bit is set to
		zero.
                <vspace blankLines="1"/></t>

                <t hangText="A
                  </t>
                  <t/>
                </dd>
                <dt>A (1 bit):">Set bit):</dt>
                <dd>

                  <t>Set to 1 to indicate that the
                scheduled LSP has been activated and should be considered
                as part of LSP-DB (instead of Scheduled LSP-DB). <vspace blankLines="1"/></t>

                <t hangText="G activated. </t>
                  <t/>
                </dd>
                <dt>G (1 bit):">Set bit):</dt>
                <dd>
                  <t>Set to 1 to indicate that the
                Grace
                grace period is included in the fields
                GrB/Elastic-Lower-Bound and GrA/Elastic-Upper-Bound;
                set to 0 to indicate that the elastic range is included in the
		fields.
                <vspace blankLines="1"/></t>

              </list></t>

                <t hangText="Reserved
                  </t>
                  <t/>
                </dd>
              </dl>
            </dd>
            <dt>Reserved (24 bits):">This bits):</dt>
            <dd>
              <t>This field MUST <bcp14>MUST</bcp14> be set to
                zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on
		receipt. <vspace
                blankLines="1"/></t>

                <t hangText="Start-Time </t>
              <t/>
            </dd>
            <dt>Start-Time (32 bits):">This value bits):</dt>
            <dd>
              <t>This value, in seconds,
                indicates when the scheduled LSP is used to carry traffic and
                the corresponding LSP MUST <bcp14>MUST</bcp14> be setup set up and
		activated.

                Note that the transmission delay SHOULD <bcp14>SHOULD</bcp14> be
		considered when R=1
                and the value of Start-Time is small.
                <vspace blankLines="1"/></t>

                <t hangText="Duration
              </t>
              <t/>
            </dd>
            <dt>Duration (32 bits):">The value bits):</dt>
            <dd>

              <t>This value, in seconds, indicates the duration that the LSP is undertaken by
              carries a traffic flow and the corresponding LSP MUST
              <bcp14>MUST</bcp14> be up to carry traffic. At the expiry of
              this duration, the LSP MUST <bcp14>MUST</bcp14> be torn down and
              deleted.
                Value  A value of 0 MUST NOT <bcp14>MUST NOT</bcp14> be used in Duration
              since it does not make any sense.  The value of Duration SHOULD
              <bcp14>SHOULD</bcp14> be greater than a constant
              MINIMUM-DURATION seconds, where MINIMUM-DURATION is 5.
                <vspace blankLines="1"/></t>
              </list></t>

            <t>The Start-Time
              </t>
              <t/>
            </dd>
          </dl>
          <t>Start-Time indicates a time at or before which the scheduled LSP MUST
          <bcp14>MUST</bcp14> be set up. The When the R bit is set to 0, the value
          of the Start-Time represents the number of seconds since the epoch when R bit is set to 0. epoch.
          When the R bit is set to 1, the value of the Start-Time represents the
          number of seconds from the current time.</t>

          <t>In addition, it the SCHED-LSP-ATTRIBUTE TLV contains the G flag set
          to 1 and a non zero grace-before nonzero Grace-Before and
            grace-after Grace-After in the fields
          GrB/Elastic-Lower-Bound and GrA/Elastic-Upper-Bound if grace periods
          are configured.  It includes the G flag set to 0 and a non
            zero nonzero
          elastic range lower bound and upper bound in the fields if there is
          an elastic range configured.  A TLV can configure a non-zero nonzero grace
          period or elastic range, but it MUST NOT <bcp14>MUST NOT</bcp14> provide both
          for an LSP.
              <list style="symbols">
                <t>GrB (Grace-Before -16 bits): The
          </t>
          <dl>

            <dt>GrB (Grace-Before, 16 bits):</dt><dd>The grace period time
                length
                length, in seconds seconds, before the starting time.</t>

                <t>GrA (Grace-After -16 bits): The start time.</dd>
            <dt>GrA (Grace-After, 16 bits):</dt><dd>The grace period time length
	    length,
                in seconds seconds, after time interval [starting [start time, starting start time +
                duration].</t>

                <t>Elastic-Lower-Bound
                duration].</dd>
            <dt>Elastic-Lower-Bound (16 bits): The bits):</dt><dd>The maximum amount of time
	    time,
                in seconds seconds, that the time interval can shift to lower/left.</t>

                <t>Elastic-Upper-Bound lower/left.</dd>
            <dt>Elastic-Upper-Bound (16 bits): The bits):</dt><dd>The maximum amount of time
	    time,
                in seconds seconds, that the time interval can shift to upper/right.</t>
              </list></t>
		higher/right.</dd>
          </dl>
        </section>
        <section title="SCHED-PD-LSP-ATTRIBUTE TLV" anchor="SCHED-PD-LSP-ATTRIBUTE"> anchor="SCHED-PD-LSP-ATTRIBUTE" numbered="true"
		 toc="default">
          <name>SCHED-PD-LSP-ATTRIBUTE TLV</name>
          <t>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.</t>

          <t>This TLV MUST NOT <bcp14>MUST NOT</bcp14> be included unless both PCEP
	  peers have set the B
            (LSP-SCHEDULING-CAPABILITY) bit and PD (PD-LSP-CAPABLITY) (PD-LSP-CAPABILITY) bit in
            STATEFUL-PCE-CAPABILITY TLV carried in open Open message to one.
            If the TLV is received by a peer when either (or both) bit is zero, zero (or both
	        bits are zero), the peer MUST <bcp14>MUST</bcp14> generate
            a PCEP Error (PCErr) with a PCEP-ERROR object
                having Error-type Error-Type = 19 (Invalid Operation) and
                Error-value = TBD6 ( Attempted 15 (Attempted LSP Scheduling if scheduling while the
		scheduling
                capability was not advertised).</t>
          <t>The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2. <xref
	    target="sched-pd-lsp-attr-tlv"/>.
          </t>

          <figure anchor="sched-pd-lsp-attr-tlv"
                 title="SCHED-PD-LSP-ATTRIBUTE TLV">
                <artwork> anchor="sched-pd-lsp-attr-tlv">
            <name>SCHED-PD-LSP-ATTRIBUTE TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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) (50)          |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Flags|R|C|A|G| Opt   |           NR          |  Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Start-Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Duration                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Repeat-time-length                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   GrB / Elastic-Lower-Bound   |   GrA / Elastic-Upper-Bound   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
              </figure></t>
]]></artwork>
          </figure>

          <t>The type of the TLV is [TBD2] 50, and the TLV has a fixed length of 20
          octets. The description, format format, and meaning of the Flags flags (R, C, A A,
          and G bit),
            Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and Elastic-Upper-Bound
            fields remain the same as in the SCHED-LSP-ATTRIBUTE TLV.</t>

            <t>The following fields are new :<list style="hanging">

                <!--<t hangText="Start-Time (32 bits):">This value in seconds,
                indicates the time when the scheduled LSP is used to carry
                traffic and the corresponding LSP must be setup and
                activated.</t>

                <t hangText="Duration (32 bits):">This 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.</t>

                <t hangText="R (1 bit):">Set to 1 to indicate the the
                Start-Time is a relative time, which is relative to the
                current time; set to 0 to indicate bits), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound,
          and Elastic-Upper-Bound fields remain the same as in the Start-Time is an
                absolute time.</t>-->

                <t hangText="Opt:
          SCHED-LSP-ATTRIBUTE TLV.</t>
          <t>The following fields are new:</t>
          <dl newline="false" spacing="normal">
                <dt>Opt (4 bits)">Indicates bits):</dt>
            <dd>
              <t>Indicates options to repeat.
                When a PCE receives a TLV with a an unknown Opt value,
                it does not compute any path for the LSP.
                It MUST <bcp14>MUST</bcp14> generate a PCEP Error (PCErr) with a
		PCEP-ERROR object
                having Error-type Error-Type = 4 (Not supported object) and
                Error-value = 4 (Unsupported parameter).
                <list>
                    <t>Opt
              </t>
              <dl newline="false" spacing="normal">
                <dt/>
                <dd>Opt = 1: repeat every month;</t>
                    <t>Opt month</dd>
                <dt/>
                <dd>Opt = 2: repeat every year;</t>
                    <t>Opt year</dd>
                <dt/>
                <dd>Opt = 3: repeat every Repeat-time-length.</t>
                  </list> Repeat-time-length</dd>
              </dl>
              <t>
                A user may configure a Repeat-time-length in time units
                weeks, days, hours, minutes, and/or seconds.
                The value represented by these units
                is converted to the number of seconds in the TLV.
                For example, repeat every 2 weeks is equivalent to repeat
		every
                Repeat-time-length = 2*7*86,400 (seconds), where 86,400 is the
                number of seconds per day. </t>

                <t hangText="NR:
            </dd>
            <dt>NR (12 bits)">The bits):</dt>
            <dd>The number of repeats.
                During each repetition, LSP carries traffic. </t>

                <t hangText="Reserved </dd>
            <dt>Reserved (8 bits):">This bits):</dt>
            <dd>
              <t>This field MUST <bcp14>MUST</bcp14> be set to
                zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on
		receipt. <vspace
                blankLines="1"/></t>

                <t hangText="Repeat-time-length: </t>

            </dd>
            <dt>Repeat-time-length (32 bits)">The bits):</dt>
            <dd>The time in
                seconds between the start-time Start-Time of one repetition and
                the start-time Start-Time of the next repetition.
                </t></list></t>
            </dd>
          </dl>
        </section>
      </section>
    </section>
    <section title="The numbered="true" toc="default" anchor="pcep-msgs">
      <name>The PCEP Messages"> Messages</name>
      <section title="The numbered="true" toc="default">
        <name>The PCRpt Message">
      <t>Path Message</name>
        <t>The Path Computation State Report (PCRpt) message is a PCEP message
	sent by a PCC
      to a PCE to report the status of one or more LSPs LSPs, as per <xref target="RFC8231"/>.
      target="RFC8231" format="default"/>.  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 in a PCRpt message is also used in
      delegation or revocation of control of an LSP to/from a PCE.  In the
      case of a scheduled LSP, a scheduled TLV MUST <bcp14>MUST</bcp14> be carried
      in the LSP
      object
      object, and the ERO conveys the intended path for the scheduled LSP. The
      scheduled LSP
      MUST
      <bcp14>MUST</bcp14> be delegated to a PCE.</t>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The PCUpd Message">
          <t>Path Message</name>
        <t>The Path Computation Update Request (PCUpd) message is a PCEP
	message sent by a
      PCE to a PCC to update LSP parameters, on one or more LSPs as per <xref target="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, a scheduled TLV 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).
<!--      Note that in the PCE-initiated case the PCE could send the PCInitiate message
      at the start time to the PCC to create a normal LSP without the scheduled TLV
      and remove the LSP after the duration expires as per <xref target="RFC8281"/>. -->
      </t>
<!--
      This message is also
      used to synchronize the scheduled LSPs to other PCE as described in <xref target="I-D.litkowski-pce-state-sync"/>.</t>
-->
          <!--<t>To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL
          compute the path for the scheduled LSP based on network resource
          availability recorded in scheduled TED which is generated from the
          scheduled LSP-DB, LSP-DB and TED.</t>

          <t>If the request can be satisfied and an available path is found,
          the stateful PCE SHALL send a PCC to update LSP parameters on one or more LSPs, as per <xref
      target="RFC8231" format="default"/>. Each
      LSP Update Request in a PCUpd Message including message contains all LSP
      parameters that a PCE wishes to be set for a given LSP. In the SCHED-
          LSP-ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE case of a
      scheduled LSP, a scheduled TLV <bcp14>MUST</bcp14> be carried in the LSP Object
          body to the PCC. Note that,
      object, and the stateful PCE can update ERO conveys the Scheduled
          LSP parameters later as well based on any network events using intended path for the
          same PCUpd message.</t>

          <t>If conflicts happen or scheduled LSP. If
      no path available is can be found, the requesting
          PCE SHALL return a PCUpd message with an empty ERO as described in <xref target="RFC8231"/>.</t>-->

          <!-- removed by dhruv, as this is incorrect
          <t>If no path used. The A bit is found, used in the stateful PCE sends a
      PCUpd
      message with to indicate the NO Path Object. The definition activation of the PCUpd message to carry scheduled LSP
          objects(see <xref target="RFC8231"/>) if the PCE is unchanged.
      responsible for the activation (as per the C bit).
        </t> -->
      </section>
      <section title="The numbered="true" toc="default">
        <name>The PCInitiate Message">
          <t>An Message</name>
        <t>The LSP Initiate Request (PCInitiate) message is a PCEP message
	sent
          by a PCE to a PCC to trigger LSP instantiation or deletion deletion, as per
	    <xref target="RFC8281"/>. target="RFC8281" format="default"/>.
          In the case of a scheduled LSP, based on the local policy, the PCE MAY
	    <bcp14>MAY</bcp14> convey the scheduled LSP to the PCC by
	    including

          a scheduled TLV in the LSP object. Or Alternatively, the PCE would
	    initiate the LSP only at the start time of the
          scheduled LSP LSP, as per the <xref target="RFC8281"/> target="RFC8281" format="default"/>,
	  without the use of scheduled TLVs.</t>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The PCReq message"> message</name>
        <t>The Path Computation Request (PCReq) message is a PCEP message sent
            by a PCC to a PCE to request a path computation <xref target="RFC5440"/>
	        target="RFC5440" format="default"/>, and it may
            contain the LSP object <xref target="RFC8231"/> to identify the LSP for which the path
            computation is requested. In case of scheduled LSP, a scheduled TLV
            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. The parameters of the LSP may be changed
            (refer to <xref target="lsp-modify"/>).</t>

          <!--<t>After scheduled LSP capability negotiation, for PCC-Initiated
          mode, a PCC can send a PCReq 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
            contain the
          delegation bit set LSP object <xref target="RFC8231" format="default"/>
	    to 1 in identify the LSP Object. The value of requested
          bandwidth for which the path
            computation is taken via requested. In the existing 'Requested Bandwidth with
          BANDWIDTH Object-Type as 1' defined case of a scheduled LSP, a
	    scheduled TLV
            <bcp14>MUST</bcp14> be carried in <xref target="RFC5440"/>.</t>

          <t>Meanwhile, for both modes (PCC-Initiated and PCE-Initiated), the
          delegated PCE shall distribute the scheduling information to other
          PCEs LSP object in the environment by sending a PCRpt PCReq
	    message with to request the
          SCHED-LSP-ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV, as well as
            path computation based on the Bandwith Object scheduled TED and RRO for the found path.</t>

          <t>The definition of LSP-DB. A PCC
	        <bcp14>MAY</bcp14> use the
            PCReq message and PCRpt message to carry obtain the scheduled path before delegating the
            LSP. The parameters of the LSP objects (see [I-D.ietf-pce-stateful-pce]) remains
          unchanged.</t>--> may be changed
            (refer to <xref target="lsp-modify" format="default"/>).</t>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The PCRep Message"> Message</name>
        <t>The Path Computation Reply (PCRep) message is a PCEP message sent
	by a PCE to a PCC in reply to a path
	computation request <xref target="RFC5440"/> target="RFC5440" format="default"/>, and it
	may
            contain the LSP object <xref target="RFC8231"/> target="RFC8231" format="default"/>
	        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, satisfied or a negative
      reply if not.  The  A negative reply may indicate the reason why no
      path could be found. In the case of a scheduled LSP, a scheduled TLV
            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.</t>
          <!--<t>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 PCRpt message with path and resource information for the
          scheduled LSP.</t>

          <t>If no conflict exists, other PCEs SHALL update their scheduled
          LSP-DBs and scheduled TED.</t>

          <t>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 TLV
            <bcp14>MUST</bcp14> be carried in the found
          path back LSP object in PCRep message
	    to indicate the PCC as a successful acknowledge.</t>

          <t>If conflicts happen or no
            path available is found, computation based on the requesting scheduled TED and LSP-DB. A PCC and
	    PCE SHALL return a <bcp14>MAY</bcp14> use
            PCReq and PCRep message with NO PATH back messages to obtain the PCC.</t>--> scheduled path before
	    delegating the
            LSP.</t>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The PCErr Message"> Message</name>
        <t>The Path Computation PCEP Error (PCErr) message is a PCEP message message, as described in
        <xref target="RFC5440"/> target="RFC5440" format="default"/>, for error reporting. The current This
        document defines new error values for several error types to cover
        failures specific to scheduling and reuse reuses the applicable error types
        and error values of <xref target="RFC5440"/> target="RFC5440" format="default"/> and
        <xref target="RFC8231"/> target="RFC8231" format="default"/> wherever appropriate.</t>
        <t>The PCEP extensions for scheduling MUST NOT <bcp14>MUST NOT</bcp14> be used
        if one or both of the PCEP speakers have not set the corresponding
        bits in the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN message Open
        messages to ones. one.  If the PCEP speaker supports the extensions of this
        specification but did not advertise this capability, then upon receipt
        of LSP object with the scheduled TLV, it MUST <bcp14>MUST</bcp14> generate
        a PCEP Error (PCErr) with Error-type=19 Error-Type = 19 (Invalid

   Operation) and error-value TBD6 Error-value = 15 (Attempted LSP Scheduling if scheduling while the
   scheduling capability was not advertised), and it
   SHOULD
   <bcp14>SHOULD</bcp14> ignore the TLV. As per Section 7.1 of <xref target="RFC5440"/>,
   target="RFC5440" sectionFormat="of" section="7.1"/>,
   a legacy PCEP implementation that does not understand this specification, specification
   would consider a scheduled TLV as unknown and ignore them.</t>
   <t>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 of <xref target="RFC8231"/>)
   with LSP error-value = 4 "Unacceptable parameters" in the LSP object
   (with the scheduled TLV) in the PCRpt message to the PCE.</t>
   <t>The scheduled TLV 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).</t>
        </section>
      </section>

<section title="Implementation Status" anchor="imps">

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

  <t>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
     <xref target="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.</t>

  <t>According to <xref target="RFC7942"/>, "this will allow reviewers scheduled TLV unknown and working
     groups to assign due consideration to documents that have ignore it.</t>
        <t>If the
     benefit of running code, which may serve as evidence of valuable
     experimentation and feedback PCC
   decides that have made the implemented
     protocols more mature.  It is up to scheduling parameters proposed in the individual working groups
     to use PCUpd/PCInitiate
   message are
   unacceptable, it <bcp14>MUST</bcp14> report this information as they see fit".</t>

  <t>At error by including the time of posting
   LSP-ERROR-CODE TLV (<xref target="RFC8231"
   sectionFormat="of" section="7.3.3"/>)
   with LSP Error-value = 4 (Unacceptable parameters) in 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 LSP object
   (with the scheduled TLV) in the PCRpt message to
     make any further assertions.</t> the PCE.</t>
        <t>The scheduled TLV <bcp14>MUST</bcp14> be included in the LSP object
	for the scheduled LSPs.
	If the TLV is missing, the receiving PCEP speaker <bcp14>MUST</bcp14>
	send a PCErr message with Error-Type = 6 (Mandatory Object missing)
	and

	Error-value = 16 (Scheduled TLV missing).</t>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document defines the LSP-SCHEDULING-CAPABILITY TLV and
      SCHED-LSP-ATTRIBUTE TLV, TLV; the security considerations
      discussed in <xref target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC8231"/>,
      target="RFC8231" format="default"/>, and <xref target="RFC8281"/> target="RFC8281"
      format="default"/> continue to apply. In some deployments 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 deployments SHOULD <bcp14>SHOULD</bcp14> employ suitable PCEP security
   mechanisms
   like TCP Authentication Option (TCP-AO) (TCP-AO), which is discussed in <xref target="RFC5925"/> or
   target="RFC5925" format="default"/> and
   <xref target="RFC8253"/>, which target="RFC8253" format="default"/>. Note that
   <xref target="RFC8253"/> target="RFC8253" format="default"/> 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.</t>
    </section>
    <section title="Manageability Consideration">
      <section title="Control numbered="true" toc="default">
      <name>Manageability Consideration</name>
      <section numbered="true" toc="default">
        <name>Control of Function and Policy"> Policy</name>
        <t>The LSP-Scheduling LSP scheduling feature MUST <bcp14>MUST</bcp14> be controlled per
	tunnel by the
        active stateful PCE, the PCE. The values for parameters like starting time, start time and
        duration SHOULD <bcp14>SHOULD</bcp14> be configurable by customer
	applications and based on
        the local policy at PCE.
        The suggested default values for starting start time and duration are
        one day in seconds (in seconds) from the current time and one year in seconds (in seconds),
        respectively.
        One day has 86,400 seconds. One year has 31,536,000 seconds.</t>
        <t>When configuring the parameters about for time, a user SHOULD
	<bcp14>SHOULD</bcp14>
        consider leap-years leap years and leap-seconds. leap seconds.
        If a scheduled LSP has a time interval containing a leap-year, leap year,
        the duration of the LSP is 366 days plus the rest of the interval.</t>
      </section>
      <section title="Information numbered="true" toc="default">
        <name>Information and Data Models"> Models</name>
        <t> An implementation SHOULD <bcp14>SHOULD</bcp14> allow the operator to view
	the information
   about each scheduled LSP
   defined in this document.  To serve this purpose, the PCEP YANG
   module <xref target="I-D.ietf-pce-pcep-yang"/> target="I-D.ietf-pce-pcep-yang" format="default"/> could be
	extended.</t>
      </section>
      <section title="Liveness numbered="true" toc="default">
        <name>Liveness Detection and Monitoring"> Monitoring</name>
        <t>Mechanisms defined in this document do not imply any new liveness
        detection and monitoring requirements in addition to those already
        listed in <xref target="RFC5440"/>. target="RFC5440" format="default"/>.
        </t>
      </section>
      <section title="Verify numbered="true" toc="default">
        <name>Verify Correct Operations"> Operations</name>
        <t>Mechanisms defined in this document do not imply any new
	operation verification requirements in addition to those already
	listed in
        <xref target="RFC5440"/>. target="RFC5440" format="default"/>.

        An implementation SHOULD <bcp14>SHOULD</bcp14> allow a user to view the information
        information, including the status about of a scheduled LSP LSP, through CLI. a
        Command Line Interface (CLI) tool.  In addition, it SHOULD <bcp14>SHOULD</bcp14>
        check and handle the cases where there is a significant time
        correction or a clock skew between PCC and PCE.
        </t>
      </section>
      <section title="Requirements On numbered="true" toc="default">
        <name>Requirements on Other Protocols"> Protocols</name>
        <t>Mechanisms defined in this document do not imply any new
        requirements on other protocols.</t>
      </section>
      <section title="Impact On numbered="true" toc="default">
        <name>Impact on Network Operations"> Operations</name>
        <t>Mechanisms defined in this document do not have any impact on
        network operations in addition to those already listed in
        <xref target="RFC5440"/>.</t> target="RFC5440" format="default"/>.</t>
      </section>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section title="PCEP numbered="true" toc="default">
        <name>PCEP TLV Type Indicators">
        <t>This document defines the following new PCEP TLVs. IANA Indicators</name>
    <t>IANA maintains a sub-registry the "PCEP TLV Type Indicators" in subregistry within the
    "Path
    Computation Element Protocol (PCEP) Numbers" registry. IANA is requested
        to make has made the
    following allocations from in this sub-registry. <figure>
            <artwork>Value     Meaning                         Reference
 TBD1 SCHED-LSP-ATTRIBUTE                 This document
 TBD2 SCHED-PD-LSP-ATTRIBUTE              This document</artwork>
          </figure></t>

      <section title="Opt Field subregistry for the new PCEP TLVs defined in SCHED-PD-LSP-ATTRIBUTE TLV">
<t>IANA is requested
    this document. </t>

<table anchor="PCEP-TLVs">
  <name>Additions to create PCEP TLV Type Indicators Subregistry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>49</td>
      <td>SCHED-LSP-ATTRIBUTE</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>50</td>
      <td>SCHED-PD-LSP-ATTRIBUTE</td>
      <td>This document</td>
    </tr>
  </tbody>
</table>

<section>
          <name>SCHED-PD-LSP-ATTRIBUTE TLV Opt Field</name>
          <t>IANA has created and will maintain a new
sub-registry
subregistry named "SCHED-PD-LSP-ATTRIBUTE TLV Opt field" Field"
within the "Path Computation Element Protocol (PCEP) Numbers" registry.
Initial values for the sub-registry subregistry are given below.
New values are assigned by Standards Action <xref target="RFC8126"/>.</t>
<figure>
  <artwork>
  Value    Name                              Reference
  -----    ----                              ----------
   0       Reserved
   1       REPEAT-EVERY-MONTH                This document
   2       REPEAT-EVERY-YEAR                 This target="RFC8126"
format="default"/>.</t>

<table anchor="opt-field">
  <name>New SCHED-PD-LSP-ATTRIBUTE TLV Opt Field Subregistry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Reserved</td>
      <td></td>
    </tr>
    <tr>
      <td>1</td>
      <td>REPEAT-EVERY-MONTH </td>
      <td>This document</td>
    </tr>
    <tr>
      <td>2</td>
      <td>REPEAT-EVERY-YEAR</td>
      <td>This document
   3       REPEAT-EVERY-REPEAT-TIME-LENGTH   This </td>
    </tr>
    <tr>
      <td>3</td>
      <td>REPEAT-EVERY-REPEAT-TIME-LENGTH</td>
      <td>This document
   4-14    Unassigned
   15      Reserved
  </artwork>
</figure>
       </section>

      <section title="Schedule </td>
    </tr>
    <tr>
      <td>4-14</td>
      <td>Unassigned</td>
      <td></td>
    </tr>
    <tr>
      <td>15</td>
      <td>Reserved</td>
      <td></td>
    </tr>
  </tbody>
</table>
</section>
        <section numbered="true" toc="default">
          <name>Schedule TLVs Flag Field"> Field</name>
          <t>IANA is requested to create has created a new sub-registry, subregistry named "Schedule TLVs Flag Field",
          Field" within the "Path Computation Element Protocol (PCEP) Numbers"
          registry.  New values are assigned by Standards Action <xref target="RFC8126"/>.
          target="RFC8126" format="default"/>.  Each bit should be tracked
          with the following qualities:
   <list style="symbols">
   <t>Bit
          </t>
          <ul spacing="normal">
            <li>Bit number (counting from bit 0 as the most significant bit)</t>
   <t>Capability description</t>
   <t>Defining RFC</t></list>
   </t>
	    bit)</li>
            <li>Capability description</li>
            <li>Defining RFC</li>
          </ul>
          <t>The following values are defined in this document:<figure>
            <artwork>
Bit    Description                                    Reference
0-3    Unassigned
4      Relative document:</t>

<table anchor="schedule-tlvs">
  <name>New Schedule TLVs Flag Field Subregistry</name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0-3</td>
      <td>Unassigned</td>
      <td></td>
    </tr>
    <tr>
      <td>4</td>
      <td>Relative Time (R-bit)                          This document
5      PCC (R-bit)</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>5</td>
      <td>PCC Responsible (C-bit)                        This document
6      LSP (C-bit)</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>6</td>
      <td>LSP Activated (A-bit)                          This document
7      Grace (A-bit)</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>7</td>
      <td>Grace Period Included (G-bit)                  This document</artwork>
          </figure></t> (G-bit)</td>
      <td>This document</td>
    </tr>
  </tbody>
</table>

        </section>
      </section>
      <section title="STATEFUL-PCE-CAPABILITY numbered="true" toc="default">
        <name>STATEFUL-PCE-CAPABILITY TLV Flag field"> Field</name>
        <t>This document defines new bits in the Flags field in the
        STATEFUL-PCE-CAPABILITY TLV in the OPEN object. IANA maintains a sub-registry the
        "STATEFUL-PCE-CAPABILITY TLV Flag Field" in subregistry within the "Path
        Computation Element Protocol (PCEP) Numbers" registry. IANA is requested
        to make has
        made the following allocations from this sub-registry.</t>

        <t>The following values are defined in this document:<figure>
            <artwork>Bit    Description                                 Reference
 TBD3   LSP-SCHEDULING-CAPABILITY (B-bit)          This document
 TBD4   PD-LSP-CAPABLITY (PD-bit)                  This document</artwork>
          </figure></t>

      </section>

    <section title="PCEP-Error Object">
      <t>IANA is requested subregistry.</t>

<table anchor="stateful-pce-flag">
  <name>Additions to allocate STATEFUL-PCE-CAPABILITY TLV Flag Field Subregistry</name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>22</td>
      <td>LSP-SCHEDULING-CAPABILITY (B-bit)</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>21</td>
      <td>PD-LSP-CAPABILITY (PD-bit)</td>
      <td>This document</td>
    </tr>
  </tbody>
</table>
      </section>
      <section numbered="true" toc="default">
        <name>PCEP-ERROR Object Error Types and Values</name>
        <t>IANA has allocated 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:<figure><artwork>
   Error-Type  Meaning
      6        Mandatory registry:</t>

<table anchor="PCEP-error">
  <name>Additions to PCEP-ERROR Object missing

                Error-value
                TBD5: Error Types and Values
  Subregistry</name>
  <thead>
    <tr>
      <th>Error-Type</th>
      <th>Meaning</th>
      <th>Error-value</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>6</td>
      <td>Mandatory Object missing</td>
      <td>16:  Scheduled TLV missing

      19       Invalid Operation

                Error-value
                TBD6: missing</td>
    </tr>
    <tr>
      <td>19</td>
      <td>Invalid Operation</td>
      <td>15: Attempted LSP Scheduling if scheduling while the scheduling capability was not advertised

      29       Path
      advertised</td>
    </tr>
    <tr>
      <td>29</td>
      <td>Path computation failure

                Error-value
                TBD7: failure</td>
      <td>5: Constraints could not be met for some intervals
</artwork></figure>
 </t> intervals</td>
    </tr>
  </tbody>
</table>

      </section>
    </section>
  </middle>
  <back>
<displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
<displayreference target="I-D.litkowski-pce-state-sync" to="PCE-STATE-SYNC"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8232.xml"/>
	<xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8413.xml"/>
      </references>

      <references>
        <name>Informative References</name>
	<xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7399.xml"/>
	<xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.litkowski-pce-state-sync.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-pce-pcep-yang.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>

      </references>
    </references>

    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors of this document would also like to thank Rafal
      Szarecki, Adrian Farrel, Cyril Margaria <contact
      fullname="Rafal Szarecki"/>, <contact fullname="Adrian Farrel"/>, and
      <contact fullname="Cyril Margaria"/> for the review and comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.5440'?>
      <?rfc include='reference.RFC.5905'?>
      <?rfc include="reference.RFC.8126"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.8231"?>
      <?rfc include="reference.RFC.8232"?>

      <!--<?rfc include="reference.I-D.ietf-pce-stateful-sync-optimizations"?>-->

      <?rfc include="reference.RFC.8281"?>
      <?rfc include="reference.RFC.8413"?>
      <!--<?rfc include="reference.I-D.ietf-pce-stateful-pce-auto-bandwidth"?>-->

    </references>

    <!-- Normative -->

    <references title="Informative References">

      <!--<?rfc include='reference.RFC.5226'?>-->

      <?rfc include='reference.RFC.5925'?>

      <?rfc include='reference.RFC.7399'?>
      <?rfc include='reference.RFC.7942'?>
      <!--<?rfc include='reference.RFC.7420'?>-->
      <?rfc include="reference.RFC.8051"?>
      <?rfc include="reference.RFC.8253"?>
      <?rfc include="reference.RFC.8402"?>
      <?rfc include="reference.I-D.ietf-pce-pcep-yang"?>
      <?rfc include="reference.I-D.ietf-detnet-architecture"?>

    </references>

<!--
    <section title="Scheduled LSP information synchronization">
      <t>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.</t>

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

      <t>The information of SLSP-DB MUST be shared and synchronized among all
      PCEs within the centralized network by using PCRpt and PCUpd message with
      scheduled LSP information as per the mechanism described in <xref target="I-D.litkowski-pce-state-sync"/>. </t>

      <t>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.</t>
    </section>
-->

    <section title="Contributors Addresses">
      <figure>
        <artwork>   Dhruv Dhody
   Huawei
   Divyashree numbered="false" toc="default">
      <name>Contributors</name>

<contact fullname="Dhruv Dhody">
<organization>Huawei</organization>
<address>
<postal>
<street>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 Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</contact>

<contact fullname="Xufeng Liu">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<country>United States of America</country>
</postal>
<email>xliu@kuatrotech.com</email>
</address>
</contact>

<contact fullname="Mehmet Toy">
<organization>Verizon</organization>
<address>
<postal>
<street></street>
<country>United States of America</country>
</postal>
<email>mehmet.toy@verizon.com</email>
</address>
</contact>

<contact fullname="Vic Liu">
<organization>China Mobile</organization>
<address>
<postal>
<street>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 District</street>
<city>Beijing</city>
<code>100053</code>
<country>China</country>
</postal>
<email>liu.cmri@gmail.com</email>
</address>
</contact>

<contact fullname="Lei Liu">
<organization>Fujitsu</organization>
<address>
<postal>
<street></street>
<country>United States of America</country> </postal>
<email>lliu@us.fujitsu.com</email>
</address>
</contact>

<contact fullname="Khuzema Pithewan">
<organization>Infinera</organization>
<address>
<postal>
<street></street>
<country></country>
</postal>
<email>kpithewan@infinera.com</email>
</address>
</contact>

<contact fullname="Zitao Wang">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: wangzitao@huawei.com

   Xian Zhang
   Huawei Technologies
   Research District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>wangzitao@huawei.com</email>
</address>
</contact>

<contact fullname="Xian Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Research Area F3-1B,
   Huawei F3-1B</street>
<cityarea>Huawei Industrial Base,
   Shenzhen, 518129, China

   Email: zhang.xian@huawei.com</artwork>
      </figure> Base</cityarea>
<city>Shenzhen</city>
<code>518129</code>
<country>China</country>
</postal>
<email>zhang.xian@huawei.com</email>
</address>
</contact>

    </section>

    <!-- Informative -->

</back>
</rfc>