rfc8934xml2.original.xml   rfc8934.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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">
]>
<rfc category="std" 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" ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-ietf-pce-stateful-pce-lsp-scheduling-27" number="8934"
ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
category="std" consensus="true" xml:lang="en" tocInclude="true"
symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="LSP Scheduling">PCEP Extensions for LSP scheduling with <title abbrev="PCEP Extensions for LSP Scheduling">PCE
stateful PCE</title> Communication Protocol (PCEP) Extensions for Label Switched Path (LSP)
Scheduling with Stateful PCE</title>
<author fullname="Huaimo Chen " initials="H." role="editor" surname="Chen"> <seriesInfo name="RFC" value="8934"/>
<author fullname="Huaimo Chen " initials="H." role="editor"
surname="Chen">
<organization>Futurewei</organization> <organization>Futurewei</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Boston</city> <city>Boston</city>
<region>MA</region> <region>MA</region>
<code/> <code/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>huaimo.chen@futurewei.com</email> <email>huaimo.chen@futurewei.com</email>
</address> </address>
</author> </author>
<author fullname="Yan Zhuang" initials="Y." role="editor"
<author fullname="Yan Zhuang" initials="Y." role="editor" surname="Zhuang"> surname="Zhuang">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>101 Software Avenue, Yuhua District</street> <street>101 Software Avenue</street>
<extaddr>Yuhua District</extaddr>
<city>Nanjing</city> <city>Nanjing</city>
<region>Jiangsu</region> <region>Jiangsu</region>
<code>210012</code> <code>210012</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhuangyan.zhuang@huawei.com</email> <email>zhuangyan.zhuang@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Qin Wu" initials="Q." surname="Wu"> <author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>101 Software Avenue, Yuhua District</street> <street>101 Software Avenue</street>
<extaddr>Yuhua District</extaddr>
<city>Nanjing</city> <city>Nanjing</city>
<region>Jiangsu</region> <region>Jiangsu</region>
<code>210012</code> <code>210012</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>bill.wu@huawei.com</email> <email>bill.wu@huawei.com</email>
</address> </address>
</author> </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"> <author fullname="Daniele Ceccarelli" initials="D." surname="Ceccarelli">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Via A. Negrone 1/A</street> <street>Via A. Negrone 1/A</street>
<city>Genova - Sestri Ponente</city> <city>Genova - Sestri Ponente</city>
<country>Italy</country> <country>Italy</country>
</postal> </postal>
<email>daniele.ceccarelli@ericsson.com</email> <email>daniele.ceccarelli@ericsson.com</email>
</address> </address>
</author> </author>
<date year="2020" month="October" />
<date year="2020"/>
<area>Routing Area</area> <area>Routing Area</area>
<workgroup>PCE Working Group</workgroup> <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> <keyword>Path Computation Element</keyword>
<abstract> <abstract>
<t>This document defines a set of extensions needed to the stateful
Path Computation Element (PCE) communication Protocol (PCEP), so as to <t>This document defines a set of extensions to the stateful
enable Labeled Switched Path (LSP) path computation, PCE Communication Protocol (PCEP) to
activation, setup and deletion based on scheduled time intervals for the L enable Label Switched Path (LSP) path computation,
SP and activation, setup, and deletion based on scheduled time intervals for
the LSP and
the actual network resource usage the actual network resource usage
in a centralized network environment as stated in in a centralized network environment, as stated in
RFC 8413.</t> RFC 8413.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>The Path Computation Element Protocol (PCEP) defined in <xref target="R <name>Introduction</name>
FC5440"/> is <t>The PCE Communication Protocol (PCEP) defined in
used between a Path Computation Element (PCE) and a Path Computation <xref target="RFC5440" format="default"/> is used between a Path
Client (PCC) (or other PCE) to enable path computation of Multi-protocol Computation Element (PCE) and a Path Computation Client (PCC) (or other
Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE PCE) to enable path computation of Multiprotocol Label Switching (MPLS)
LSPs).</t> Traffic Engineering Label Switched Paths (TE LSPs).</t>
<t><xref target="RFC8231" format="default"/> describes a set of
<t><xref target="RFC8231"/> describes a set of extensions to PCEP to provi extensions to PCEP to provide stateful control. A stateful PCE has
de stateful access to not only the information carried by the network's Interior
control. A stateful PCE has access to not only the information Gateway Protocol (IGP) but also the set of active paths and their
carried by the network's Interior Gateway Protocol (IGP) but also the reserved resources for its computations. The additional state allows
set of active paths and their reserved resources for its the PCE to compute constrained paths while considering individual LSPs
computations. The additional state allows the PCE to compute and their interactions. </t>
constrained paths while considering individual LSPs and their
interactions. </t>
<t>Traditionally, the usage and allocation of network resources, <t>Traditionally, the usage and allocation of network resources,
especially bandwidth, can be supported by a Network Management System (NMS especially bandwidth, can be supported by a Network Management System
) (NMS)
operation such as path pre-establishment. However, this does not provide operation such as path pre-establishment. However, this does not provide
efficient usage of network resources. The established paths reserve the efficient usage of network resources. The established paths reserve the
resources forever, which cannot be used by other services even resources forever, so they cannot be used by other services even
when they are not used when they are not used
for transporting any service. <xref target="RFC8413"/> then for transporting any service. <xref target="RFC8413" format="default"/>
provides a framework that describes and discusses the problem, and then
provides a framework that describes and discusses the problem and
defines an appropriate architecture for the scheduled reservation of TE defines an appropriate architecture for the scheduled reservation of TE
resources.</t> resources.</t>
<t> <t>
The scheduled reservation of TE resources allows network operators to The scheduled reservation of TE resources allows network operators to
reserve resources in advance according to the agreements with their reserve resources in advance according to the agreements with their
customers, and allows them to transmit data about scheduling such as customers and allows them to transmit data about scheduling, such as
a specified start time and duration, for example for a scheduled bulk a specified start time and duration (for example, for a scheduled
data replication between data centers. It enables the bulk data replication between data centers).
activation of bandwidth usage at the time the service is really being used
while letting other services use it when this service is not using it.
It enables the activation of
bandwidth usage at the time the service is really being used while
letting other services use the bandwidth when it is not being used by this
service.
The requirement of The requirement of
scheduled LSP provisioning is mentioned in <xref target="RFC8231"/> scheduled LSP provisioning is mentioned in <xref target="RFC8231"
and <xref target="RFC7399"/>. format="default"/>
and <xref target="RFC7399" format="default"/>.
Also, for Also, for
deterministic networks <xref target="I-D.ietf-detnet-architecture"/>, deterministic networks <xref target="RFC8655" format="default"/>,
the scheduled LSP or temporal LSP can provide a better network the scheduled LSP or temporal LSP can provide better network
resource usage for guaranteed links. This idea can also be applied in resource usage for guaranteed links. This idea can also be applied in
segment routing <xref target="RFC8402"/> segment routing <xref target="RFC8402" format="default"/>
to schedule the network resources over the whole network to schedule the network resources over the whole network
in a centralized manner as well.</t> in a centralized manner.</t>
<t>With this in mind, this document defines a set of needed extensions
<t>With this in mind, this document defines a set of extensions needed
to PCEP used for stateful PCEs to PCEP used for stateful PCEs
so as to enable LSP scheduling for path computation so as to enable LSP scheduling for path computation
and LSP setup/deletion based on the actual network resource usage and LSP setup/deletion based on the actual network resource usage
duration of a traffic service. A scheduled LSP is characterized by a duration of a traffic service. A scheduled LSP is characterized by a
starting time and a duration. When the end of the LSP life is reached, 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 it is deleted to free up the resources for other LSPs (scheduled or
not).</t> not).</t>
</section> </section>
<section numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<t>
The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Conventions used in this document"> <section numbered="true" toc="default">
<t> <name>Terminology</name>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The following terminology is reused from existing PCE
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", documents.</t>
"MAY", and "OPTIONAL" in this document are to be interpreted as <ul spacing="normal">
described in BCP 14 <xref <li>Active Stateful PCE <xref target="RFC8051"
target="RFC2119"></xref> <xref format="default"/></li>
target="RFC8174"></xref> when, and only when, they <li>Delegation <xref target="RFC8051" format="default"/></li>
appear in all capitals, as shown here. <li>PCE-initiated LSP <xref target="RFC8281" format="default"/></li>
</t> <li>PCC <xref target="RFC5440" format="default"/></li>
<li>PCE <xref target="RFC5440" format="default"/></li>
<section title="Terminology"> <li>TE LSP <xref target="RFC5440" format="default"/></li>
<t>The following terminology is re-used from existing PCE <li>TED (Traffic Engineering Database) <xref target="RFC5440"
documents.<list style="symbols"> format="default"/></li>
<t>Active Stateful PCE <xref target="RFC8051"/></t> <li>LSP-DB (LSP State Database) <xref target="RFC8051"
format="default"/></li>
<t>Delegation <xref target="RFC8051"/></t> </ul>
<t>In addition, this document defines the following
<t>PCE-Initiated LSP <xref target="RFC8281"/></t> terminologies.</t>
<dl newline="false" spacing="normal">
<t>PCC <xref target="RFC5440"/></t> <dt>Scheduled TE LSP (or Scheduled LSP for short):</dt>
<dd>
<t>PCE <xref target="RFC5440"/></t> An LSP with scheduling
attributes that carries traffic flow demand at a start time and
<t>TE LSP <xref target="RFC5440"/></t> lasts for a certain duration (or from a start time to an end time,
where the end time is the start time plus the duration).
<t>TED <xref target="RFC5440"/></t> A scheduled LSP is also called a "temporal LSP".
<t>LSP-DB <xref target="RFC8051"/></t>
</list>In addition, this document defines the following
terminologies.<list style="hanging">
<t hangText="Scheduled TE LSP (or Scheduled LSP for short):">
an LSP with the scheduling
attributes, that carries traffic flow demand at a starting time and
lasts for a certain duration (or from a starting time to an ending t
ime,
where the ending time is the starting time plus the duration).
A scheduled LSP is also called a temporal LSP.
The PCE operates path computation per The PCE operates path computation per
LSP availability for the required time and duration.</t> LSP availability for the required time and duration.</dd>
<dt>Scheduled LSP-DB (SLSP-DB):</dt>
<t hangText="Scheduled LSP-DB:">a database of scheduled LSPs.</t> <dd>A database of scheduled LSPs.</dd>
<dt>Scheduled TED:</dt>
<t hangText="Scheduled TED:">Traffic engineering database with the <dd>Traffic engineering database with the
awareness of scheduled resources for TE. This database is awareness of scheduled resources for TE. This database is
generated by the PCE from the information in TED and scheduled LSP-D generated by the PCE from the information in the TED and scheduled
B LSP-DB;
and allows knowing, at any time, it allows knowing, at any time,
the expected amount of available resources (discounting the expected amount of available resources (discounting
the possibility of failures in the future).</t> the possibility of failures in the future).</dd>
<dt>Start time (Start-Time):</dt>
<t hangText="Starting time (start-time):">This value indicates when <dd>This value indicates when
the scheduled LSP is used and the corresponding LSP must be setup the scheduled LSP is used and the corresponding LSP must be set up
and active. In other time (i.e., before the starting time or after and active. At other times (i.e., before the start time or after
the starting time plus Duration), the LSP can be inactive to the start time plus duration), the LSP can be inactive to
include the possibility of the resources being used by other include the possibility of the resources being used by other
services.</t> services.</dd>
<dt>Duration:</dt>
<t hangText="Duration:">This value indicates the length of time that <dd>This value indicates the length of time that
the LSP is undertaken by a traffic flow and the corresponding LSP the LSP carries a traffic flow and the corresponding LSP
must be setup and active. At the end of which, the LSP is torn down must be set up and active. At the end of the duration, the LSP is
and removed from the database.</t> torn down
</list></t> and removed from the database.</dd>
</dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Motivation and Objectives"> <name>Motivation and Objectives</name>
<t>A stateful PCE <xref target="RFC8231"/> can support better efficiency <t>A stateful PCE <xref target="RFC8231" format="default"/> can support
better efficiency
by using LSP scheduling by using LSP scheduling
described in the use case of <xref target="RFC8051"/>. described in the use case of <xref target="RFC8051" format="default"/>.
This requires the PCE to This requires the PCE to
maintain the scheduled LSPs and their associated resource usage, e.g. maintain the scheduled LSPs and their associated resource usage (e.g.,
bandwidth for Packet-switched network, as well as have the ability to bandwidth for packet-switched network) as well as have the ability to
trigger signaling for the LSP setup/tear-down at the correct time.</t> trigger signaling for the LSP setup/tear-down at the correct time.</t>
<t>Note that existing configuration tools can be used for LSP <t>Note that existing configuration tools can be used for LSP
scheduling, but as highlighted in section 3.1.3 of <xref target="RFC8231"/ scheduling, but as highlighted in <xref
> target="RFC8231" sectionFormat="of" section="3.1.3"/>
as well as discussions in as well as discussions in
<xref target="RFC8413"/>, doing this as a part of PCEP in a <xref target="RFC8413" format="default"/>, doing this as a part of PCEP
centralized manner, has obvious advantages.</t> in a
centralized manner has obvious advantages.</t>
<t>This document provides a set of extensions to PCEP to enable LSP <t>This document provides a set of extensions to PCEP to enable LSP
scheduling for LSP creation/deletion under the stateful control of a scheduling for LSP creation/deletion under the stateful control of a
PCE and according to traffic service requests from customers, so as PCE and according to traffic service requests from customers, so as
to improve the usage of network resources.</t> to improve the usage of network resources.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Procedures and Mechanisms"> <name>Procedures and Mechanisms</name>
<section title="LSP Scheduling Overview" anchor="LSPSchedulingOverview"> <section anchor="LSPSchedulingOverview" numbered="true" toc="default">
<t>The LSP scheduling allows PCEs and PCCs to provide scheduled LSP <name>LSP Scheduling 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 for customers' traffic services at its actual usage time, so as to
improve the network resource utilization efficiency.</t> improve the network resource utilization efficiency.</t>
<t>For stateful PCE supporting LSP scheduling, there are two types of <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 LSP databases used in this document. One is the LSP-DB defined in PCEP
<xref target="RFC8231"/>, while the other is the scheduled LSP database <xref target="RFC8231" format="default"/>, while the other is the
(SLSP-DB, see scheduled LSP database (SLSP-DB). The SLSP-DB records
section 6). The SLSP-DB records scheduled LSPs and is used in conjunctio scheduled LSPs and is used in conjunction with
n with
the TED and LSP-DB. Note that the two types of LSP the TED and LSP-DB. Note that the two types of LSP
databases can be implemented in one physical database or two different databases can be implemented in one physical database or two different
databases. This is an implementation matter and this document does not s databases. This is an implementation matter, and this document does
tate any preference.</t> not state any preference.</t>
<t>Furthermore, a scheduled TED can be generated from the scheduled <t>Furthermore, a scheduled TED can be generated from the scheduled
LSP-DB, LSP-DB and TED to indicate the network links and nodes with LSP-DB, LSP-DB, and TED to indicate the network links and nodes with
resource availability information for now and future. The scheduled resource availability information for now and the future. The
TED MUST be maintained by all PCEs within the network scheduled
TED <bcp14>MUST</bcp14> be maintained by all PCEs within the network
environment.</t> environment.</t>
<!--<t>In case of implementing PCC-initiated scheduled LSPs, a PCC can <t>In the case of implementing PCC-initiated scheduled LSPs, when
request a path computation with LSP information of its scheduling delegating a scheduled LSP, a PCC <bcp14>MUST</bcp14> include that
parameters, including the starting time and the duration. Upon LSP's scheduling parameters (see <xref target="SCHED-LSP-ATTRIBUTE"
receiving the request with the scheduled LSP delegation, a stateful format="default"/>), including the start time and duration, using a
PCE SHALL check the scheduled TED for the network resource Path Computation State Report (PCRpt) message. Since the LSP is not
availability on network nodes and compute a path for the LSP with the yet signaled, at the time of delegation, the LSP would be in down
scheduling information.</t>--> state. Upon receiving the delegation of the scheduled LSP, a stateful
PCE <bcp14>MUST</bcp14> check whether the parameters are valid. If
<t>In case of implementing PCC-initiated scheduled LSPs, they are valid, it <bcp14>SHALL</bcp14> check the scheduled TED for
when delegating a scheduled LSP, the network resource availability on network nodes, compute a path for
a PCC MUST include its scheduling the LSP with the scheduling information, and update to the PCC as per
parameters (see <xref target="SCHED-LSP-ATTRIBUTE"/>), the active stateful PCE techniques <xref target="RFC8231"
including the starting time and the duration using PCRpt message. format="default"/>.</t>
Since the LSP is not yet signaled, at the time of delegation <t>Note that the active stateful PCE can update to the PCC with the
the LSP would be in down state. path for the scheduled LSP at any time. However, the PCC should not
Upon signal the LSP over the path after receiving these messages since the
receiving the delegation of the scheduled LSP, a stateful path is not active yet; the PCC signals the LSP at the start time.</t>
PCE MUST check whether the parameters are valid. If they are valid,
it SHALL check the scheduled TED for the network resource
availability on network nodes and compute a path for the LSP with the
scheduling information and update to the PCC as per the active stateful
PCE techniques <xref target="RFC8231"/>.</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 receiving these
messages since the path is not active yet; PCC signals the LSP at the st
arting
time.</t>
<!--<t>For a multiple PCE environment, in order to coordinate the
scheduling request of the LSP path over the network, the PCE needs to
send a 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 LS
P to other PCEs, any future
update to the scheduled LSP is also updated to other PCEs. This way th
e state of all scheduled LSPs
are synchronized among the PCEs. <xref target="RFC7399"/> discusses so
me 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 informa
tion.
The ingress PCE acting as a PCC sends its next hop PCE the PCRpt messa
ge.
After receiving the PCRpt message, the next hop PCE acting as a PCC se
nds
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 <t>In the case of multiple PCEs within a single domain, the PCE would
to synchronize their scheduling information with other PCEs need to synchronize their scheduling information with other PCEs
within the domain. This could be achieved by proprietary database within the domain.
synchronization techniques or via a possible PCEP extension
[I-D.litkowski-pce-state-sync]. The technique used to synchronize
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 This could be achieved by proprietary database-synchronization techniques or
case of implementing PCE-initiated scheduled LSP, the stateful PCE via a possible PCEP extension (see <xref
SHALL check the network resource availability for the traffic and target="I-D.litkowski-pce-state-sync"/>). The technique used to synchronize an
compute a path for the scheduled LSP and initiate a scheduled LSP SLSP-DB is out of scope for this document. When the scheduling information is
at the PCC and synchronize the scheduled LSP to out of synchronization among some PCEs, some scheduled LSPs may not be set up
other PCEs. Note that, the PCC could be notified immediately or at the successfully. </t>
starting time of the scheduled LSP based on the local policy. <t>The scheduled LSP can also be initiated by a PCE itself. In the
In the former case, the case of implementing a PCE-initiated scheduled LSP, the stateful PCE
SCHED-LSP-ATTRIBUTE TLV (see <xref target="SCHED-LSP-ATTRIBUTE"/>) <bcp14>SHALL</bcp14> check the network resource availability for the
MUST be included in the message whereas, for traffic, compute a path for the scheduled LSP, and initiate a
the latter the SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be included. scheduled LSP at the PCC and synchronize the scheduled LSP to other
Either way the synchronization to other PCEs MUST be done PCEs. Note that the PCC could be notified immediately or at the start
time of the scheduled LSP, based on the local policy. In the former
case, the SCHED-LSP-ATTRIBUTE TLV (see <xref
target="SCHED-LSP-ATTRIBUTE" format="default"/>) <bcp14>MUST</bcp14>
be included in the message, whereas for the latter, the
SCHED-LSP-ATTRIBUTE TLV <bcp14>SHOULD NOT</bcp14> be included. Either
way, the synchronization to other PCEs <bcp14>MUST</bcp14> be done
when the scheduled LSP is created.</t> when the scheduled LSP is created.</t>
<t>In both modes, for activation of scheduled LSPs, the PCC
<t>In both modes, for activation of scheduled LSPs, the PCC MUST <bcp14>MUST</bcp14>
initiate the setup of scheduled LSP at the start time. initiate the setup of the scheduled LSP at the start time.
Similarly on Similarly, on the scheduled usage expiry, the PCC
scheduled usage expiry, the PCC MUST initiate the removal of the LSP <bcp14>MUST</bcp14>
based on the Flag set in SCHED-LSP-ATTRIBUTE TLV.</t> initiate the removal of the LSP
based on the flag set in the SCHED-LSP-ATTRIBUTE TLV.</t>
<!--the stateful PCE </section>
can send a path computation LSP Initiate (PCInitiate message) with LSP <section numbered="true" toc="default">
information at its starting time to the PCC for signaling the LSP over <name>Support of LSP Scheduling</name>
the network nodes as defined in <xref target="RFC8281"/>. <section numbered="true" toc="default">
Also, in the PCC-initiated mode, with scheduling information ,the PCC <name>LSP Scheduling</name>
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 of LSP Scheduling">
<section title="LSP Scheduling">
<t>For a scheduled LSP, a user configures it with an arbitrary <t>For a scheduled LSP, a user configures it with an arbitrary
scheduling duration from time Ta to time Tb, which may be scheduling period from time Ta to time Tb, which may be
represented as [Ta, Tb].</t> represented as [Ta, Tb].</t>
<t>When an LSP is configured with arbitrary scheduling period [Ta,
<t>When an LSP is configured with arbitrary scheduling duration [Ta,
Tb], a path satisfying the constraints for the LSP in the scheduling Tb], a path satisfying the constraints for the LSP in the scheduling
duration is computed and the LSP along the path is set up to carry period is computed, and the LSP along the path is set up to carry
traffic from time Ta to time Tb.</t> traffic from time Ta to time Tb.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Periodical LSP Scheduling"> <name>Periodical LSP Scheduling</name>
<t>In addition to LSP Scheduling at an arbitrary time period, there <t>In addition to LSP scheduling at an arbitrary time period, there
are also periodical LSP Scheduling.</t> is also periodical LSP scheduling.</t>
<t>Periodical LSP scheduling means an LSP has multiple time
<t>A periodical LSP Scheduling means an LSP has multiple time interval intervals
s
and the LSP is set up to carry traffic in every time and the LSP is set up to carry traffic in every time
interval. It has a scheduling duration such as [Ta, Tb], a number of interval. It has a scheduling period such as [Ta, Tb], a number of
repeats such as 10 (repeats 10 times), and a repeat cycle/time repeats such as 10 (repeats 10 times), and a repeat cycle/time
interval such as a week (repeats every week). The scheduling interval such as a week (repeats every week). The scheduling
interval: "[Ta, Tb] repeats n times with repeat cycle C" represents interval "[Ta, Tb] repeats n times with repeat cycle C" represents
n+1 scheduling intervals as follows:<figure> n+1 scheduling intervals as follows:</t>
<artwork>[Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+n
C]</artwork> <t indent="3">
</figure></t> [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC]</t>
<t>When an LSP is configured with a scheduling interval such as <t>When an LSP is configured with a scheduling interval such as
"[Ta, Tb] repeats 10 times with a repeat cycle a week" (representing "[Ta, Tb] repeats 10 times with a repeat cycle of a week"
11 scheduling intervals), a path satisfying the constraints for the (representing 11 scheduling intervals), a path satisfying the
LSP in every interval represented by the constraints for the LSP in every interval represented by the
periodical scheduling interval is computed once. periodical scheduling interval is computed once. Note that the path
Note that the path computed for one recurrence may be different from computed for one recurrence may be different from the path for
the path for another recurrence. another recurrence. And then the LSP along the path is set up to
And then the LSP along the carry traffic in each of the scheduling intervals. If there is no
path is set up to carry traffic in each of the scheduling path satisfying the constraints for some of the intervals, the LSP
intervals. If there is no path satisfying the constraints <bcp14>MUST NOT</bcp14> be set up at all.
for some of the intervals, the LSP MUST NOT be set up at all.
It MUST generate a PCEP Error (PCErr) with
Error-type = 29 (Path computation failure) and
Error-value = TBD7 (Path could not be found for some intervals).
</t>
<section title="Elastic Time LSP Scheduling"> It <bcp14>MUST</bcp14> generate a PCEP Error (PCErr) with
Error-Type = 29 (Path computation failure) and
Error-value = 5 (Constraints could not be met for some intervals).
</t>
<section numbered="true" toc="default">
<name>Elastic Time LSP Scheduling</name>
<t>In addition to the basic LSP scheduling at an arbitrary time <t>In addition to the basic LSP scheduling at an arbitrary time
period, another option is elastic time intervals, which is period, another option is elastic time intervals, which is
represented as within -P and Q, where P and Q is an amount of time represented as within -P and Q, where P and Q are amounts of time
such as 300 seconds. P is called elastic range lower bound and Q such as 300 seconds. P is called the elastic range lower bound,
is called elastic range upper bound.</t> and Q
is called the elastic range upper bound.</t>
<t>For a simple time interval such as [Ta, Tb] with an elastic <t>For a simple time interval such as [Ta, Tb] with an elastic
range, elastic time interval: "[Ta, Tb] within -P and Q" means a range, elastic time interval "[Ta, Tb] within -P and Q" means a
time period from (Ta+X) to (Tb+X), where -P &lt;= X &lt;= Q. Note 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'. that both Ta and Tb are shifted by the same X.
This elastic time interval is suitable for the case where This elastic time interval is suitable for the case where
a user wants to have a scheduled LSP up to carry the traffic a user wants to have a scheduled LSP up to carry the traffic
in time interval [Ta, Tb] and has some flexibility on shifting in time interval [Ta, Tb] and has some flexibility on shifting
the time interval a little bit such as up to P seconds earlier/left the time interval a little bit, such as up to P seconds
or earlier/left or
some time such as up to Q seconds later/right.</t> some time such as up to Q seconds later/right.</t>
<t>When an LSP is configured with elastic time interval "[Ta, Tb] <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 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 the constraints for the LSP in the time period from (Ta+Xv) to
(Tb+Xv) and an optimization is performed on Xv from -P to Q. (Tb+Xv), and an optimization is performed on Xv from -P to Q.
The optimization makes The optimization makes
[Ta+Xv, Tb+Xv] to be the time interval closest to time interval [Ta+Xv, Tb+Xv] the time interval closest to time interval
[Ta, Tb] within the elastic range. The LSP along the path is set [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> 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, <t>Similarly, for a recurrent time interval with an elastic range,
elastic time interval: "[Ta, Tb] repeats n times with repeat cycle elastic time interval "[Ta, Tb] repeats n times with repeat cycle
C within -P and Q" represents n+1 simple elastic time intervals as C within -P and Q" represents n+1 simple elastic time intervals as
follows:<figure> follows:</t> <t indent="3"> [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1],
<artwork>[Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+ ..., [Ta+nC+Xn, Tb+nC+Xn], where -P &lt;= Xi &lt;= Q, i = 0, 1, 2,
nC+Xn] ..., n.</t>
where -P &lt;= Xi &lt;= Q, i = 0, 1, 2, ..., n. </artwork>
</figure></t>
<t>If a user wants to keep the same repeat cycle between any two <t>If a user wants to keep the same repeat cycle between any two
adjacent time intervals, elastic time interval: "[Ta, Tb] repeats adjacent time intervals, elastic time interval "[Ta, Tb] repeats n
n times with repeat cycle C within -P and Q SYNC" may be used, times with repeat cycle C within -P and Q SYNC" may be used, which
which represents n+1 simple elastic time intervals as represents n+1 simple elastic time intervals as follows:</t> <t
follows:<figure> indent="3"> [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X,
<artwork>[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.</t>
where -P &lt;= X &lt;= Q. </artwork>
</figure></t>
</section> </section>
<section numbered="true" toc="default">
<name>Grace Periods</name>
<section title="Grace Periods">
<t>Besides the stated time scheduling, a user may want to have <t>Besides the stated time scheduling, a user may want to have
some grace periods (short for graceful time periods) some grace periods (short for "graceful time periods") for each or
for each or some of the time intervals for some of the time intervals for the LSP. Two grace periods may be
the LSP. Two grace periods may be configured for a time configured for a time interval. One is the grace period before the
interval. One is the grace period before the time interval, time interval, called "Grace-Before", which extends the lifetime
called grace-before, which extends the lifetime of the LSP for of the LSP by an amount of time (such as 30 seconds)
grace-before (such as 30 seconds) before the time interval. The before the time interval. The other grace period is after the
other is the one after the time interval, called grace-after, time interval and is called "Grace-After"; it extends the lifetime
which extends the lifetime of the LSP for grace-after (such as 60 of the LSP by an amount of time (such as 60 seconds)
seconds) after the time interval. after the time interval. Note that no network resources such as
Note that no network resources such as link bandwidth will be link bandwidth will be reserved for the LSP during the grace
reserved for the LSP during the grace periods.</t> periods.</t>
<t>When an LSP is configured with a simple time interval such as <t>When an LSP is configured with a simple time interval such as
[Ta, Tb] with grace periods such as grace-before GB and [Ta, Tb] with grace periods such as Grace-Before GrB and
grace-after GA, a path is computed such that the path satisfies 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 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 LSP along the path is set up to carry traffic in the time period
from (Ta-GB) to (Tb+GA). During grace periods from (Ta-GB) to from (Ta-GrB) to (Tb+GrA).
Ta and from Tb to (Tb+GA), the LSP is up to carry traffic
in best effort.</t> During grace periods from (Ta-GrB) to Ta and from Tb to (Tb+GrA), the LSP is
up to carry traffic in best effort.</t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Scheduled LSP creation"> <name>Scheduled LSP Creation</name>
<t>In order to realize PCC-Initiated scheduled LSPs in a centralized <t>In order to realize PCC-initiated scheduled LSPs in a centralized
network environment, a PCC MUST separate the setup of an LSP into two network environment, a PCC <bcp14>MUST</bcp14> separate the setup of
steps. The first step is to request/delegate and get an LSP but not sign an LSP into two
al it 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 over the network. The second step is to signal the scheduled LSP over
the LSRs (Label Switching Router) at its starting time.</t> the Label Switching Routers (LSRs) at its start time.</t>
<t>For PCC-initiated scheduled LSPs, a PCC <bcp14>MUST</bcp14>
<t>For PCC-Initiated scheduled LSPs, a PCC MUST delegate the scheduled L delegate the scheduled LSP
SP by sending a PCRpt
by sending a path computation message by including its demanded
report (PCRpt) message by including its demanded
resources with the scheduling information to a stateful resources with the scheduling information to a stateful
PCE. Note the PCC MAY use the PCReq/PCRep with scheduling information be PCE. Note that the PCC <bcp14>MAY</bcp14> use Path Computation
fore delegating.</t> 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 <t>Upon receiving the delegation via PCRpt message, the stateful PCE
MUST compute a path for the scheduled LSP per its starting time and <bcp14>MUST</bcp14> compute a path for the scheduled LSP per its start
duration based on the network resource availability stored in time and
scheduled TED (see <xref target="LSPSchedulingOverview"/>).</t> duration based on the network resource availability stored in the
scheduled TED (see <xref target="LSPSchedulingOverview"
<!--<t>If a resultant path is found, the stateful PCE will send a PCRpt format="default"/>).</t>
message with the path information as well as the scheduled resource <t>The stateful PCE will send a Path Computation Update Request
information for the scheduled LSP to other PCEs within the network if (PCUpd)
there is any, so as to keep their scheduling information message with the scheduled path information and the scheduled resource
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>-->
<!-- <t>The stateful PCE will send a PCUpd
message with the scheduled path information as well as the scheduled res
ource
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 res
ource
information for the scheduled LSP to the PCC. information for the scheduled LSP to the PCC.
The stateful PCE MUST update its local scheduled LSP-DB and The stateful PCE <bcp14>MUST</bcp14> update its local scheduled LSP-DB
and
scheduled TED with the scheduled LSP and would need to synchronize the scheduled TED with the scheduled LSP and would need to synchronize the
scheduling information with other PCEs in the domain. </t> scheduling information with other PCEs in the domain. </t>
<t>For a PCE-initiated scheduled LSP, the stateful PCE
<t>For PCE-Initiated Scheduled LSP, the stateful PCE MUST compute a <bcp14>MUST</bcp14> automatically compute a path for the scheduled LSP
path for the scheduled LSP per requests from network management per requests from network management systems, based on the network
systems automatically based on the network resource availability in resource availability in the scheduled TED, and send an LSP Initiate
the scheduled TED and send a PCInitiate message with the Request (PCInitiate) message with the path information to the
path information back to the PCC. Based on the local policy, the PCIniti PCC. Based on the local policy, the PCInitiate message could be sent
ate message immediately to ask the PCC to create a scheduled LSP (as per this
could be sent immediately to ask the PCC to create a scheduled LSP (as p document), or the PCInitiate message could be sent at the start time
er this document) or the PCInitiate message to the PCC to create a normal LSP (as per <xref target="RFC8281"
could be sent at the start time to the PCC to create a normal LSP (as pe format="default"/>).
r <xref target="RFC8281"/>). </t>
</t> <t>For both PCC-initiated and PCE-initiated Scheduled LSPs:</t>
<ul spacing="normal">
<t>For both PCC-Initiated and PCE-Initiated Scheduled LSPs:<list style=" <li>The stateful PCE <bcp14>MUST</bcp14> update its local scheduled
symbols"> LSP-DB
<t>The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP.</li>
and scheduled TED with the scheduled LSP.</t> <li>Upon receiving the PCUpd message or PCInitiate message for the
scheduled
<t>Upon receiving the PCUpd message or PCInitiate message for the sc
heduled
LSP from PCEs with a found path, the PCC determines that it is a LSP from PCEs with a found path, the PCC determines that it is a
scheduled path for the LSP by the scheduled path for the LSP by the
SCHED-LSP-ATTRIBUTE TLV (see <xref target="SCHED-LSP-ATTRIBUTE"/>) o SCHED-LSP-ATTRIBUTE TLV (see <xref target="SCHED-LSP-ATTRIBUTE"
r format="default"/>) or
SCHED-PD-LSP-ATTRIBUTE TLV (see <xref target="SCHED-PD-LSP-ATTRIBUTE SCHED-PD-LSP-ATTRIBUTE TLV (see <xref
"/>) target="SCHED-PD-LSP-ATTRIBUTE" format="default"/>)
in the message, and in the message and
does not trigger signaling for the LSP does not trigger signaling for the LSP
setup on LSRs immediately.</t> setup on LSRs immediately.</li>
<li>The stateful PCE <bcp14>MUST</bcp14> update the scheduled LSP
<t>The stateful PCE MUST update the Scheduled LSP parameters on any network events using the PCUpd message to the
parameters on any network events using the PCUpd message to PCC. The PCC. These
se changes are also synchronized to other PCEs.</li>
changes are also synchronized to other PCEs.</t> <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
<t>When it is time for the LSP to be set up the
(i.e., at the start time), based on the value of the C flag for the
scheduled TLV, scheduled TLV,
either the PCC MUST trigger the LSP to be signaled or the delegated either the PCC <bcp14>MUST</bcp14> trigger the LSP to be signaled
PCE MUST send a PCUpd message to the head or the delegated
end LSR providing the updated path to be signaled PCE <bcp14>MUST</bcp14> send a PCUpd message to the head-end LSR
(with A flag set to indicate LSP activation).</t> providing the updated path to be signaled
</list></t> (with the A flag set to indicate LSP activation).</li>
</ul>
</section> </section>
<section title="Scheduled LSP Modifications" anchor="lsp-modify"> <section anchor="lsp-modify" numbered="true" toc="default">
<name>Scheduled LSP Modifications</name>
<t>After a scheduled LSP is configured, a user may change its <t>After a scheduled LSP is configured, a user may change its
parameters including the requested time as well as the bandwidth. parameters, including the requested time and the bandwidth.
For a periodic scheduled LSP, its unused recurrences can be modified For a periodic-scheduled LSP, its unused recurrences can be modified
or cancelled. or canceled.
For a scheduled LSP that is currently active, its duration (the lifetime For a scheduled LSP that is currently active, its duration (the
) lifetime)
can be reduced.</t> can be reduced.</t>
<t>In the PCC-initiated case, the PCC <bcp14>MUST</bcp14> send the PCE
a PCRpt message for the scheduled LSP with updated parameters, as well
as scheduled information included in the SCHED-LSP-ATTRIBUTE TLV (see
<xref target="SCHED-LSP-ATTRIBUTE" format="default"/>) or
SCHED-PD-LSP-ATTRIBUTE TLV (see <xref target="SCHED-PD-LSP-ATTRIBUTE"
format="default"/>) carried in the LSP object. The PCE
<bcp14>SHOULD</bcp14> take the updated resources and schedule into
consideration, and update the new path for the scheduled LSP to the
PCC, and synchronize to other PCEs in the network.
<t>In the PCC-Initiated case, the PCC MUST send the PCE a PCRpt message If the path cannot be set based on new requirements, the previous LSP will not
for the be impacted, and this <bcp14>MUST</bcp14> be conveyed by the use of an empty
scheduled LSP with updated parameters as well as scheduled information Explicit Route Object (ERO) in the PCEP messages.</t>
included in the SCHED-LSP-ATTRIBUTE TLV (see <xref target="SCHED-LSP-ATT <t>In the PCE-initiated case, the stateful PCE would recompute the
RIBUTE"/>) or path based on
SCHED-PD-LSP-ATTRIBUTE TLV (see <xref target="SCHED-PD-LSP-ATTRIBUTE"/>) updated parameters and scheduled information. If it has
carried in the LSP Object. The PCE SHOULD already conveyed this information to the PCC by sending a PCInitiate
take the updated resources and schedule into considerations and message, it <bcp14>SHOULD</bcp14> update the path and other
update the new path for the scheduled LSP to the PCC as well as scheduling and resource
synchronize to other PCEs in the network. In case path cannot be
set based on new requirements, the previous LSP will not be impacted
and the same MUST be conveyed by the
use of empty ERO in the PCEP messages.</t>
<t>In the PCE-Initiated case, the Stateful PCE would recompute the path
based on
updated parameters as well as scheduled information. In case it has
already conveyed to the PCC this information by sending a PCInitiate
message, it SHOULD update the path and other scheduling and resource
information by sending a PCUpd message.</t> information by sending a PCUpd message.</t>
<!-- original:
After a scheduled LSP is configured, a user may change its parameter
s
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>
<section numbered="true" toc="default">
<section title="Scheduled LSP activation and deletion"> <name>Scheduled LSP Activation and Deletion</name>
<t>In the PCC-Initiated case, <t>In the 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
when it is time for the LSP to be set up scheduled TLV, either the PCC <bcp14>MUST</bcp14> trigger the LSP to
(i.e., at the start time), based on the value of the C flag for the be signaled, or the delegated PCE <bcp14>MUST</bcp14> send a PCUpd
scheduled TLV, message to the head-end LSR providing the updated path to be signaled
either the PCC MUST trigger the LSP to be signaled or the delegated (with the A flag set to indicate LSP activation). The PCC
PCE <bcp14>MUST</bcp14> report the status of the active LSP as per the
MUST send a PCUpd message to the head procedures in <xref target="RFC8231" format="default"/>, and at this
end LSR providing the updated path to be signaled (with A flag set t time, the LSP <bcp14>MUST</bcp14> be considered part of the LSP-DB.
o The A flag <bcp14>MUST</bcp14> be set in the scheduled TLV to indicate
indicate LSP activation). that the LSP is active now. After the scheduled duration expires,
The PCC MUST report the status of the active LSP as per the based on the C flag, the PCC <bcp14>MUST</bcp14> trigger the LSP
procedures in <xref target="RFC8231"/> and at this time the LSP deletion on itself, or the delegated PCE <bcp14>MUST</bcp14> send a
MUST be considered as part of the LSP-DB. PCUpd message to the PCC to delete the LSP as per the procedures in
The A flag MUST be set in the scheduled TLV to indicate that the LSP <xref target="RFC8231" format="default"/>.
is </t>
active now. After the scheduled duration expires, based on the C fla <t>In the PCE-initiated case, based on the local policy, if the
g, scheduled LSP is
the PCC MUST trigger the already conveyed to the PCC at the time of creation, the handling
LSP deletion on itself or the delegated PCE MUST send a PCUpd messag of LSP
e activation and deletion is handled in the same way as the
to the PCC to delete the LSP as per the procedures in <xref target=" PCC-initiated case,
RFC8231"/>. as per the setting of the C flag. Otherwise, the PCE
</t> <bcp14>MUST</bcp14> send the PCInitiate message
to the PCC at the start time to create a normal LSP without the
<t>In the PCE-Initiated case, based on the local policy, if the schedu scheduled TLV
led LSP is and remove the LSP after the duration expires, as per <xref
already conveyed to the PCC at the time of creation, the handling o target="RFC8281" format="default"/>.</t>
f 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 PCIn
itiate message
at the start time to the PCC to create a normal LSP without the sch
eduled TLV
and remove the LSP after the duration expires as per <xref target="
RFC8281"/>.</t>
<!--
<t>Additionally, the scheduled databases SHALL be updated and synchr
onization to other PCEs MUST be done as per <xref target="I-D.litkowski-pce-stat
e-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, the PCE shall send a PCUpd
message with R flag set to the PCC to delete the LSP over the path, as
well as to other PCEs to remove the scheduled LSP in the databases.
Additionally, it shall update its scheduled LSP-DB and scheduled
TED.</t>
<t>Note that, the stateful PCE can update the Scheduled LSP parameters
at any time based on any network events using the PCUpd message
including SCHED-LSP-ATTRIBUTE TLV in the LSP Object body.</t>-->
</section> </section>
</section> </section>
<section title="PCEP Objects and TLVs">
<section title="Stateful PCE Capability TLV">
<t>A PCC and a PCE indicate their ability to support LSP scheduling du
ring
their PCEP session establishment phase. For a multiple-PCE
environment, the PCEs SHOULD also establish a PCEP session and
indicate its ability to support LSP scheduling among PCEP peers. The
Open Object in the Open message contains the STATEFUL-PCE-CAPABILITY
TLV. Note that the
STATEFUL-PCE-CAPABILITY TLV is defined in <xref target="RFC8231"/> and
updated in <xref target="RFC8281"/> and <xref target="RFC8232"/>".
In this document, we define a new
flag bit B (SCHED-LSP-CAPABLITY) in the Flags field of the
STATEFUL-PCE-CAPABILITY TLV to indicate the support of LSP scheduling
and
another flag bit PD (PD-LSP-CAPABLITY) to indicate the support of
LSP periodical scheduling.</t>
<t><list style="hanging"> <section numbered="true" toc="default">
<t hangText="B (LSP-SCHEDULING-CAPABILITY) - 1 bit [Bit Position - <name>PCEP Objects and TLVs</name>
TBD3]:">If set to 1 <section numbered="true" toc="default">
by a PCC, the B Flag indicates that the PCC allows LSP <name>Stateful PCE Capability TLV</name>
scheduling; if set to 1 by a PCE, the B Flag indicates that the <t>A PCC and a PCE indicate their ability to support LSP scheduling
PCE is capable of LSP scheduling. The B bit MUST be set by both during their PCEP session establishment phase. For an environment with
multiple PCEs, the PCEs <bcp14>SHOULD</bcp14> also establish a PCEP
session and indicate its ability to support LSP scheduling among PCEP
peers. The OPEN object in the Open message contains the
STATEFUL-PCE-CAPABILITY TLV. Note that the STATEFUL-PCE-CAPABILITY TLV
is defined in <xref target="RFC8231" format="default"/> and updated in
<xref target="RFC8281" format="default"/> and <xref target="RFC8232"
format="default"/>. In this document, we define a new flag bit B
(LSP-SCHEDULING-CAPABILITY) in the Flags field of the
STATEFUL-PCE-CAPABILITY TLV to indicate the support of LSP
scheduling. We also define another flag bit PD (PD-LSP-CAPABILITY) to
indicate the support of LSP periodical scheduling.</t>
<dl newline="false" spacing="normal">
<dt>B (LSP-SCHEDULING-CAPABILITY) - 1 bit (Bit Position 22):</dt>
<dd>If set to 1
by a PCC, the B flag indicates that the PCC allows LSP
scheduling; if set to 1 by a PCE, the B flag indicates that the
PCE is capable of LSP scheduling. The B bit <bcp14>MUST</bcp14>
be set by both
PCEP peers in order to support LSP scheduling for path PCEP peers in order to support LSP scheduling for path
computation.</t> computation.</dd>
<t hangText="PD (PD-LSP-CAPABLITY) - 1 bit: [Bit Position - TBD4]" <dt>PD (PD-LSP-CAPABILITY) - 1 bit (Bit Position - 21):</dt>
> <dd>
If set to 1 by a If set to 1 by a
PCC, the PD Flag indicates that the PCC allows LSP scheduling PCC, the PD flag indicates that the PCC allows LSP scheduling
periodically; if set to 1 by a PCE, the PD Flag indicates that periodically; if set to 1 by a PCE, the PD flag indicates that
the PCE is capable of periodical LSP scheduling. Both the PD bit a the PCE is capable of periodical LSP scheduling. Both the PD bit
nd and
the B bit the B bit
MUST <bcp14>MUST</bcp14>
be set to 1 by both PCEP peers in order to support periodical LSP be set to 1 by both PCEP peers in order to support periodical
LSP
scheduling for path computation. scheduling for path computation.
If the PD bit or B bit is 0, then If the PD bit or B bit is 0, then
the periodical LSP scheduling capability MUST be ignored.</t> the periodical LSP scheduling capability <bcp14>MUST</bcp14> be
</list></t> ignored.</dd>
</section> </dl>
<section title="LSP Object"> </section>
<t>The LSP object is defined in <xref target="RFC8231"/>. <section numbered="true" toc="default">
<name>LSP Object</name>
<t>The LSP object is defined in <xref target="RFC8231"
format="default"/>.
This document adds an This document adds an
optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an
optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP
scheduling. The LSP Object for a scheduled LSP MUST NOT include scheduling. The LSP object for a scheduled LSP <bcp14>MUST
NOT</bcp14> include
these two TLVs. Only one scheduling, either normal or periodical, these two TLVs. Only one scheduling, either normal or periodical,
is allowed for a scheduled LSP. </t> is allowed for a scheduled LSP. </t>
<t>The presence of the SCHED-LSP-ATTRIBUTE TLV in the LSP object
<t>The presence of the SCHED-LSP-ATTRIBUTE TLV in the LSP object
indicates that this LSP is normal scheduling while the indicates that this LSP is normal scheduling while the
SCHED-PD-LSP-ATTRIBUTE TLV indicates that this scheduled LSP is SCHED-PD-LSP-ATTRIBUTE TLV indicates that this scheduled LSP is
periodical. The SCHED-LSP-ATTRIBUTE TLV MUST be present in LSP periodical. The SCHED-LSP-ATTRIBUTE TLV <bcp14>MUST</bcp14> be
Object for each normal scheduled LSP carried in the PCEP messages. present in the LSP object for each normal-scheduled LSP carried in
The the PCEP messages. The
SCHED-PD-LSP-ATTRIBUTE TLV MUST be used in the LSP Object for each per SCHED-PD-LSP-ATTRIBUTE TLV <bcp14>MUST</bcp14> be used in the LSP
iodic object for each periodic-scheduled LSP carried in the PCEP
scheduled LSP carried in the PCEP messages.</t> messages.</t>
<t>Only one SCHED-LSP-ATTRIBUTE TLV <bcp14>SHOULD</bcp14> be present
<t>Only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP objec in the LSP object.
t. If more than one SCHED-LSP-ATTRIBUTE TLV is found,
In case more than one SCHED-LSP-ATTRIBUTE TLV is found,
the first instance is processed and others ignored. the first instance is processed and others ignored.
The SCHED-PD-LSP-ATTRIBUTE TLV is the same as the The SCHED-PD-LSP-ATTRIBUTE TLV is the same as the
SCHED-LSP-ATTRIBUTE TLV regarding to its presence in the LSP object SCHED-LSP-ATTRIBUTE TLV with regard to its presence in the LSP
.</t> object.</t>
<section anchor="SCHED-LSP-ATTRIBUTE" numbered="true" toc="default">
<section title="SCHED-LSP-ATTRIBUTE TLV" anchor="SCHED-LSP-ATTRIBUTE"> <name>SCHED-LSP-ATTRIBUTE TLV</name>
<t>The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV <t>The SCHED-LSP-ATTRIBUTE TLV <bcp14>MAY</bcp14> be included as an
optional TLV
within the LSP object for LSP scheduling for the requesting within the LSP object for LSP scheduling for the requesting
traffic service.</t> traffic service.</t>
<t>This TLV <bcp14>MUST NOT</bcp14> be included unless both PCEP
<t>This TLV MUST NOT be included unless both PCEP peers have set the peers have set the B
B (LSP-SCHEDULING-CAPABILITY) bit in the STATEFUL-PCE-CAPABILITY TLV
(LSP-SCHEDULING-CAPABILITY) bit in STATEFUL-PCE-CAPABILITY TLV
carried in the Open message to one. carried in the Open message to one.
If the TLV is received by a peer when both peers If the TLV is received by a peer when both peers
didn't set the B bit to one, the peer MUST generate didn't set the B bit to one, the peer <bcp14>MUST</bcp14> generate
a PCEP Error (PCErr) with a PCEP-ERROR object a PCEP Error (PCErr) with a PCEP-ERROR object
having Error-type = 19 (Invalid Operation) and having Error-Type = 19 (Invalid Operation) and
Error-value = TBD6 (Attempted LSP Scheduling if the scheduling Error-value = 15 (Attempted LSP scheduling while the scheduling
capability was not advertised).</t> capability was not advertised).</t>
<t>The format of the SCHED-LSP-ATTRIBUTE TLV is shown in <xref
target="sched-lsp-attr-tlv"/>.</t>
<t>The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1.</ <figure anchor="sched-lsp-attr-tlv">
t> <name>SCHED-LSP-ATTRIBUTE TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure anchor="sched-lsp-attr-tlv"
title="SCHED-LSP-ATTRIBUTE TLV">
<artwork>
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD1) | Length | | Type (49) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |R|C|A|G| Reserved (0) | | Flags |R|C|A|G| Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time | | Start-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration | | Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound | | GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> ]]></artwork>
</figure>
<t>The type of the TLV is [TBD1] and the TLV has a fixed length of <t>The type of the TLV is 49, and the TLV has a fixed length of
16 octets.</t> 16 octets.</t>
<t>The fields in the format are:</t>
<t>The fields in the format are:<list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Flags (8 bits):">The following flags are <dt>Flags (8 bits):</dt>
defined in this document <dd>
<list style="hanging"> <t>The following flags are defined in this document.
<t hangText="R (1 bit):"> </t>
Set to 1 to indicate the <dl newline="false" spacing="normal">
Start-Time is a relative time, which is the number of seconds fr <dt>R (1 bit):</dt>
om the <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. current time.
The PCEs and PCCs MUST synchronized their clocks The PCEs and PCCs <bcp14>MUST</bcp14> synchronize their clocks
when relative time is used. when relative time is used.
It is RECOMMENDED that the Network Time Protocol It is <bcp14>RECOMMENDED</bcp14> that the Network Time
<xref target="RFC5905"/> Protocol
<xref target="RFC5905" format="default"/>
be used to synchronize clocks among them. be used to synchronize clocks among them.
When the transmission delay from a PCE or PCC to another PCE or When the transmission delay from a PCE or PCC to another PCE
PCC or PCC
is too big such as greater than 1 second, the scheduling interva is too big (such as greater than 1 second), the scheduling
l interval
represented is not accurate if the delay is not considered. represented is not accurate if the delay is not considered.
Set to 0 to indicate that the 32-bit Start-Time is an Set to 0 to indicate that the 32-bit Start-Time is an
absolute time, which is the number of seconds since the epoch. absolute time, which is the number of seconds since the epoch.
The epoch is 1 January 1970 at 00:00 UTC. The epoch is 1 January 1970 at 00:00 UTC.
It wraps around every 2^32 seconds, which is roughly It wraps around every 2^32 seconds, which is roughly
136 years. The next wraparound will occur in the year 2106. 136 years. The next wraparound will occur in the year 2106.
The received Start-Time is considered after the The received Start-Time is considered after the
wraparound if the resulting value is less than the current time. wraparound if the resulting value is less than the current time.
In which case, the value of the 32-bit Start-Time is considered In that case, the value of the 32-bit Start-Time is considered
as the number of seconds from the time of wraparound (because to be the number of seconds from the time of wraparound (because
the Start-Time is always a future time). the Start-Time is always a future time).
</t>
<t/>
</dd>
<dt>C (1 bit):</dt>
<dd>
<t>Set to 1 to indicate that the
PCC is responsible to set up and remove the scheduled LSP
based on the
Start-Time and Duration.
The PCE holds these responsibilities when the bit is set to
zero.
</t>
<t/>
</dd>
<dt>A (1 bit):</dt>
<dd>
<!-- <t>Set to 1 to indicate that the
After the wraparound, the value of the 32-bit Start-Time is scheduled LSP has been activated. </t>
the number of seconds from the time of wraparound because <t/>
the Start-Time is always a future time. </dd>
Before the wraparound and <dt>G (1 bit):</dt>
within a constant RANGE-START-TIME to reach the wraparound, <dd>
if the time at which the LSP is to be <t>Set to 1 to indicate that the
activated is after the wraparound, the time is represented by grace period is included in the fields
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 the range of start time limit RANGE-START-TIME,
it represents the time before the wraparound,
where MAX-AWAY-TIME = 100 seconds,
RANGE-START-TIME = 2*365*86400 seconds.
<vspace blankLines="1"/></t>
<t hangText="C (1 bit):">Set to 1 to indicate the
PCC is responsible to setup and remove the scheduled LSP based o
n the
Start-Time and duration.
The PCE holds these responsibilities when the bit is set to zero
.
<vspace blankLines="1"/></t>
<t hangText="A (1 bit):">Set to 1 to indicate the
scheduled LSP has been activated and should be considered
as part of LSP-DB (instead of Scheduled LSP-DB). <vspace blankLi
nes="1"/></t>
<t hangText="G (1 bit):">Set to 1 to indicate the
Grace period is included in the fields
GrB/Elastic-Lower-Bound and GrA/Elastic-Upper-Bound; GrB/Elastic-Lower-Bound and GrA/Elastic-Upper-Bound;
set to 0 indicate the elastic range is included in the fields. set to 0 to indicate that the elastic range is included in the
<vspace blankLines="1"/></t> fields.
</t>
</list></t> <t/>
</dd>
<t hangText="Reserved (24 bits):">This field MUST be set to </dl>
zero on transmission and MUST be ignored on receipt. <vspace </dd>
blankLines="1"/></t> <dt>Reserved (24 bits):</dt>
<dd>
<t hangText="Start-Time (32 bits):">This value in seconds, <t>This field <bcp14>MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on
receipt. </t>
<t/>
</dd>
<dt>Start-Time (32 bits):</dt>
<dd>
<t>This value, in seconds,
indicates when the scheduled LSP is used to carry traffic and indicates when the scheduled LSP is used to carry traffic and
the corresponding LSP MUST be setup and activated. the corresponding LSP <bcp14>MUST</bcp14> be set up and
activated.
Note that the transmission delay SHOULD be considered when R=1 Note that the transmission delay <bcp14>SHOULD</bcp14> be
considered when R=1
and the value of Start-Time is small. and the value of Start-Time is small.
<vspace blankLines="1"/></t> </t>
<t/>
<t hangText="Duration (32 bits):">The value in seconds, </dd>
indicates the duration that the LSP is undertaken by a traffic <dt>Duration (32 bits):</dt>
flow and the corresponding LSP MUST be up to carry traffic. At <dd>
the expiry of this duration, the LSP MUST be torn down and delet
ed.
Value of 0 MUST NOT be used in Duration since it does not make
any sense.
The value of Duration SHOULD be greater than a constant
MINIMUM-DURATION seconds, where MINIMUM-DURATION is 5.
<vspace blankLines="1"/></t>
</list></t>
<t>The Start-Time indicates a time
at or before which the scheduled LSP MUST be set up. The
value of the Start-Time represents the number of seconds since
the epoch when R bit is set to 0.
When R bit is
set to 1, the value of the Start-Time represents the number of
seconds from the current
time.</t>
<t>In addition, it contains G flag set to 1 and a non zero grace-bef
ore and
grace-after in the fields GrB/Elastic-Lower-Bound and GrA/Elastic-Up
per-Bound
if grace periods are configured.
It includes G flag set to 0 and a non
zero elastic range lower bound and upper bound in the fields if ther
e is an
elastic range configured.
A TLV can configure a non-zero grace period or elastic range,
but it MUST NOT provide both for an LSP.
<list style="symbols">
<t>GrB (Grace-Before -16 bits): The grace period time
length in seconds before the starting time.</t>
<t>GrA (Grace-After -16 bits): The grace period time length
in seconds after time interval [starting time, starting time +
duration].</t>
<t>Elastic-Lower-Bound (16 bits): The maximum amount of time <t>This value, in seconds, indicates the duration that the LSP
in seconds that time interval can shift to lower/left.</t> carries a traffic flow and the corresponding LSP
<bcp14>MUST</bcp14> be up to carry traffic. At the expiry of
this duration, the LSP <bcp14>MUST</bcp14> be torn down and
deleted. A value of 0 <bcp14>MUST NOT</bcp14> be used in Duration
since it does not make any sense. The value of Duration
<bcp14>SHOULD</bcp14> be greater than a constant
MINIMUM-DURATION seconds, where MINIMUM-DURATION is 5.
</t>
<t/>
</dd>
</dl>
<t>Start-Time indicates a time at or before which the scheduled LSP
<bcp14>MUST</bcp14> be set up. When the R bit is set to 0, the value
of Start-Time represents the number of seconds since the epoch.
When the R bit is set to 1, the value of Start-Time represents the
number of seconds from the current time.</t>
<t>Elastic-Upper-Bound (16 bits): The maximum amount of time <t>In addition, the SCHED-LSP-ATTRIBUTE TLV contains the G flag set
in seconds that time interval can shift to upper/right.</t> to 1 and a nonzero Grace-Before and Grace-After in the fields
</list></t> GrB/Elastic-Lower-Bound and GrA/Elastic-Upper-Bound if grace periods
</section> are configured. It includes the G flag set to 0 and a nonzero
elastic range lower bound and upper bound in the fields if there is
an elastic range configured. A TLV can configure a nonzero grace
period or elastic range, but it <bcp14>MUST NOT</bcp14> provide both
for an LSP.
</t>
<dl>
<section title="SCHED-PD-LSP-ATTRIBUTE TLV" anchor="SCHED-PD-LSP-ATTRI <dt>GrB (Grace-Before, 16 bits):</dt><dd>The grace period time
BUTE"> length, in seconds, before the start time.</dd>
<t>The periodical LSP is a special case of LSP scheduling. The <dt>GrA (Grace-After, 16 bits):</dt><dd>The grace period time
length,
in seconds, after time interval [start time, start time +
duration].</dd>
<dt>Elastic-Lower-Bound (16 bits):</dt><dd>The maximum amount of
time,
in seconds, that the time interval can shift lower/left.</dd>
<dt>Elastic-Upper-Bound (16 bits):</dt><dd>The maximum amount of
time,
in seconds, that the time interval can shift
higher/right.</dd>
</dl>
</section>
<section 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. traffic service happens in a series of repeated time intervals.
The SCHED-PD-LSP-ATTRIBUTE TLV can be included as an optional TLV The SCHED-PD-LSP-ATTRIBUTE TLV can be included as an optional TLV
within the LSP object for this periodical LSP scheduling.</t> within the LSP object for this periodical LSP scheduling.</t>
<t>This TLV MUST NOT be included unless both PCEP peers have set the <t>This TLV <bcp14>MUST NOT</bcp14> be included unless both PCEP
B peers have set the B
(LSP-SCHEDULING-CAPABILITY) bit and PD (PD-LSP-CAPABLITY) bit in (LSP-SCHEDULING-CAPABILITY) bit and PD (PD-LSP-CAPABILITY) bit in
STATEFUL-PCE-CAPABILITY TLV carried in open message to one. STATEFUL-PCE-CAPABILITY TLV carried in Open message to one.
If the TLV is received by a peer when either (or both) bit is zero, If the TLV is received by a peer when either bit is zero (or both
the peer MUST generate bits are zero), the peer <bcp14>MUST</bcp14> generate
a PCEP Error (PCErr) with a PCEP-ERROR object a PCEP Error (PCErr) with a PCEP-ERROR object
having Error-type = 19 (Invalid Operation) and having Error-Type = 19 (Invalid Operation) and
Error-value = TBD6 ( Attempted LSP Scheduling if the scheduling Error-value = 15 (Attempted LSP scheduling while the
scheduling
capability was not advertised).</t> capability was not advertised).</t>
<t>The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in <xref
target="sched-pd-lsp-attr-tlv"/>.
</t>
<t>The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2 <figure anchor="sched-pd-lsp-attr-tlv">
. <name>SCHED-PD-LSP-ATTRIBUTE TLV</name>
<figure anchor="sched-pd-lsp-attr-tlv" <artwork name="" type="" align="left" alt=""><![CDATA[
title="SCHED-PD-LSP-ATTRIBUTE TLV">
<artwork>
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD2) | Length | | Type (50) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags|R|C|A|G| Opt | NR | Reserved (0) | | Flags|R|C|A|G| Opt | NR | Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time | | Start-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration | | Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repeat-time-length | | Repeat-time-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound | | GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure></t> </figure>
<t>The type of the TLV is [TBD2] and the TLV has a fixed length of
20 octets. The description, format and meaning of the Flags (R, C, A
and G bit),
Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and Elastic-Uppe
r-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 the the Start-Time is an
absolute time.</t>-->
<t hangText="Opt: (4 bits)">Indicates options to repeat. <t>The type of the TLV is 50, and the TLV has a fixed length of 20
When a PCE receives a TLV with a unknown Opt value, octets. The description, format, and meaning of the flags (R, C, A,
and G bits), 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:</t>
<dl newline="false" spacing="normal">
<dt>Opt (4 bits):</dt>
<dd>
<t>Indicates options to repeat.
When a PCE receives a TLV with an unknown Opt value,
it does not compute any path for the LSP. it does not compute any path for the LSP.
It MUST generate a PCEP Error (PCErr) with a PCEP-ERROR object It <bcp14>MUST</bcp14> generate a PCEP Error (PCErr) with a
having Error-type = 4 (Not supported object) and PCEP-ERROR object
having Error-Type = 4 (Not supported object) and
Error-value = 4 (Unsupported parameter). Error-value = 4 (Unsupported parameter).
<list> </t>
<t>Opt = 1: repeat every month;</t> <dl newline="false" spacing="normal">
<t>Opt = 2: repeat every year;</t> <dt/>
<t>Opt = 3: repeat every Repeat-time-length.</t> <dd>Opt = 1: repeat every month</dd>
</list> <dt/>
<dd>Opt = 2: repeat every year</dd>
<dt/>
<dd>Opt = 3: repeat every Repeat-time-length</dd>
</dl>
<t>
A user may configure a Repeat-time-length in time units A user may configure a Repeat-time-length in time units
weeks, days, hours, minutes, and/or seconds. weeks, days, hours, minutes, and/or seconds.
The value represented by these units The value represented by these units
is converted to the number of seconds in the TLV. is converted to the number of seconds in the TLV.
For example, repeat every 2 weeks is equivalent to repeat every For example, repeat every 2 weeks is equivalent to repeat
every
Repeat-time-length = 2*7*86,400 (seconds), where 86,400 is the Repeat-time-length = 2*7*86,400 (seconds), where 86,400 is the
number of seconds per day. </t> number of seconds per day. </t>
</dd>
<dt>NR (12 bits):</dt>
<dd>The number of repeats.
During each repetition, LSP carries traffic. </dd>
<dt>Reserved (8 bits):</dt>
<dd>
<t>This field <bcp14>MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on
receipt. </t>
<t hangText="NR: (12 bits)">The number of repeats. </dd>
During each repetition, LSP carries traffic. </t> <dt>Repeat-time-length (32 bits):</dt>
<dd>The time in
<t hangText="Reserved (8 bits):">This field MUST be set to seconds between the Start-Time of one repetition and
zero on transmission and MUST be ignored on receipt. <vspace the Start-Time of the next repetition.
blankLines="1"/></t> </dd>
</dl>
<t hangText="Repeat-time-length: (32 bits)">The time in
seconds between the start-time of one repetition and
the start-time of the next repetition.
</t></list></t>
</section>
</section> </section>
</section> </section>
</section>
<section title="The PCEP Messages"> <section numbered="true" toc="default" anchor="pcep-msgs">
<section title="The PCRpt Message"> <name>The PCEP Messages</name>
<t>Path Computation State Report (PCRpt) is a PCEP message sent by a PCC <section numbered="true" toc="default">
to a PCE to report the status of one or more LSPs as per <xref target="RFC <name>The PCRpt Message</name>
8231"/>. Each LSP State <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, as per <xref
target="RFC8231" format="default"/>. Each LSP State
Report in a PCRpt message contains the actual LSP's path, Report in a PCRpt message contains the actual LSP's path,
bandwidth, operational and administrative status, etc. An LSP bandwidth, operational and administrative status, etc. An LSP
Status Report carried on a PCRpt message is also used in Status Report carried in a PCRpt message is also used in
delegation or revocation of control of an LSP to/from a PCE. In case of delegation or revocation of control of an LSP to/from a PCE. In the
scheduled LSP, a scheduled TLV MUST be carried in the LSP case of a scheduled LSP, a scheduled TLV <bcp14>MUST</bcp14> be carried
object and the ERO conveys the intended path for the scheduled LSP. The sc in the LSP
heduled LSP object, and the ERO conveys the intended path for the scheduled LSP. The
MUST be delegated to a PCE.</t> scheduled LSP
</section> <bcp14>MUST</bcp14> be delegated to a PCE.</t>
<section title="The PCUpd Message"> </section>
<t>Path Computation Update Request (PCUpd) is a PCEP message sent by a <section numbered="true" toc="default">
PCE to a PCC to update LSP parameters, on one or more LSPs as per <xref ta <name>The PCUpd Message</name>
rget="RFC8231"/>. Each <t>The Path Computation Update Request (PCUpd) message is a PCEP
LSP Update Request on a PCUpd message contains all LSP message sent by a
parameters that a PCE wishes to be set for a given LSP. In case of PCE to a PCC to update LSP parameters on one or more LSPs, as per <xref
scheduled LSP, a scheduled TLV MUST be carried in the LSP target="RFC8231" format="default"/>. Each
object and the ERO conveys the intended path for the scheduled LSP. In cas LSP Update Request in a PCUpd message contains all LSP
e parameters that a PCE wishes to be set for a given LSP. In the case of a
no path can be found, an empty ERO is used. The A bit is used in PCUpd mes scheduled LSP, a scheduled TLV <bcp14>MUST</bcp14> be carried in the LSP
sage to indicate the activation of the scheduled LSP in object, and the ERO conveys the intended path for the scheduled LSP. If
case the PCE is responsible for the activation (as per the C bit). no path can be found, an empty ERO is used. The A bit is used in the
<!-- Note that in the PCE-initiated case the PCE could send the PCInitiate PCUpd
message message to indicate the activation of the scheduled LSP if the PCE is
at the start time to the PCC to create a normal LSP without the scheduled responsible for the activation (as per the C bit).
TLV </t>
and remove the LSP after the duration expires as per <xref target="RFC8281 </section>
"/>. --> <section numbered="true" toc="default">
</t> <name>The PCInitiate Message</name>
<!-- <t>The LSP Initiate Request (PCInitiate) message is a PCEP message
This message is also sent
used to synchronize the scheduled LSPs to other PCE as described in <xref by a PCE to a PCC to trigger LSP instantiation or deletion, as per
target="I-D.litkowski-pce-state-sync"/>.</t> <xref target="RFC8281" format="default"/>.
<!--<t>To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL In the case of a scheduled LSP, based on the local policy, the PCE
compute the path for the scheduled LSP based on network resource <bcp14>MAY</bcp14> convey the scheduled LSP to the PCC by
availability recorded in scheduled TED which is generated from the including
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 PCUpd Message including the SCHED-
LSP-ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV in the LSP Object
body to the PCC. Note that, the stateful PCE can update the Scheduled
LSP parameters later as well based on any network events using the
same PCUpd message.</t>
<t>If conflicts happen or no path available is found, the requesting
PCE SHALL return a PCUpd message with empty ERO as described in <xref
target="RFC8231"/>.</t>-->
<!-- removed by dhruv, as this is incorrect
<t>If no path is found, the stateful PCE sends a PCUpd message with
the NO Path Object. The definition of the PCUpd message to carry LSP
objects(see <xref target="RFC8231"/>) is unchanged. </t> -->
</section>
<section title="The PCInitiate Message">
<t>An LSP Initiate Request (PCInitiate) message is a PCEP message sent
by a PCE to a PCC to trigger LSP instantiation or deletion as per <xre
f target="RFC8281"/>.
In case of scheduled LSP, based on the local policy, PCE MAY convey th
e scheduled LSP to the PCC by including
a scheduled TLV in the LSP object. Or the PCE would initiate the LSP o
nly at the start time of the
scheduled LSP as per the <xref target="RFC8281"/> without the use of s
cheduled TLVs.</t>
</section> a scheduled TLV in the LSP object. Alternatively, the PCE would
<section title="The PCReq message"> initiate the LSP only at the start time of the
<t>The Path Computation Request (PCReq) message is a PCEP message sent scheduled LSP, as per <xref target="RFC8281" format="default"/>,
by a PCC to a PCE to request a path computation <xref target="RFC544 without the use of scheduled TLVs.</t>
0"/> and it may </section>
contain the LSP object <xref target="RFC8231"/> to identify the LSP <section numbered="true" toc="default">
for which the path <name>The PCReq message</name>
computation is requested. In case of scheduled LSP, a scheduled TLV <t>The Path Computation Request (PCReq) message is a PCEP message sent
MUST be carried in the LSP object in PCReq message to request the by a PCC to a PCE to request a path computation <xref
path computation based on scheduled TED and LSP-DB. A PCC MAY use target="RFC5440" format="default"/>, and it may
contain the LSP object <xref target="RFC8231" format="default"/>
to identify the LSP for which the path
computation is requested. In the case of a scheduled LSP, a
scheduled TLV
<bcp14>MUST</bcp14> be carried in the LSP object in the PCReq
message to request the
path computation based on the scheduled TED and LSP-DB. A PCC
<bcp14>MAY</bcp14> use the
PCReq message to obtain the scheduled path before delegating the PCReq message to obtain the scheduled path before delegating the
LSP. The parameters of the LSP may be changed LSP. The parameters of the LSP may be changed
(refer to <xref target="lsp-modify"/>).</t> (refer to <xref target="lsp-modify" format="default"/>).</t>
</section>
<!--<t>After scheduled LSP capability negotiation, for PCC-Initiated <section numbered="true" toc="default">
mode, a PCC can send a PCReq message including the <name>The PCRep Message</name>
SCHED-LSP-ATTRIBUTE TLV (see section 4.3.4.1) or <t>The Path Computation Reply (PCRep) message is a PCEP message sent
SCHED-PD-LSP-ATTRIBUTE TLV (see section 4.3.4.2) carried in the LSP by a PCE to a PCC in reply to a path
Object (see section 4.3.4) body to indicate the requested LSP computation request <xref target="RFC5440" format="default"/>, and it
scheduling parameters for a customer's traffic service with the may
delegation bit set to 1 in the LSP Object. The value of requested contain the LSP object <xref target="RFC8231" format="default"/>
bandwidth is taken via the existing 'Requested Bandwidth with to identify the LSP for which the path
BANDWIDTH Object-Type as 1' defined 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 in the environment by sending a PCRpt message with the
SCHED-LSP-ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV, as well as
the Bandwith Object and RRO for the found path.</t>
<t>The definition of the PCReq message and PCRpt message to carry
LSP objects (see [I-D.ietf-pce-stateful-pce]) remains
unchanged.</t>-->
</section>
<section title="The PCRep Message">
<t>The Path Computation Reply (PCRep) message is a PCEP message sent b
y a PCE to a PCC in reply to a path
computation request <xref target="RFC5440"/> and it may
contain the LSP object <xref target="RFC8231"/> to identify the LSP
for which the path
is computed. A PCRep message can contain either a set of is computed. A PCRep message can contain either a set of
computed paths if the request can be satisfied, or a negative computed paths if the request can be satisfied or a negative
reply if not. The negative reply may indicate the reason why no reply if not. A negative reply may indicate the reason why no
path could be found. In case of scheduled LSP, a scheduled TLV 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 <bcp14>MUST</bcp14> be carried in the LSP object in PCRep message
path computation based on scheduled TED and LSP-DB. A PCC and PCE MA to indicate the
Y use path computation based on the scheduled TED and LSP-DB. A PCC and
PCReq and PCRep message to obtain the scheduled path before delegati PCE <bcp14>MAY</bcp14> use
ng the PCReq and PCRep messages to obtain the scheduled path before
delegating the
LSP.</t> LSP.</t>
<!--<t>To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL </section>
compute the path for the scheduled LSP carried on PCReq message <section numbered="true" toc="default">
based on network resource availability recorded in scheduled TED <name>The PCErr Message</name>
which is generated from the scheduled LSP-DB and TED and also <t>The PCEP Error (PCErr) message is a PCEP message, as described in
synchronize the scheduling with other PCEs in the environment by <xref target="RFC5440" format="default"/>, for error reporting. This
using PCRpt message with path and resource information for the document defines new error values for several error types to cover
scheduled LSP.</t> failures specific to scheduling and reuses the applicable error types
and error values of <xref target="RFC5440" format="default"/> and
<t>If no conflict exists, other PCEs SHALL update their scheduled <xref target="RFC8231" format="default"/> wherever appropriate.</t>
LSP-DBs and scheduled TED.</t> <t>The PCEP extensions for scheduling <bcp14>MUST NOT</bcp14> be used
if one or both of the PCEP speakers have not set the corresponding
<t>If the LSP request can be satisfied and an available path is bits in the STATEFUL-PCE-CAPABILITY TLV in their respective Open
found, the stateful PCE SHALL send a PCRep Message including the messages to one. If the PCEP speaker supports the extensions of this
SCHED-LSP-ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV in the LSP specification but did not advertise this capability, then upon receipt
Object body, as well as the Bandwith Object and RRO for the found of LSP object with the scheduled TLV, it <bcp14>MUST</bcp14> generate
path back to the PCC as a successful acknowledge.</t> a PCEP Error (PCErr) with Error-Type = 19 (Invalid
<t>If conflicts happen or no path available is found, the requesting Operation) and Error-value = 15 (Attempted LSP scheduling while the
PCE SHALL return a PCRep message with NO PATH back to the PCC.</t>-->
</section>
<section title="The PCErr Message">
<t>The Path Computation Error (PCErr) message is a PCEP message as des
cribed in <xref target="RFC5440"/> for error reporting. The current document def
ines new error values
for several error types to cover failures specific to scheduling and reuse th
e applicable error types and error values of <xref target="RFC5440"/> and <xref
target="RFC8231"/>
wherever appropriate.</t>
<t>The PCEP extensions for scheduling MUST NOT be used if one or both
PCEP speakers have not set the corresponding bits in the STATEFUL-PCE-CAPABIL
ITY TLV in
their respective OPEN message to ones. 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 generate a PCEP Error (PCErr) with Error-type=19 (Invalid
Operation) and error-value TBD6 (Attempted LSP Scheduling if the
scheduling capability was not advertised), and it scheduling capability was not advertised), and it
SHOULD ignore the TLV. As per Section 7.1 of <xref target="RFC5440"/>, <bcp14>SHOULD</bcp14> ignore the TLV. As per <xref
a legacy PCEP implementation that does not understand this specification, target="RFC5440" sectionFormat="of" section="7.1"/>,
would consider a scheduled TLV as unknown and ignore them.</t> a legacy PCEP implementation that does not understand this specification
<t>If the PCC would consider a scheduled TLV unknown and ignore it.</t>
decides that the scheduling parameters proposed in the PCUpd/PCInitiate messa <t>If the PCC
ge are decides that the scheduling parameters proposed in the PCUpd/PCInitiate
unacceptable, it MUST report this error by including the message are
LSP-ERROR-CODE TLV (Section 7.3.3 of <xref target="RFC8231"/>) unacceptable, it <bcp14>MUST</bcp14> report this error by including the
with LSP error-value = 4 "Unacceptable parameters" in the LSP object LSP-ERROR-CODE TLV (<xref target="RFC8231"
sectionFormat="of" section="7.3.3"/>)
with LSP Error-value = 4 (Unacceptable parameters) in the LSP object
(with the scheduled TLV) in the PCRpt message to the PCE.</t> (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 LSP <t>The scheduled TLV <bcp14>MUST</bcp14> be included in the LSP object
s, for the scheduled LSPs.
if the TLV is If the TLV is missing, the receiving PCEP speaker <bcp14>MUST</bcp14>
missing, the receiving PCEP speaker MUST send a PCErr message with send a PCErr message with Error-Type = 6 (Mandatory Object missing)
Error-type=6 (Mandatory Object missing) and Error-value TBD5 (Scheduled TLV and
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 secti
on 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 and worki
ng
groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups
to use this information as they see fit".</t>
<t>At the time of posting the -09 version of this document, there are no known
implementations of this mechanism. It is believed that two vendors/organiz
ations are
considering prototype implementations, but these plans are too vague to
make any further assertions.</t>
</section>
<section title="Security Considerations"> Error-value = 16 (Scheduled TLV missing).</t>
<t>This document defines LSP-SCHEDULING-CAPABILITY TLV and </section>
SCHED-LSP-ATTRIBUTE TLV, the security considerations </section>
discussed in <xref target="RFC5440"/>, <xref target="RFC8231"/>, and <xref <section numbered="true" toc="default">
target="RFC8281"/> continue to apply. In some deployments <name>Security Considerations</name>
<t>This document defines the LSP-SCHEDULING-CAPABILITY TLV and
SCHED-LSP-ATTRIBUTE TLV; the security considerations
discussed in <xref target="RFC5440" format="default"/>, <xref
target="RFC8231" format="default"/>, and <xref target="RFC8281"
format="default"/> continue to apply. In some deployments,
the scheduling information could provide details about the network the scheduling information could provide details about the network
operations that could be deemed as extra sensitive. operations that could be deemed extra sensitive.
Additionally, snooping of PCEP messages Additionally, snooping of PCEP messages
with such data or using PCEP messages for network reconnaissance may with such data or using PCEP messages for network reconnaissance may
give an attacker sensitive information about the operations of the give an attacker sensitive information about the operations of the
network. network.
A single PCEP message can now instruct a PCC to set up and tear down 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 an LSP every second for a number of times. That single message could
have a significant effect on the network. have a significant effect on the network.
Thus, such deployments SHOULD employ suitable PCEP security mechanisms Thus, such deployments <bcp14>SHOULD</bcp14> employ suitable PCEP security
like TCP Authentication Option (TCP-AO) <xref target="RFC5925"/> or mechanisms
<xref target="RFC8253"/>, which like TCP Authentication Option (TCP-AO), which is discussed in <xref
<xref target="RFC8253"/> is considered a security enhancement and thus is muc target="RFC5925" format="default"/> and
h better <xref target="RFC8253" format="default"/>. Note that
suited for the sensitive information. <xref target="RFC8253" format="default"/> is considered a security
enhancement and thus is much better
suited for sensitive information.
PCCs may also need to apply some form of rate limit to the processing of PCCs may also need to apply some form of rate limit to the processing of
scheduled LSPs.</t> scheduled LSPs.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Manageability Consideration"> <name>Manageability Consideration</name>
<section title="Control of Function and Policy"> <section numbered="true" toc="default">
<t>The LSP-Scheduling feature MUST be controlled per tunnel by the <name>Control of Function and Policy</name>
active stateful PCE, the values for parameters like starting time, <t>The LSP scheduling feature <bcp14>MUST</bcp14> be controlled per
duration SHOULD be configurable by customer applications and based on tunnel by the
active stateful PCE. The values for parameters like start time and
duration <bcp14>SHOULD</bcp14> be configurable by customer
applications and based on
the local policy at PCE. the local policy at PCE.
The suggested default values for starting time and duration are The suggested default values for start time and duration are
one day in seconds from the current time and one year in seconds one day (in seconds) from the current time and one year (in seconds),
respectively. respectively.
One day has 86,400 seconds. One year has 31,536,000 seconds.</t> One day has 86,400 seconds. One year has 31,536,000 seconds.</t>
<t>When configuring the parameters for time, a user
<t>When configuring the parameters about time, a user SHOULD <bcp14>SHOULD</bcp14>
consider leap-years and leap-seconds. consider leap years and leap seconds.
If a scheduled LSP has a time interval containing a leap-year, If a scheduled LSP has a time interval containing a leap year,
the duration of the LSP is 366 days plus the rest of the interval.</t> the duration of the LSP is 366 days plus the rest of the interval.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Information and Data Models"> <name>Information and Data Models</name>
<t> An implementation SHOULD allow the operator to view the information <t> An implementation <bcp14>SHOULD</bcp14> allow the operator to view
the information
about each scheduled LSP about each scheduled LSP
defined in this document. To serve this purpose, the PCEP YANG defined in this document. To serve this purpose, the PCEP YANG
module <xref target="I-D.ietf-pce-pcep-yang"/> could be extended.</t> module <xref target="I-D.ietf-pce-pcep-yang" format="default"/> could be
extended.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Liveness Detection and Monitoring"> <name>Liveness Detection and Monitoring</name>
<t>Mechanisms defined in this document do not imply any new liveness <t>Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in <xref target="RFC5440"/>. listed in <xref target="RFC5440" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>Verify Correct 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" format="default"/>.
<section title="Verify Correct Operations"> An implementation <bcp14>SHOULD</bcp14> allow a user to view
<t>Mechanisms defined in this document do not imply any new operation information, including the status of a scheduled LSP, through a
verification requirements in addition to those already listed in Command Line Interface (CLI) tool. In addition, it <bcp14>SHOULD</bcp14
<xref target="RFC5440"/>. >
An implementation SHOULD allow a user to view the information check and handle the cases where there is a significant time
including status about a scheduled LSP correction or a clock skew between PCC and PCE.
through CLI.
In addition, it SHOULD check and handle the cases where
there is a significant time correction or
a clock skew between PCC and PCE.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requirements On Other Protocols"> <name>Requirements on Other Protocols</name>
<t>Mechanisms defined in this document do not imply any new <t>Mechanisms defined in this document do not imply any new
requirements on other protocols.</t> requirements on other protocols.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Impact On Network Operations"> <name>Impact on Network Operations</name>
<t>Mechanisms defined in this document do not have any impact on <t>Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in network operations in addition to those already listed in
<xref target="RFC5440"/>.</t> <xref target="RFC5440" format="default"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<section title="PCEP TLV Type Indicators"> <name>PCEP TLV Type Indicators</name>
<t>This document defines the following new PCEP TLVs. IANA <t>IANA maintains the "PCEP TLV Type Indicators" subregistry within the
maintains a sub-registry "PCEP TLV Type Indicators" in the "Path
"Path Computation Element Protocol (PCEP) Numbers" registry. IANA is req Computation Element Protocol (PCEP) Numbers" registry. IANA has made the
uested following allocations in this subregistry for the new PCEP TLVs defined in
to make the following allocations from this sub-registry. <figure> this document. </t>
<artwork>Value Meaning Reference
TBD1 SCHED-LSP-ATTRIBUTE This document
TBD2 SCHED-PD-LSP-ATTRIBUTE This document</artwork>
</figure></t>
<section title="Opt Field in SCHED-PD-LSP-ATTRIBUTE TLV"> <table anchor="PCEP-TLVs">
<t>IANA is requested to create and maintain a new <name>Additions to PCEP TLV Type Indicators Subregistry</name>
sub-registry named "SCHED-PD-LSP-ATTRIBUTE TLV Opt field" <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
subregistry named "SCHED-PD-LSP-ATTRIBUTE TLV Opt Field"
within the "Path Computation Element Protocol (PCEP) Numbers" registry. within the "Path Computation Element Protocol (PCEP) Numbers" registry.
Initial values for the sub-registry are given below. Initial values for the subregistry are given below.
New values are assigned by Standards Action <xref target="RFC8126"
format="default"/>.</t>
New values are assigned by Standards Action <xref target="RFC8126"/>.</t> <table anchor="opt-field">
<figure> <name>New SCHED-PD-LSP-ATTRIBUTE TLV Opt Field Subregistry</name>
<artwork> <thead>
Value Name Reference <tr>
----- ---- ---------- <th>Value</th>
0 Reserved <th>Description</th>
1 REPEAT-EVERY-MONTH This document <th>Reference</th>
2 REPEAT-EVERY-YEAR This document </tr>
3 REPEAT-EVERY-REPEAT-TIME-LENGTH This document </thead>
4-14 Unassigned <tbody>
15 Reserved <tr>
</artwork> <td>0</td>
</figure> <td>Reserved</td>
</section> <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 </td>
</tr>
<tr>
<td>3</td>
<td>REPEAT-EVERY-REPEAT-TIME-LENGTH</td>
<td>This document </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</name>
<t>IANA has created a new subregistry named "Schedule TLVs Flag
Field" within the "Path Computation Element Protocol (PCEP) Numbers"
registry. New values are assigned by Standards Action <xref
target="RFC8126" format="default"/>. Each bit should be tracked
with the following qualities:
</t>
<ul spacing="normal">
<li>Bit number (counting from bit 0 as the most significant
bit)</li>
<li>Capability description</li>
<li>Defining RFC</li>
</ul>
<t>The following values are defined in this document:</t>
<section title="Schedule TLVs Flag Field"> <table anchor="schedule-tlvs">
<t>IANA is requested to create a new sub-registry, <name>New Schedule TLVs Flag Field Subregistry</name>
named "Schedule TLVs Flag Field", <thead>
within the "Path Computation Element Protocol (PCEP) <tr>
Numbers" registry. <th>Bit</th>
New values are <th>Description</th>
assigned by Standards Action <xref target="RFC8126"/>. Each bit should be tr <th>Reference</th>
acked </tr>
with the following qualities: </thead>
<list style="symbols"> <tbody>
<t>Bit number (counting from bit 0 as the most significant bit)</t> <tr>
<t>Capability description</t> <td>0-3</td>
<t>Defining RFC</t></list> <td>Unassigned</td>
</t> <td></td>
</tr>
<tr>
<td>4</td>
<td>Relative Time (R-bit)</td>
<td>This document</td>
</tr>
<tr>
<td>5</td>
<td>PCC Responsible (C-bit)</td>
<td>This document</td>
</tr>
<tr>
<td>6</td>
<td>LSP Activated (A-bit)</td>
<td>This document</td>
</tr>
<tr>
<td>7</td>
<td>Grace Period Included (G-bit)</td>
<td>This document</td>
</tr>
</tbody>
</table>
<t>The following values are defined in this document:<figure> </section>
<artwork>
Bit Description Reference
0-3 Unassigned
4 Relative Time (R-bit) This document
5 PCC Responsible (C-bit) This document
6 LSP Activated (A-bit) This document
7 Grace Period Included (G-bit) This document</artwork>
</figure></t>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="STATEFUL-PCE-CAPABILITY TLV Flag field"> <name>STATEFUL-PCE-CAPABILITY TLV Flag Field</name>
<t>This document defines new bits in the Flags field in the <t>This document defines new bits in the Flags field in the
STATEFUL-PCE-CAPABILITY TLV in the OPEN object. IANA STATEFUL-PCE-CAPABILITY TLV in the OPEN object. IANA maintains the
maintains a sub-registry "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry within the "Path
"Path Computation Element Protocol (PCEP) Numbers" registry. IANA is req Computation Element Protocol (PCEP) Numbers" registry. IANA has
uested made the following allocations in this subregistry.</t>
to make the following allocations from this sub-registry.</t>
<t>The following values are defined in this document:<figure>
<artwork>Bit Description Referenc
e
TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document
TBD4 PD-LSP-CAPABLITY (PD-bit) This document</artwork>
</figure></t>
<table anchor="stateful-pce-flag">
<name>Additions to 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>
<section numbered="true" toc="default">
<section title="PCEP-Error Object"> <name>PCEP-ERROR Object Error Types and Values</name>
<t>IANA is requested to allocate the following new error types to the exis <t>IANA has allocated the following new error types to the existing
ting error values error values
within the "PCEP-ERROR Object Error Types and Values" subregistry of within the "PCEP-ERROR Object Error Types and Values" subregistry of
the "Path Computation Element Protocol (PCEP) Numbers" registry:<figure><artw the "Path Computation Element Protocol (PCEP) Numbers" registry:</t>
ork>
Error-Type Meaning
6 Mandatory Object missing
Error-value
TBD5: Scheduled TLV missing
19 Invalid Operation
Error-value
TBD6: Attempted LSP Scheduling if the scheduling
capability was not advertised
29 Path computation failure
Error-value
TBD7: Constraints could not be met for some intervals
</artwork></figure>
</t>
</section> <table anchor="PCEP-error">
</section> <name>Additions to PCEP-ERROR Object 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</td>
</tr>
<tr>
<td>19</td>
<td>Invalid Operation</td>
<td>15: Attempted LSP scheduling while the scheduling capability was not
advertised</td>
</tr>
<tr>
<td>29</td>
<td>Path computation failure</td>
<td>5: Constraints could not be met for some intervals</td>
</tr>
</tbody>
</table>
<section title="Acknowledgments"> </section>
<t>The authors of this document would also like to thank Rafal
Szarecki, Adrian Farrel, Cyril Margaria for the review and comments.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
<?rfc include='reference.RFC.2119'?> <displayreference target="I-D.litkowski-pce-state-sync" to="PCE-STATE-SYNC"/>
<?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>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8232.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8413.x
ml"/>
</references>
<references title="Informative References"> <references>
<name>Informative References</name>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7399.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8051.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.x
ml"/>
<!--<?rfc include='reference.RFC.5226'?>--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .litkowski-pce-state-sync.xml"/>
<?rfc include='reference.RFC.5925'?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-pce-pcep-yang.xml"/>
<?rfc include='reference.RFC.7399'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7942'?> FC.8655.xml"/>
<!--<?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>
</references> </references>
<!-- <section numbered="false" toc="default">
<section title="Scheduled LSP information synchronization"> <name>Acknowledgments</name>
<t>As for a stateful PCE, it maintains a database of LSPs (LSP-DB) that <t>The authors of this document would also like to thank <contact
are active in the network, so as to reveal the available network fullname="Rafal Szarecki"/>, <contact fullname="Adrian Farrel"/>, and
resources and place new LSPs more cleverly.</t> <contact fullname="Cyril Margaria"/> for the review and comments.</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>
<section title="Contributors Addresses">
<figure>
<artwork> Dhruv Dhody
Huawei
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com <section numbered="false" toc="default">
<name>Contributors</name>
Xufeng Liu <contact fullname="Dhruv Dhody">
Ericsson <organization>Huawei</organization>
USA <address>
Email: xliu@kuatrotech.com <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>
</contact>
Mehmet Toy <contact fullname="Xufeng Liu">
Verizon <organization>Ericsson</organization>
USA <address>
Email: mehmet.toy@verizon.com <postal>
<street></street>
<country>United States of America</country>
</postal>
<email>xliu@kuatrotech.com</email>
</address>
</contact>
Vic Liu <contact fullname="Mehmet Toy">
China Mobile <organization>Verizon</organization>
No.32 Xuanwumen West Street, Xicheng District <address>
Beijing, 100053 <postal>
China <street></street>
Email: liu.cmri@gmail.com <country>United States of America</country>
</postal>
<email>mehmet.toy@verizon.com</email>
</address>
</contact>
Lei Liu <contact fullname="Vic Liu">
Fujitsu <organization>China Mobile</organization>
USA <address>
Email: lliu@us.fujitsu.com <postal>
<street>No.32 Xuanwumen West Street, Xicheng District</street>
<city>Beijing</city>
<code>100053</code>
<country>China</country>
</postal>
<email>liu.cmri@gmail.com</email>
</address>
</contact>
Khuzema Pithewan <contact fullname="Lei Liu">
Infinera <organization>Fujitsu</organization>
Email: kpithewan@infinera.com <address>
<postal>
<street></street>
<country>United States of America</country> </postal>
<email>lliu@us.fujitsu.com</email>
</address>
</contact>
Zitao Wang <contact fullname="Khuzema Pithewan">
Huawei <organization>Infinera</organization>
101 Software Avenue, Yuhua District <address>
Nanjing, Jiangsu 210012 <postal>
China <street></street>
<country></country>
</postal>
<email>kpithewan@infinera.com</email>
</address>
</contact>
Email: wangzitao@huawei.com <contact fullname="Zitao Wang">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>wangzitao@huawei.com</email>
</address>
</contact>
Xian Zhang <contact fullname="Xian Zhang">
Huawei Technologies <organization>Huawei Technologies</organization>
Research Area F3-1B, <address>
Huawei Industrial Base, <postal>
Shenzhen, 518129, China <street>Research Area F3-1B</street>
<cityarea>Huawei Industrial Base</cityarea>
<city>Shenzhen</city>
<code>518129</code>
<country>China</country>
</postal>
<email>zhang.xian@huawei.com</email>
</address>
</contact>
Email: zhang.xian@huawei.com</artwork>
</figure>
</section> </section>
<!-- Informative --> </back>
</back>
</rfc> </rfc>
 End of changes. 213 change blocks. 
1290 lines changed or deleted 1167 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/