Internet DRAFT - draft-ietf-pce-stateful-pce-lsp-scheduling
draft-ietf-pce-stateful-pce-lsp-scheduling
PCE Working Group H. Chen, Ed.
Internet-Draft Futurewei
Intended status: Standards Track Y. Zhuang, Ed.
Expires: February 27, 2021 Q. Wu
Huawei
D. Ceccarelli
Ericsson
August 26, 2020
PCEP Extensions for LSP scheduling with stateful PCE
draft-ietf-pce-stateful-pce-lsp-scheduling-27
Abstract
This document defines a set of extensions needed to the stateful Path
Computation Element (PCE) communication Protocol (PCEP), so as to
enable Labeled Switched Path (LSP) path computation, activation,
setup and deletion based on scheduled time intervals for the LSP and
the actual network resource usage in a centralized network
environment as stated in RFC 8413.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 27, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Chen, et al. Expires February 27, 2021 [Page 1]
Internet-Draft LSP Scheduling August 2020
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation and Objectives . . . . . . . . . . . . . . . . . . 5
4. Procedures and Mechanisms . . . . . . . . . . . . . . . . . . 5
4.1. LSP Scheduling Overview . . . . . . . . . . . . . . . . . 5
4.2. Support of LSP Scheduling . . . . . . . . . . . . . . . . 7
4.2.1. LSP Scheduling . . . . . . . . . . . . . . . . . . . 7
4.2.2. Periodical LSP Scheduling . . . . . . . . . . . . . . 7
4.3. Scheduled LSP creation . . . . . . . . . . . . . . . . . 9
4.4. Scheduled LSP Modifications . . . . . . . . . . . . . . . 10
4.5. Scheduled LSP activation and deletion . . . . . . . . . . 11
5. PCEP Objects and TLVs . . . . . . . . . . . . . . . . . . . . 11
5.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 11
5.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. SCHED-LSP-ATTRIBUTE TLV . . . . . . . . . . . . . . . 12
5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV . . . . . . . . . . . . . 15
6. The PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 16
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 16
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 17
6.3. The PCInitiate Message . . . . . . . . . . . . . . . . . 17
6.4. The PCReq message . . . . . . . . . . . . . . . . . . . . 17
6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 17
6.6. The PCErr Message . . . . . . . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Manageability Consideration . . . . . . . . . . . . . . . . . 19
9.1. Control of Function and Policy . . . . . . . . . . . . . 19
9.2. Information and Data Models . . . . . . . . . . . . . . . 20
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20
9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20
9.5. Requirements On Other Protocols . . . . . . . . . . . . . 20
9.6. Impact On Network Operations . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 20
10.1.1. Opt Field in SCHED-PD-LSP-ATTRIBUTE TLV . . . . . . 21
10.1.2. Schedule TLVs Flag Field . . . . . . . . . . . . . . 21
10.2. STATEFUL-PCE-CAPABILITY TLV Flag field . . . . . . . . . 21
10.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
Chen, et al. Expires February 27, 2021 [Page 2]
Internet-Draft LSP Scheduling August 2020
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Contributors Addresses . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
The Path Computation Element Protocol (PCEP) defined in [RFC5440] is
used between a Path Computation Element (PCE) and a Path Computation
Client (PCC) (or other PCE) to enable path computation of Multi-
protocol Label Switching (MPLS) Traffic Engineering Label Switched
Paths (TE LSPs).
[RFC8231] describes a set of extensions to PCEP to provide stateful
control. A stateful PCE has access to not only the information
carried by the network's Interior Gateway Protocol (IGP) but also the
set of active paths and their reserved resources for its
computations. The additional state allows the PCE to compute
constrained paths while considering individual LSPs and their
interactions.
Traditionally, the usage and allocation of network resources,
especially bandwidth, can be supported by a Network Management System
(NMS) operation such as path pre-establishment. However, this does
not provide efficient usage of network resources. The established
paths reserve the resources forever, which cannot be used by other
services even when they are not used for transporting any service.
[RFC8413] then provides a framework that describes and discusses the
problem, and defines an appropriate architecture for the scheduled
reservation of TE resources.
The scheduled reservation of TE resources allows network operators to
reserve resources in advance according to the agreements with their
customers, and allows them to transmit data about scheduling such as
a specified start time and duration, for example for a scheduled bulk
data replication between data centers. It enables the activation of
bandwidth usage at the time the service is really being used while
letting other services use it when this service is not using it. The
requirement of scheduled LSP provisioning is mentioned in [RFC8231]
and [RFC7399]. Also, for deterministic networks
[I-D.ietf-detnet-architecture], the scheduled LSP or temporal LSP can
provide a better network resource usage for guaranteed links. This
idea can also be applied in segment routing [RFC8402] to schedule the
network resources over the whole network in a centralized manner as
well.
Chen, et al. Expires February 27, 2021 [Page 3]
Internet-Draft LSP Scheduling August 2020
With this in mind, this document defines a set of extensions needed
to PCEP used for stateful PCEs so as to enable LSP scheduling for
path computation and LSP setup/deletion based on the actual network
resource usage duration of a traffic service. A scheduled LSP is
characterized by a starting time and a duration. When the end of the
LSP life is reached, it is deleted to free up the resources for other
LSPs (scheduled or not).
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.1. Terminology
The following terminology is re-used from existing PCE documents.
o Active Stateful PCE [RFC8051]
o Delegation [RFC8051]
o PCE-Initiated LSP [RFC8281]
o PCC [RFC5440]
o PCE [RFC5440]
o TE LSP [RFC5440]
o TED [RFC5440]
o LSP-DB [RFC8051]
In addition, this document defines the following terminologies.
Scheduled TE LSP (or Scheduled LSP for short): an LSP with the
scheduling attributes, that carries traffic flow demand at a
starting time and lasts for a certain duration (or from a starting
time to an ending time, where the ending time is the starting time
plus the duration). A scheduled LSP is also called a temporal
LSP. The PCE operates path computation per LSP availability for
the required time and duration.
Scheduled LSP-DB: a database of scheduled LSPs.
Chen, et al. Expires February 27, 2021 [Page 4]
Internet-Draft LSP Scheduling August 2020
Scheduled TED: Traffic engineering database with the awareness of
scheduled resources for TE. This database is generated by the PCE
from the information in TED and scheduled LSP-DB and allows
knowing, at any time, the expected amount of available resources
(discounting the possibility of failures in the future).
Starting time (start-time): This value indicates when the scheduled
LSP is used and the corresponding LSP must be setup and active.
In other time (i.e., before the starting time or after the
starting time plus Duration), the LSP can be inactive to include
the possibility of the resources being used by other services.
Duration: This value indicates the length of time that the LSP is
undertaken by a traffic flow and the corresponding LSP must be
setup and active. At the end of which, the LSP is torn down and
removed from the database.
3. Motivation and Objectives
A stateful PCE [RFC8231] can support better efficiency by using LSP
scheduling described in the use case of [RFC8051]. This requires the
PCE to maintain the scheduled LSPs and their associated resource
usage, e.g. bandwidth for Packet-switched network, as well as have
the ability to trigger signaling for the LSP setup/tear-down at the
correct time.
Note that existing configuration tools can be used for LSP
scheduling, but as highlighted in section 3.1.3 of [RFC8231] as well
as discussions in [RFC8413], doing this as a part of PCEP in a
centralized manner, has obvious advantages.
This document provides a set of extensions to PCEP to enable LSP
scheduling for LSP creation/deletion under the stateful control of a
PCE and according to traffic service requests from customers, so as
to improve the usage of network resources.
4. Procedures and Mechanisms
4.1. LSP Scheduling Overview
The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for
customers' traffic services at its actual usage time, so as to
improve the network resource utilization efficiency.
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 [RFC8231], while the other is the scheduled LSP database (SLSP-
DB, see section 6). The SLSP-DB records scheduled LSPs and is used
Chen, et al. Expires February 27, 2021 [Page 5]
Internet-Draft LSP Scheduling August 2020
in conjunction with the TED and LSP-DB. Note that the two types of
LSP databases can be implemented in one physical database or two
different databases. This is an implementation matter and this
document does not state any preference.
Furthermore, a scheduled TED can be generated from the scheduled LSP-
DB, LSP-DB and TED to indicate the network links and nodes with
resource availability information for now and future. The scheduled
TED MUST be maintained by all PCEs within the network environment.
In case of implementing PCC-initiated scheduled LSPs, when delegating
a scheduled LSP, a PCC MUST include its scheduling parameters (see
Section 5.2.1), including the starting time and the duration using
PCRpt message. Since the LSP is not yet signaled, at the time of
delegation the LSP would be in down state. Upon receiving the
delegation of the scheduled LSP, a stateful PCE 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
[RFC8231].
Note that the active stateful PCE can update to the PCC with the path
for the scheduled LSP at any time. However, the PCC should not
signal the LSP over the path on receiving these messages since the
path is not active yet; PCC signals the LSP at the starting time.
In case of multiple PCEs within a single domain, the PCE would need
to synchronize their scheduling information with other PCEs within
the domain. This could be achieved by proprietary database
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.
The scheduled LSP can also be initiated by a PCE itself. In case of
implementing PCE-initiated scheduled LSP, the stateful PCE SHALL
check the network resource availability for the traffic and compute a
path for the scheduled LSP and initiate a scheduled LSP at the PCC
and synchronize the scheduled LSP to other PCEs. Note that, the PCC
could be notified immediately or at the starting time of the
scheduled LSP based on the local policy. In the former case, the
SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the
message whereas, for the latter the SCHED-LSP-ATTRIBUTE TLV SHOULD
NOT be included. Either way the synchronization to other PCEs MUST
be done when the scheduled LSP is created.
Chen, et al. Expires February 27, 2021 [Page 6]
Internet-Draft LSP Scheduling August 2020
In both modes, for activation of scheduled LSPs, the PCC MUST
initiate the setup of scheduled LSP at the start time. Similarly on
scheduled usage expiry, the PCC MUST initiate the removal of the LSP
based on the Flag set in SCHED-LSP-ATTRIBUTE TLV.
4.2. Support of LSP Scheduling
4.2.1. LSP Scheduling
For a scheduled LSP, a user configures it with an arbitrary
scheduling duration from time Ta to time Tb, which may be represented
as [Ta, Tb].
When an LSP is configured with arbitrary scheduling duration [Ta,
Tb], a path satisfying the constraints for the LSP in the scheduling
duration is computed and the LSP along the path is set up to carry
traffic from time Ta to time Tb.
4.2.2. Periodical LSP Scheduling
In addition to LSP Scheduling at an arbitrary time period, there are
also periodical LSP Scheduling.
A periodical LSP Scheduling means an LSP has multiple time intervals
and the LSP is set up to carry traffic in every time interval. It
has a scheduling duration such as [Ta, Tb], a number of repeats such
as 10 (repeats 10 times), and a repeat cycle/time interval such as a
week (repeats every week). The scheduling interval: "[Ta, Tb]
repeats n times with repeat cycle C" represents n+1 scheduling
intervals as follows:
[Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC]
When an LSP is configured with a scheduling interval such as "[Ta,
Tb] repeats 10 times with a repeat cycle a week" (representing 11
scheduling intervals), a path satisfying the constraints for the LSP
in every interval represented by the periodical scheduling interval
is computed once. Note that the path computed for one recurrence may
be different from the path for another recurrence. And then the LSP
along the path is set up to carry traffic in each of the scheduling
intervals. If there is no path satisfying the constraints for some
of the intervals, the LSP MUST NOT 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).
Chen, et al. Expires February 27, 2021 [Page 7]
Internet-Draft LSP Scheduling August 2020
4.2.2.1. Elastic Time LSP Scheduling
In addition to the basic LSP scheduling at an arbitrary time period,
another option is elastic time intervals, which is represented as
within -P and Q, where P and Q is an amount of time such as 300
seconds. P is called elastic range lower bound and Q is called
elastic range upper bound.
For a simple time interval such as [Ta, Tb] with an elastic range,
elastic time interval: "[Ta, Tb] within -P and Q" means a time period
from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb
are shifted by the same 'X'. This elastic time interval is suitable
for the case where a user wants to have a scheduled LSP up to carry
the traffic in time interval [Ta, Tb] and has some flexibility on
shifting the time interval a little bit such as up to P seconds
earlier/left or some time such as up to Q seconds later/right.
When an LSP is configured with elastic time interval "[Ta, Tb] within
-P and Q", a path is computed such that the path satisfies the
constraints for the LSP in the time period from (Ta+Xv) to (Tb+Xv)
and an optimization is performed on Xv from -P to Q. The
optimization makes [Ta+Xv, Tb+Xv] to be the time interval closest to
time interval [Ta, Tb] within the elastic range. The LSP along the
path is set up to carry traffic in the time period from (Ta+Xv) to
(Tb+Xv).
Similarly, for a recurrent time interval with an elastic range,
elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C
within -P and Q" represents n+1 simple elastic time intervals as
follows:
[Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn]
where -P <= Xi <= Q, i = 0, 1, 2, ..., n.
If a user wants to keep the same repeat cycle between any two
adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n
times with repeat cycle C within -P and Q SYNC" may be used, which
represents n+1 simple elastic time intervals as follows:
[Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X]
where -P <= X <= Q.
4.2.2.2. Grace Periods
Besides the stated time scheduling, a user may want to have some
grace periods (short for graceful time periods) for each or some of
the time intervals for the LSP. Two grace periods may be configured
for a time interval. One is the grace period before the time
Chen, et al. Expires February 27, 2021 [Page 8]
Internet-Draft LSP Scheduling August 2020
interval, called grace-before, which extends the lifetime of the LSP
for grace-before (such as 30 seconds) before the time interval. The
other is the one after the time interval, called grace-after, which
extends the lifetime of the LSP for grace-after (such as 60 seconds)
after the time interval. Note that no network resources such as link
bandwidth will be reserved for the LSP during the grace periods.
When an LSP is configured with a simple time interval such as [Ta,
Tb] with grace periods such as grace-before GB and grace-after GA, a
path is computed such that the path satisfies the constraints for the
LSP in the time period from Ta to Tb. The LSP along the path is set
up to carry traffic in the time period from (Ta-GB) to (Tb+GA).
During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the
LSP is up to carry traffic in best effort.
4.3. Scheduled LSP creation
In order to realize PCC-Initiated scheduled LSPs in a centralized
network environment, a PCC MUST separate the setup of an LSP into two
steps. The first step is to request/delegate and get an LSP but not
signal it over the network. The second step is to signal the
scheduled LSP over the LSRs (Label Switching Router) at its starting
time.
For PCC-Initiated scheduled LSPs, a PCC MUST delegate the scheduled
LSP by sending a path computation report (PCRpt) message by including
its demanded resources with the scheduling information to a stateful
PCE. Note the PCC MAY use the PCReq/PCRep with scheduling
information before delegating.
Upon receiving the delegation via PCRpt message, the stateful PCE
MUST compute a path for the scheduled LSP per its starting time and
duration based on the network resource availability stored in
scheduled TED (see Section 4.1).
The stateful PCE will send a PCUpd message with the scheduled path
information as well as the scheduled resource information for the
scheduled LSP to the PCC. The stateful PCE MUST update its local
scheduled LSP-DB and scheduled TED with the scheduled LSP and would
need to synchronize the scheduling information with other PCEs in the
domain.
For PCE-Initiated Scheduled LSP, the stateful PCE MUST compute a path
for the scheduled LSP per requests from network management systems
automatically based on the network resource availability in the
scheduled TED and send a PCInitiate message with the path information
back to the PCC. Based on the local policy, the PCInitiate message
could be sent immediately to ask the PCC to create a scheduled LSP
Chen, et al. Expires February 27, 2021 [Page 9]
Internet-Draft LSP Scheduling August 2020
(as per this document) or the PCInitiate message could be sent at the
start time to the PCC to create a normal LSP (as per [RFC8281]).
For both PCC-Initiated and PCE-Initiated Scheduled LSPs:
o The stateful PCE MUST update its local scheduled LSP-DB and
scheduled TED with the scheduled LSP.
o Upon receiving the PCUpd message or PCInitiate message for the
scheduled LSP from PCEs with a found path, the PCC determines that
it is a scheduled path for the LSP by the SCHED-LSP-ATTRIBUTE TLV
(see Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see
Section 5.2.2) in the message, and does not trigger signaling for
the LSP setup on LSRs immediately.
o The stateful PCE MUST update the Scheduled LSP parameters on any
network events using the PCUpd message to PCC. These changes are
also synchronized to other PCEs.
o When it is time for the LSP to be set up (i.e., at the start
time), based on the value of the C flag for the scheduled TLV,
either the PCC MUST trigger the LSP to be signaled or the
delegated PCE MUST send a PCUpd message to the head end LSR
providing the updated path to be signaled (with A flag set to
indicate LSP activation).
4.4. Scheduled LSP Modifications
After a scheduled LSP is configured, a user may change its parameters
including the requested time as well as the bandwidth. For a
periodic scheduled LSP, its unused recurrences can be modified or
cancelled. For a scheduled LSP that is currently active, its
duration (the lifetime) can be reduced.
In the PCC-Initiated case, the PCC MUST 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
Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2)
carried in the LSP Object. The PCE SHOULD take the updated resources
and schedule into considerations and update the new path for the
scheduled LSP to the PCC as well as synchronize to other PCEs in the
network. In case path cannot be set based on new requirements, the
previous LSP will not be impacted and the same MUST be conveyed by
the use of empty ERO in the PCEP messages.
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
Chen, et al. Expires February 27, 2021 [Page 10]
Internet-Draft LSP Scheduling August 2020
PCInitiate message, it SHOULD update the path and other scheduling
and resource information by sending a PCUpd message.
4.5. Scheduled LSP activation and deletion
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
scheduled TLV, either the PCC MUST trigger the LSP to be signaled or
the delegated PCE MUST send a PCUpd message to the head end LSR
providing the updated path to be signaled (with A flag set to
indicate LSP activation). The PCC MUST report the status of the
active LSP as per the procedures in [RFC8231] and at this time the
LSP MUST be considered as part of the LSP-DB. The A flag MUST be set
in the scheduled TLV to indicate that the LSP is active now. After
the scheduled duration expires, based on the C flag, the PCC MUST
trigger the LSP deletion on itself or the delegated PCE MUST send a
PCUpd message to the PCC to delete the LSP as per the procedures in
[RFC8231].
In the PCE-Initiated case, based on the local policy, if the
scheduled LSP is already conveyed to the PCC at the time of creation,
the handling of LSP activation and deletion is handled in the same
way as PCC-Initiated case as per the setting of C flag. Otherwise,
the PCE MUST send the PCInitiate message at the start time to the PCC
to create a normal LSP without the scheduled TLV and remove the LSP
after the duration expires as per [RFC8281].
5. PCEP Objects and TLVs
5.1. Stateful PCE Capability TLV
A PCC and a PCE indicate their ability to support LSP scheduling
during 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
[RFC8231] and updated in [RFC8281] and [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.
B (LSP-SCHEDULING-CAPABILITY) - 1 bit [Bit Position - TBD3]: If set
to 1 by a PCC, the B Flag indicates that the PCC allows LSP
scheduling; if set to 1 by a PCE, the B Flag indicates that the
PCE is capable of LSP scheduling. The B bit MUST be set by both
Chen, et al. Expires February 27, 2021 [Page 11]
Internet-Draft LSP Scheduling August 2020
PCEP peers in order to support LSP scheduling for path
computation.
PD (PD-LSP-CAPABLITY) - 1 bit: [Bit Position - TBD4] If set to 1 by
a PCC, the PD Flag indicates that the PCC allows LSP scheduling
periodically; if set to 1 by a PCE, the PD Flag indicates that the
PCE is capable of periodical LSP scheduling. Both the PD bit and
the B bit MUST be set to 1 by both PCEP peers in order to support
periodical LSP scheduling for path computation. If the PD bit or
B bit is 0, then the periodical LSP scheduling capability MUST be
ignored.
5.2. LSP Object
The LSP object is defined in [RFC8231]. This document adds an
optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an
optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP scheduling.
The LSP Object for a scheduled LSP MUST NOT include these two TLVs.
Only one scheduling, either normal or periodical, is allowed for a
scheduled LSP.
The presence of the SCHED-LSP-ATTRIBUTE TLV in the LSP object
indicates that this LSP is normal scheduling while the SCHED-PD-LSP-
ATTRIBUTE TLV indicates that this scheduled LSP is periodical. The
SCHED-LSP-ATTRIBUTE TLV MUST be present in LSP Object for each normal
scheduled LSP carried in the PCEP messages. The SCHED-PD-LSP-
ATTRIBUTE TLV MUST be used in the LSP Object for each periodic
scheduled LSP carried in the PCEP messages.
Only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP object.
In case more than one SCHED-LSP-ATTRIBUTE TLV is found, the first
instance is processed and others ignored. The SCHED-PD-LSP-ATTRIBUTE
TLV is the same as the SCHED-LSP-ATTRIBUTE TLV regarding to its
presence in the LSP object.
5.2.1. SCHED-LSP-ATTRIBUTE TLV
The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV within
the LSP object for LSP scheduling for the requesting traffic service.
This TLV MUST NOT be included unless both PCEP peers have set the B
(LSP-SCHEDULING-CAPABILITY) bit in STATEFUL-PCE-CAPABILITY TLV
carried in the Open message to one. If the TLV is received by a peer
when both peers didn't set the B bit to one, the peer MUST generate a
PCEP Error (PCErr) with a PCEP-ERROR object having Error-type = 19
(Invalid Operation) and Error-value = TBD6 (Attempted LSP Scheduling
if the scheduling capability was not advertised).
Chen, et al. Expires February 27, 2021 [Page 12]
Internet-Draft LSP Scheduling August 2020
The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |R|C|A|G| Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SCHED-LSP-ATTRIBUTE TLV
The type of the TLV is [TBD1] and the TLV has a fixed length of 16
octets.
The fields in the format are:
Flags (8 bits): The following flags are defined in this document
R (1 bit): Set to 1 to indicate the Start-Time is a relative
time, which is the number of seconds from the current time.
The PCEs and PCCs MUST synchronized their clocks when relative
time is used. It is RECOMMENDED that the Network Time Protocol
[RFC5905] be used to synchronize clocks among them. When the
transmission delay from a PCE or PCC to another PCE or PCC is
too big such as greater than 1 second, the scheduling interval
represented is not accurate if the delay is not considered.
Set to 0 to indicate that the 32-bit Start-Time is an absolute
time, which is the number of seconds since the epoch. The
epoch is 1 January 1970 at 00:00 UTC. It wraps around every
2^32 seconds, which is roughly 136 years. The next wraparound
will occur in the year 2106. The received Start-Time is
considered after the wraparound if the resulting value is less
than the current time. In which case, the value of the 32-bit
Start-Time is considered as the number of seconds from the time
of wraparound (because the Start-Time is always a future time).
C (1 bit): Set to 1 to indicate the PCC is responsible to setup
and remove the scheduled LSP based on the Start-Time and
duration. The PCE holds these responsibilities when the bit is
set to zero.
Chen, et al. Expires February 27, 2021 [Page 13]
Internet-Draft LSP Scheduling August 2020
A (1 bit): Set to 1 to indicate the scheduled LSP has been
activated and should be considered as part of LSP-DB (instead
of Scheduled LSP-DB).
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;
set to 0 indicate the elastic range is included in the fields.
Reserved (24 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Start-Time (32 bits): This value in seconds, indicates when the
scheduled LSP is used to carry traffic and the corresponding LSP
MUST be setup and activated. Note that the transmission delay
SHOULD be considered when R=1 and the value of Start-Time is
small.
Duration (32 bits): The value in seconds, indicates the duration
that the LSP is undertaken by a traffic flow and the corresponding
LSP MUST be up to carry traffic. At the expiry of this duration,
the LSP MUST be torn down and deleted. 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.
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.
In addition, it contains G flag set to 1 and a non zero grace-before
and grace-after in the fields GrB/Elastic-Lower-Bound and GrA/
Elastic-Upper-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 there is an elastic range configured. A TLV
can configure a non-zero grace period or elastic range, but it MUST
NOT provide both for an LSP.
o GrB (Grace-Before -16 bits): The grace period time length in
seconds before the starting time.
Chen, et al. Expires February 27, 2021 [Page 14]
Internet-Draft LSP Scheduling August 2020
o GrA (Grace-After -16 bits): The grace period time length in
seconds after time interval [starting time, starting time +
duration].
o Elastic-Lower-Bound (16 bits): The maximum amount of time in
seconds that time interval can shift to lower/left.
o Elastic-Upper-Bound (16 bits): The maximum amount of time in
seconds that time interval can shift to upper/right.
5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV
The periodical LSP is a special case of LSP scheduling. The traffic
service happens in a series of repeated time intervals. The SCHED-
PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the
LSP object for this periodical LSP scheduling.
This TLV MUST NOT be included unless both PCEP peers have set the B
(LSP-SCHEDULING-CAPABILITY) bit and PD (PD-LSP-CAPABLITY) bit in
STATEFUL-PCE-CAPABILITY TLV carried in open message to one. If the
TLV is received by a peer when either (or both) bit is zero, the peer
MUST generate a PCEP Error (PCErr) with a PCEP-ERROR object having
Error-type = 19 (Invalid Operation) and Error-value = TBD6 (
Attempted LSP Scheduling if the scheduling capability was not
advertised).
The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags|R|C|A|G| Opt | NR | Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repeat-time-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SCHED-PD-LSP-ATTRIBUTE TLV
The type of the TLV is [TBD2] and the TLV has a fixed length of 20
octets. The description, format and meaning of the Flags (R, C, A
Chen, et al. Expires February 27, 2021 [Page 15]
Internet-Draft LSP Scheduling August 2020
and G bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and
Elastic-Upper-Bound fields remain the same as in the SCHED-LSP-
ATTRIBUTE TLV.
The following fields are new :
Opt: (4 bits) Indicates options to repeat. When a PCE receives a
TLV with a unknown Opt value, it does not compute any path for the
LSP. It MUST generate a PCEP Error (PCErr) with a PCEP-ERROR
object having Error-type = 4 (Not supported object) and Error-
value = 4 (Unsupported parameter).
Opt = 1: repeat every month;
Opt = 2: repeat every year;
Opt = 3: repeat every Repeat-time-length.
A user may configure a Repeat-time-length in time units weeks,
days, hours, minutes, and/or seconds. The value represented by
these units is converted to the number of seconds in the TLV. For
example, repeat every 2 weeks is equivalent to repeat every
Repeat-time-length = 2*7*86,400 (seconds), where 86,400 is the
number of seconds per day.
NR: (12 bits) The number of repeats. During each repetition, LSP
carries traffic.
Reserved (8 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Repeat-time-length: (32 bits) The time in seconds between the start-
time of one repetition and the start-time of the next repetition.
6. The PCEP Messages
6.1. The PCRpt Message
Path Computation State Report (PCRpt) is a PCEP message sent by a PCC
to a PCE to report the status of one or more LSPs as per [RFC8231].
Each LSP State Report in a PCRpt message contains the actual LSP's
path, bandwidth, operational and administrative status, etc. An LSP
Status Report carried on a PCRpt message is also used in delegation
or revocation of control of an LSP to/from a PCE. In case of
scheduled LSP, a scheduled TLV MUST be carried in the LSP object and
the ERO conveys the intended path for the scheduled LSP. The
scheduled LSP MUST be delegated to a PCE.
Chen, et al. Expires February 27, 2021 [Page 16]
Internet-Draft LSP Scheduling August 2020
6.2. The PCUpd Message
Path Computation Update Request (PCUpd) is a PCEP message sent by a
PCE to a PCC to update LSP parameters, on one or more LSPs as per
[RFC8231]. Each LSP Update Request on a PCUpd message contains all
LSP parameters that a PCE wishes to be set for a given LSP. In case
of scheduled LSP, a scheduled TLV MUST be carried in the LSP object
and the ERO conveys the intended path for the scheduled LSP. In case
no path can be found, an empty ERO is used. The A bit is used in
PCUpd message to indicate the activation of the scheduled LSP in case
the PCE is responsible for the activation (as per the C bit).
6.3. The PCInitiate Message
An LSP Initiate Request (PCInitiate) message is a PCEP message sent
by a PCE to a PCC to trigger LSP instantiation or deletion as per
[RFC8281]. In case of scheduled LSP, based on the local policy, PCE
MAY convey the scheduled LSP to the PCC by including a scheduled TLV
in the LSP object. Or the PCE would initiate the LSP only at the
start time of the scheduled LSP as per the [RFC8281] without the use
of scheduled TLVs.
6.4. The PCReq message
The Path Computation Request (PCReq) message is a PCEP message sent
by a PCC to a PCE to request a path computation [RFC5440] and it may
contain the LSP object [RFC8231] to identify the LSP for which the
path computation is requested. In case of scheduled LSP, a scheduled
TLV MUST be carried in the LSP object in PCReq message to request the
path computation based on scheduled TED and LSP-DB. A PCC MAY use
PCReq message to obtain the scheduled path before delegating the LSP.
The parameters of the LSP may be changed (refer to Section 4.4).
6.5. The PCRep Message
The Path Computation Reply (PCRep) message is a PCEP message sent by
a PCE to a PCC in reply to a path computation request [RFC5440] and
it may contain the LSP object [RFC8231] to identify the LSP for which
the path is computed. A PCRep message can contain either a set of
computed paths if the request can be satisfied, or a negative reply
if not. The negative reply may indicate the reason why no path could
be found. In case of scheduled LSP, a scheduled TLV MUST be carried
in the LSP object in PCRep message to indicate the path computation
based on scheduled TED and LSP-DB. A PCC and PCE MAY use PCReq and
PCRep message to obtain the scheduled path before delegating the LSP.
Chen, et al. Expires February 27, 2021 [Page 17]
Internet-Draft LSP Scheduling August 2020
6.6. The PCErr Message
The Path Computation Error (PCErr) message is a PCEP message as
described in [RFC5440] for error reporting. The current document
defines new error values for several error types to cover failures
specific to scheduling and reuse the applicable error types and error
values of [RFC5440] and [RFC8231] wherever appropriate.
The PCEP extensions for scheduling MUST NOT be used if one or both
PCEP speakers have not set the corresponding bits in the STATEFUL-
PCE-CAPABILITY TLV in their respective OPEN message 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
SHOULD ignore the TLV. As per Section 7.1 of [RFC5440], a legacy
PCEP implementation that does not understand this specification,
would consider a scheduled TLV as unknown and ignore them.
If the PCC decides that the scheduling parameters proposed in the
PCUpd/PCInitiate message are unacceptable, it MUST report this error
by including the LSP-ERROR-CODE TLV (Section 7.3.3 of [RFC8231]) with
LSP error-value = 4 "Unacceptable parameters" in the LSP object (with
the scheduled TLV) in the PCRpt message to the PCE.
The scheduled TLV MUST be included in the LSP object for the
scheduled LSPs, if the TLV is missing, the receiving PCEP speaker
MUST send a PCErr message with Error-type=6 (Mandatory Object
missing) and Error-value TBD5 (Scheduled TLV missing).
7. Implementation Status
[NOTE TO RFC EDITOR : This whole section and the reference to RFC
7942 is to be removed before publication as an RFC]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
Chen, et al. Expires February 27, 2021 [Page 18]
Internet-Draft LSP Scheduling August 2020
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
At the time of posting the -09 version of this document, there are no
known implementations of this mechanism. It is believed that two
vendors/organizations are considering prototype implementations, but
these plans are too vague to make any further assertions.
8. Security Considerations
This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED-LSP-
ATTRIBUTE TLV, the security considerations discussed in [RFC5440],
[RFC8231], and [RFC8281] continue to apply. In some deployments the
scheduling information could provide details about the network
operations that could be deemed as extra sensitive. Additionally,
snooping of PCEP messages with such data or using PCEP messages for
network reconnaissance may give an attacker sensitive information
about the operations of the network. A single PCEP message can now
instruct a PCC to set up and tear down an LSP every second for a
number of times. That single message could have a significant effect
on the network. Thus, such deployments SHOULD employ suitable PCEP
security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925]
or [RFC8253], which [RFC8253] is considered a security enhancement
and thus is much better suited for the sensitive information. PCCs
may also need to apply some form of rate limit to the processing of
scheduled LSPs.
9. Manageability Consideration
9.1. Control of Function and Policy
The LSP-Scheduling feature MUST be controlled per tunnel by the
active stateful PCE, the values for parameters like starting time,
duration SHOULD be configurable by customer applications and based on
the local policy at PCE. The suggested default values for starting
time and duration are one day in seconds from the current time and
one year in seconds respectively. One day has 86,400 seconds. One
year has 31,536,000 seconds.
When configuring the parameters about time, a user SHOULD consider
leap-years and leap-seconds. 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.
Chen, et al. Expires February 27, 2021 [Page 19]
Internet-Draft LSP Scheduling August 2020
9.2. Information and Data Models
An implementation SHOULD allow the operator to view the information
about each scheduled LSP defined in this document. To serve this
purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] could be
extended.
9.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440].
9.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[RFC5440]. An implementation SHOULD allow a user to view the
information including status about a scheduled LSP 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.
9.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any new requirements
on other protocols.
9.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [RFC5440].
10. IANA Considerations
10.1. PCEP TLV Type Indicators
This document defines the following new PCEP TLVs. IANA maintains a
sub-registry "PCEP TLV Type Indicators" in the "Path Computation
Element Protocol (PCEP) Numbers" registry. IANA is requested to make
the following allocations from this sub-registry.
Value Meaning Reference
TBD1 SCHED-LSP-ATTRIBUTE This document
TBD2 SCHED-PD-LSP-ATTRIBUTE This document
Chen, et al. Expires February 27, 2021 [Page 20]
Internet-Draft LSP Scheduling August 2020
10.1.1. Opt Field in SCHED-PD-LSP-ATTRIBUTE TLV
IANA is requested to create and maintain a new sub-registry named
"SCHED-PD-LSP-ATTRIBUTE TLV Opt field" within the "Path Computation
Element Protocol (PCEP) Numbers" registry. Initial values for the
sub-registry are given below. New values are assigned by Standards
Action [RFC8126].
Value Name Reference
----- ---- ----------
0 Reserved
1 REPEAT-EVERY-MONTH This document
2 REPEAT-EVERY-YEAR This document
3 REPEAT-EVERY-REPEAT-TIME-LENGTH This document
4-14 Unassigned
15 Reserved
10.1.2. Schedule TLVs Flag Field
IANA is requested to create a new sub-registry, named "Schedule TLVs
Flag Field", within the "Path Computation Element Protocol (PCEP)
Numbers" registry. New values are assigned by Standards Action
[RFC8126]. Each bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Capability description
o Defining RFC
The following values are defined in this document:
Bit Description Reference
0-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
10.2. STATEFUL-PCE-CAPABILITY TLV Flag field
This document defines new bits in the Flags field in the STATEFUL-
PCE-CAPABILITY TLV in the OPEN object. IANA maintains a sub-registry
"STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "Path Computation
Element Protocol (PCEP) Numbers" registry. IANA is requested to make
the following allocations from this sub-registry.
The following values are defined in this document:
Chen, et al. Expires February 27, 2021 [Page 21]
Internet-Draft LSP Scheduling August 2020
Bit Description Reference
TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document
TBD4 PD-LSP-CAPABLITY (PD-bit) This document
10.3. PCEP-Error Object
IANA is requested to allocate the following new error types to the
existing error values within the "PCEP-ERROR Object Error Types and
Values" subregistry of the "Path Computation Element Protocol (PCEP)
Numbers" registry:
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
11. Acknowledgments
The authors of this document would also like to thank Rafal Szarecki,
Adrian Farrel, Cyril Margaria for the review and comments.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
Chen, et al. Expires February 27, 2021 [Page 22]
Internet-Draft LSP Scheduling August 2020
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework
for Scheduled Use of Resources", RFC 8413,
DOI 10.17487/RFC8413, July 2018,
<https://www.rfc-editor.org/info/rfc8413>.
12.2. Informative References
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019.
Chen, et al. Expires February 27, 2021 [Page 23]
Internet-Draft LSP Scheduling August 2020
[I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-14 (work in progress), July 2020.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014,
<https://www.rfc-editor.org/info/rfc7399>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Appendix A. Contributors Addresses
Dhruv Dhody
Huawei
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Xufeng Liu
Ericsson
Chen, et al. Expires February 27, 2021 [Page 24]
Internet-Draft LSP Scheduling August 2020
USA
Email: xliu@kuatrotech.com
Mehmet Toy
Verizon
USA
Email: mehmet.toy@verizon.com
Vic Liu
China Mobile
No.32 Xuanwumen West Street, Xicheng District
Beijing, 100053
China
Email: liu.cmri@gmail.com
Lei Liu
Fujitsu
USA
Email: lliu@us.fujitsu.com
Khuzema Pithewan
Infinera
Email: kpithewan@infinera.com
Zitao Wang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: wangzitao@huawei.com
Xian Zhang
Huawei Technologies
Research Area F3-1B,
Huawei Industrial Base,
Shenzhen, 518129, China
Email: zhang.xian@huawei.com
Authors' Addresses
Huaimo Chen (editor)
Futurewei
Boston, MA
USA
Email: huaimo.chen@futurewei.com
Chen, et al. Expires February 27, 2021 [Page 25]
Internet-Draft LSP Scheduling August 2020
Yan Zhuang (editor)
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: zhuangyan.zhuang@huawei.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Chen, et al. Expires February 27, 2021 [Page 26]
