]>
PCEP Extensions for LSP scheduling with
stateful PCEHuaweiBostonMAUSAhuaimo.chen@huawei.comHuawei101 Software Avenue, Yuhua DistrictNanjingJiangsu210012Chinazhuangyan.zhuang@huawei.comHuawei101 Software Avenue, Yuhua DistrictNanjingJiangsu210012Chinabill.wu@huawei.comHuaweiDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiadhruv.ietf@gmail.comEricssonVia A. Negrone 1/AGenova - Sestri PonenteItalydaniele.ceccarelli@ericsson.comRouting Area
PCE Working GroupRFCRequest for CommentsI-DInternet-DraftPath Computation ElementThis document proposes a set of extensions needed to the stateful
Path Computation Element (PCE) communication Protocol (PCEP), so as to
enable Labeled Switched Path (LSP) scheduling for path computation and
LSP setup/deletion based on the actual network resource usage duration
of a traffic service in a centralized network environment as stated in
.The Path Computation Element Protocol (PCEP) defined in 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 Path (TE
LSP). 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 network usage since the established paths exclude the
possibility of being used by other services even when they are not used
for undertaking any service. then
provides a framework that describes and discusses the problem, and
proposes an appropriate architecture for the scheduled reservation of TE
resources.With the scheduled reservation of TE resources, it allows network
operators to reserve resources in advance according to the agreements
with their customers, and allow them to transmit data with scheduling
such as specified starting time and duration, for example for a
scheduled bulk data replication between data centers. It enables the
activation of bandwidth usage at the time the service really being used
while letting other services obtain it in spare time. The requirement of
scheduled LSP provision is mentioned in
and , so as to provide more efficient network resource usage
for traffic engineering, which hasn't been solved yet. Also, for
deterministic networks, the scheduled LSP can provide a better network
resource usage for guaranteed links. This idea can also be applied in
segment routing to schedule the network resources over the whole network
in a centralized manner as well.With this in mind, this document proposes a set of extensions needed
to the stateful PCE, so as to enable LSP scheduling for path computation
and LSP setup/deletion based on the actual network resource usage
duration of a traffic service. A scheduled LSP is characterized by a
starting time and a duration. When the end of the LSP life is reached,
it is deleted to free up the resources for other LSP (scheduled or
not).
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 when, and only when, they
appear in all capitals, as shown here.
The following terminologies are re-used from existing PCE
documents.Active Stateful PCE ;Passive Stateful PCE ;Delegation ;PCE-Initiated LSP ;PCC , ;PCE , ;TE LSP , ;TED , ;LSP DB ;In addition, this document defines the following
terminologies.a LSP with the scheduling
attributes,that carries traffic flow demand at a starting time and
last for a certain duration. The PCE operates path computation per
LSP availability for the required time and duration.a database of scheduled LSPsTraffic engineering database with the
awareness of scheduled resources for TE. This database is
generated by the PCE from the information in TED and scheduled LSP
DB and allows knowing, at any time, the amount of available
resources (does not include failures in the future).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.This value indicates the time duration that
the LSP is undertaken by a traffic flow and the corresponding LSP
must be setup and active. At the end of which, the LSP is teardown
and removed from the data base.A stateful PCE can support better efficiency by using LSP scheduling
described in the use case of . 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 as well as discussions in
, doing this as a part of PCEP in a
centralized manner, has obvious advantages.The objective of this document is to provide a set of extensions to
PCEP to enable LSP scheduling for LSPs creation/deletion under the
stateful PCE control, according to traffic services from customers, so
as to improve the usage of network resources.The LSP scheduling allows PCEs and PCCs to provide scheduled LSP
for customers' traffic services at its actual usage time, so as to
improve the network resource efficient utilization.For stateful PCE supporting LSP scheduling, there are two types of
LSP databases used in this document. One is the LSP-DB defined in PCEP
, while the other is the scheduled LSP database (SLSP-DB, see
section 6). The SLSP-DB records scheduled LSPs and is used as a
complementary to the TED and LSP-DB. Note that the two types of LSP
databases can be implemented in one physical database or two different
databases. This document does not state any preference here.Furthermore, a scheduled TED can be generated from the scheduled
LSP DB, LSP DB and TED to indicate the network links and nodes with
resource availability information for now and future. The scheduled
TED should be maintained by all PCEs within the network
environment.In case of implementing PCC-initiated scheduled LSPs, before a PCC delegates a scheduled LSP, it MAY
use the PCReq/PCRep messages to learn the path for the scheduled LSP.
A PCC MUST delegate a scheduled LSP with information of its scheduling
parameters, including the starting time and the duration using PCRpt message.
Since the LSP is not yet signaled, at the time of delegation the LSP would be in down state.
Upon
receiving the delegation of the scheduled LSP, a stateful
PCE SHALL check the scheduled TED for the network resource
availability on network nodes and computes a path for the LSP with the
scheduling information and update to the PCC as per the active stateful
PCE techniques .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 once receiving these
messages since the path is not active yet (until its starting
time).For a multiple PCE environment, in order to synchronize the
scheduled LSP DB, the mechanism as described in
are used to synchronize between PCEs. The scheduled TED can be determined from the synchronized SLSP-DB.
The PCE with delegation for the scheduled LSP would report the scheduled LSP to other PCEs, any future
update to the scheduled LSP is also updated to other PCEs. This way the state of all scheduled LSPs
are synchronized among the PCEs. discusses some synchronization issues and considerations,
that are also applicable to the scheduled databases. The scheduled LSP can also be initiated by PCE itself. In
case of implementing PCE-initiated scheduled LSP, the stateful PCE
shall check the network resource availability for the traffic and
computes a path for the scheduled LSP and initiate a scheduled LSP
at the PCC and synchronize the scheduled LSP to
other PCEs. Note that, the PCC could be notified immediately or at the
starting time of the scheduled LSP based on the local policy. In case of
former SCHED-LSP-ATTRIBUTE MUST be included in the message where as for
the latter SCHED-LSP-ATTRIBUTE SHOULD NOT be included.
In both modes, for activation of scheduled LSPs, the PCC could
initiate the setup of scheduled LSP at the start time by itself or wait for the PCE
to update the PCC to initiate the setup of LSP. Similarly on the
scheduling usage expires, the PCC could initiate the removal by itself or wait for
the PCE to request the removal of the LSP. This is based on the Flag
set in SCHED-LSP-ATTRIBUTE TLV. The state of the scheduled LSP is synchronized to other PCEs
using the existing mechanism in and .For a scheduled LSP, a user configures it with an arbitrary
scheduling duration time from 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.In addition to LSP Scheduling at an arbitrary time period, there
are also periodical LSP Scheduling.A periodical LSP Scheduling represents Scheduling LSP every time
interval. It has a scheduling duration such as [Ta, Tb], a number of
repeats such as 10 (repeats 10 times), and a repeat cycle/time
interval such as a week (repeats every week). The scheduling
interval: "[Ta, Tb] repeats n times with repeat cycle C" represents
n+1 scheduling intervals as follows:[Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC]When an LSP is configured with a scheduling interval such as
"[Ta, Tb] repeats 10 times with a repeat cycle a week" (representing
11 scheduling intervals), a path satisfying the constraints for the
LSP in each of the scheduling intervals represented by the
periodical scheduling interval is computed and the LSP along the
path is set up to carry traffic in each of the scheduling
intervals.In addition to the basic LSP scheduling at an arbitrary time
period, another option is elastic time intervals, which is
represented as within -P and Q, where P and Q is an amount of time
such as 300 seconds. P is called elastic range lower bound and Q
is called elastic range upper bound.For a simple time interval such as [Ta, Tb] with an elastic
range, elastic time interval: "[Ta, Tb] within -P and Q" means a
time period from (Ta+X) to (Tb+X), where -P <= X <= Q. Note
that both Ta and Tb may be shifted by the same 'X'.When an LSP is configured with elastic time interval "[Ta, Tb]
within -P and Q", a path is computed such that the path satisfies
the constraints for the LSP in the time period from (Ta+X) to
(Tb+X) and |X| is the minimum value from 0 to max(P, Q). That is,
[Ta+X, Tb+X] is the time interval closest to time interval
[Ta, Tb] within the elastic range. The LSP along the path is set
up to carry traffic in the time period from (Ta+X) to (Tb+X).Similarly, for a recurrent time interval with an elastic range,
elastic time interval: "[Ta, Tb] repeats n times with repeat cycle
C within -P and Q" represents n+1 simple elastic time intervals as
follows:[Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn]
where -P <= Xi <= Q, i = 0, 1, 2, ..., n. If a user wants to keep the same repeat cycle between any two
adjacent time intervals, elastic time interval: "[Ta, Tb] repeats
n times with repeat cycle C within -P and Q SYNC" may be used,
which represents n+1 simple elastic time intervals as
follows:[Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X]
where -P <= X <= Q. Besides the stated time scheduling, a user may want to have
some graceful periods for each or some of the time intervals for
the LSP. Two graceful periods may be configured for a time
interval. One is the graceful period before the time interval,
called grace-before, which extends the lifetime of the LSP for
grace-before (such as 30 seconds) before the time interval. The
other is the one after the time interval, called grace-after,
which extends the lifetime of the LSP for grace-after (such as 60
seconds) after the time interval.When an LSP is configured with a simple time interval such as
[Ta, Tb] with graceful periods such as grace-before GB and
grace-after GA, a path is computed such that the path satisfies
the constraints for the LSP in the time period from Ta to Tb. The
LSP along the path is set up to carry traffic in the time period
from (Ta-GB) to (Tb+GA). During graceful periods from (Ta-GB) to
Ta and from Tb to (Tb+GA), the LSP is up to carry traffic (maybe
in best effort).In order to realize PCC-Initiated scheduled LSP in a centralized
network environment, a PCC has to separate the setup of a LSP into two
steps. The first step is to request/delegate and get a LSP but not signal it
over the network. The second step is to signal the scheduled LSP over
the LSRs (Labeled switched Router) at its starting time.For PCC-Initiated scheduled LSPs, a PCC can delegate the scheduled LSP by sending a path computation
report (PCRpt) message by including its demanded
resources with the scheduling information to a stateful
PCE. Note the PCC MAY use the PCReq/PCRep with scheduling information before delegating.Upon receiving the delegation via PCRpt message, the stateful PCE
computes the path for the scheduled LSP per its starting time and
duration based on the network resource availability stored in
scheduled TED (see section 4.1).The stateful PCE will send a PCUpd
message with the scheduled path information as well as the scheduled resource
information for the scheduled LSP to the PCC. The PCE SHOULD add the scheduled LSP into its
scheduled LSP DB and update its scheduled TED. The PCE MUST also synchronize to other PCEs within the network if
there is any, so as to keep their scheduling information
synchronized as per . For PCE-Initiated Scheduled LSP, the stateful PCE can compute a
path for the scheduled LSP per requests from network management
systems automatically based on the network resource availability in
the scheduled TED, send a PCInitiate message with the
path information back to the PCC. Based on the local policy, the PCInitiate message
could be sent immediately to ask PCC to create a scheduled LSP (as per this document) or the PCInitiate message
could be sent at the start time to the PCC to create a normal LSP (as per ). In both modes:The stateful PCE is required to update its local scheduled LSP
DB and scheduled TED with the scheduled LSP. Besides, it shall
send a PCRpt message with the scheduled LSP to other PCEs within
the network, so as to achieve the scheduling traffic engineering
information synchronization as per .Upon receiving the PCUpd message or PCInitiate message for the scheduled
LSP from PCEs with a found path, the PCC knows that it is a
scheduled path for the LSP and does not trigger signaling for the LSP
setup on LSRs immediately.The stateful PCE can update the Scheduled LSP
parameters on any network events using the PCUpd message to PCC. These
changes are also synchronized to other PCEs as per .Based on the configuration (and the C flag in scheduled TLVs), when it is time (i.e., at the start time) for the LSP to be set
up, either the PCC triggers the LSP to be signaled or the delegated PCE sends a PCUpd message to the head
end LSR providing the updated path to be signaled (with A flag set to indicate LSP activation).After a scheduled LSP is configured, a user may change its
parameters including the requested time as well as the bandwidth.In PCC-Initiated case, the PCC can send a PCRpt message for the
scheduled LSP with updated parameters as well as scheduled information
included in the SCHED-LSP-ATTRIBUTE TLV (see ) or
SCHED-PD-LSP-ATTRIBUTE TLV (see ) carried in the LSP Object. The PCE would
take the updated resources and schedule into considerations and
update the new path for the scheduled LSP to the PCC as well as
synchronize to other PCEs in the network. In case path cannot be
set based on new requirements the same should be conveyed by the
use of empty ERO in the PCEP messages.In PCE-Initiated case, the Stateful PCE would recompute the path based on
updated parameters as well as scheduled information. In case it has
already conveyed to the PCC this information by sending a PCInitiate
message, it should update the path and other scheduling and resource
information by sending a PCUpd message. In any case, the scheduled databases SHALL be updated and the PCE
MUST synchronize this information to other PCEs as per .In PCC-Initiated case, based on the configuration (and the C flag in scheduled TLVs), when it is time (i.e., at the start time) for the LSP to be set
up, either the PCC triggers the LSP to be signaled or the delegated PCE sends a PCUpd message to the head
end LSR providing the updated path to be signaled (with A flag set to indicate LSP activation).
The PCC would report the status of the active LSP as per the procedures in and at this time the LSP MUST be considered as part of the LSP-DB.
The A flag MUST be set in the scheduled TLVs to indicate that the LSP is active now. After the scheduled duration expires, based on the C flag, the PCC triggers the
LSP deletion on it self or the delegated PCE sends a PCUpd message to the PCC to delete the LSP as per the procedures in .
In PCE-Initiated case, based on the local policy, if the scheduled LSP is already conveyed to the PCC at the time of creation, the handling of LSP activation and deletion
is handled in the same way as PCC-Initiated case as per the setting of C flag. In other case, the PCE would send the PCInitiate message
at the start time to the PCC to create a normal LSP without the scheduled TLVs and remove the LSP after the duration expires as per .Additionally, the scheduled databases SHALL be updated and synchronization to other PCEs MUST be done as per .After a TCP connection for a PCEP session has been established, a
PCC and a PCE indicates its ability to support LSP scheduling during
the PCEP session establishment phase. For a multiple-PCE
environment, the PCEs should also establish PCEP session and
indicate its ability to support LSP scheduling among PCEP peers. The
Open Object in the Open message contains the STATEFUL-PCE-CAPABILITY
TLV defined in . Note that the STATEFUL-
PCE-CAPABILITY TLV is defined in and
updated in and ". In this document, we define a new
flag bit B (SCHED-LSP-CAPABLITY) flag for the STATEFUL-
PCE-CAPABILITY TLV to indicate the support of LSP scheduling and
another flag bit PD (PD-LSP-CAPABLITY) to indicate the support of
LSP periodical scheduling.If set to 1
by a PCC, the B Flag indicates that the PCC allows LSP
scheduling; if set to 1 by a PCE, the B Flag indicates that the
PCE is capable of LSP scheduling. The B bit MUST be set by both
PCEP peers in order to support LSP scheduling for path
computation.If set to 1 by a
PCC, the PD Flag indicates that the PCC allows LSP scheduling
periodically; if set to 1 by a PCE, the PD Flag indicates that
the PCE is capable of periodical LSP scheduling. The PD bit MUST
be set by both PCEP peers in order to support periodical LSP
scheduling for path computation.The LSP object is defined in . This document add an
optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an
optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP
scheduling.The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object
indicates that this LSP is requesting scheduled parameters while the
SCHED-PD-LSP-ATTRIBUTE TLV indicates that this scheduled LSP is
periodical. The scheduled LSP attribute TLV MUST be present in LSP
Object for each scheduled LSP carried in the PCEP messages. For periodical LSPs, the
SCHED-PD-LSP-ATTRIBUTE TLV can be used in LSP Object for each periodic scheduled LSP carried in the PCEP messages.Only one of these TLV SHOULD be present in the LSP object. In case more than one scheduling TLV is found, the first instance is processed and others ignored.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 SHOULD be included only if both PCEP peers have set
the B (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY
TLV carried in open message.The format of the SCHED-LSP-ATTRIBUTE TLV is shown in the
following figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|C|A| Flags | Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GrB | GrA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elastic-Lower-Bound | Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type of the TLV is [TBD1] and the TLV has a fixed length of
20 octets.The fields in the format are:Following flags are
defined in this document
Set to 1 to indicate 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. Set to 1 to indicate the
PCC is responsible to setup and remove the scheduled LSP based on the
Start-Time and duration. 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). This field MUST be set to
zero on transmission and MUST be ignored on receipt. This value in seconds,
indicates when the scheduled LSP is used to carry traffic and
the corresponding LSP must be setup and activated. The value in seconds,
indicates the duration that the LSP is undertaken by a traffic
flow and the corresponding LSP must be up to carry traffic. At
the expiry of this duration, the LSP is tear down and deleted.
The Start-Time indicates a calendar time (e.g.,2018/12/13
8:29:58), at or before which the scheduled LSP must be set up. The
value of the Start-Time represents the number of seconds since
00:00 hours,Jan 1, 1970 UTC when R bit is set to 0. When R bit is
set to 1, it represents the number of seconds from the current
time.In addition, it contains an non zero grace-before and
grace-after if graceful periods are configured. It includes an non
zero elastic range lower bound and upper bound if there is an
elastic range configured.GrB (Grace-Before -16 bits): The graceful period time
length in seconds before the starting time.GrA (Grace-After -16 bits): The graceful period time length
in seconds after time interval [starting time, starting time +
duration].Elastic-Lower-Bound (16 bits): The maximum amount of time
in seconds that time interval can shift to lower/left.Elastic-Upper-Bound (16 bits): The maximum amount of time
in seconds that time interval can shift to upper/right.The periodical LSP is a special case of LSP scheduling. The
traffic service happens in a series of repeated time intervals.
The SCHED-PD-LSP-ATTRIBUTE TLV can be included as an optional TLV
within the LSP object for this periodical LSP scheduling.This TLV SHOULD be included only if both PCEP peers have set
the B (LSP-SCHEDULING-CAPABILITY bit) and PD (PD-LSP-CAPABLITY
bit) in STATEFUL-PCE-CAPABILITY TLV carried in open message.The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in the
following figure:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|C|A| Flags | Opt | NR | Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repeat-time-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GrB | GrA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elastic-Lower-Bound | Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type of the TLV is [TBD2] and the TLV has a fixed length of
24 octets. The description, format and meaning of the Flags (R, C and A bit),
Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and Elastic-Upper-Bound
fields remains same as SCHED-LSP-ATTRIBUTE TLV.The following fields are new :Indicates options to
repeat.Options = 1: repeat every day;Options = 2: repeat every week;Options = 3: repeat every month;Options = 4: repeat every year;Options = 5: repeat every Repeat-time-length.The number of repeats.
In each of repeats, LSP carries traffic. If value is
set to 0xFFFF, it indicates forever.This field MUST be set to
zero on transmission and MUST be ignored on receipt. The time length in
seconds after which LSP starts to carry traffic again for the
Duration.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 . Each LSP State
Report in a PCRpt message contains the actual LSP's path,
bandwidth, operational and administrative status, etc. An LSP
Status Report carried on a PCRpt message is also used in
delegation or revocation of control of an LSP to/from a PCE. In case of
scheduled LSP, the scheduled TLVs MUST be carried in the LSP
object and the ERO conveys the intended path for the scheduled LSP. The scheduled LSP
MUST be delegated to a PCE. This message is also
used to synchronize the scheduled LSPs to other PCE as described in and . 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 . Each
LSP Update Request on a PCUpd message contains all LSP
parameters that a PCE wishes to be set for a given LSP. In case of
scheduled LSP, the scheduled TLVs MUST be carried in the LSP
object and the ERO conveys the intended path for the scheduled LSP. In case
no path can be found, an empty ERO is used. The A bit is used in PCUpd message to indicate the activation of the scheduled LSP in
case the PCE is responsible for the activation (as per the C bit).
This message is also
used to synchronize the scheduled LSPs to other PCE as described in .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 .
In case of scheduled LSP, based on the local policy, PCE MAY convey the scheduled LSP to the PCC by including
the scheduled TLVs in the LSP object. Or the PCE would initiate the LSP only at the start time of the
scheduled LSP as per the without the use of scheduled TLVs.The Path Computation Request (PCReq) message is a PCEP message sent
by a PCC to a PCE to request a path computation and it may
contain the LSP object to identify the LSP for which the path
computation is requested. In case of scheduled LSP, the scheduled TLVs
MUST be carried in the LSP object in PCReq message to request the
path computation based on scheduled TED and LSP-DB. A PCC MAY use
PCReq message to obtain the scheduled path before delegating the
LSP.The Path Computation Reply (PCRep) message is a PCEP message sent by a PCE to a PCC in reply to a path
computation request and it may
contain the LSP object to identify the LSP for which the path
is computed. A PCRep message can contain either a set of
computed paths if the request can be satisfied, or a negative
reply if not. The negative reply may indicate the reason why no
path could be found. In case of scheduled LSP, the scheduled TLVs
MUST be carried in the LSP object in PCRep message to indicate the
path computation based on scheduled TED and LSP-DB. A PCC and PCE MAY use
PCReq and PCRep message to obtain the scheduled path before delegating the
LSP.The Path Computation Error (PCErr) message is a PCEP message as described in 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 and
wherever appropriate.The PCEP extensions for scheduling MUST NOT be used if one or both
PCEP speakers have not set the corresponding bits in the STATEFUL-PCE-CAPABILITY TLV in
their respective OPEN message. If the PCEP speaker
supports the extensions of this specification but did not advertise
this capability, then upon receipt of LSP object with the 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 terminate the PCEP session. As per Section 7.1 of , a legacy PCEP implementation that does not understand this specification, would consider the scheduled TLVs as unknown and ignore them.If the PCC
decides that the scheduling parameters proposed in the PCUpd/PCInitiate message are
unacceptable, it MUST report this error by including the
LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable
parameters" in the LSP object (with scheduled TLVs) in the PCRpt message to the PCE.The scheduled TLVs MUST be included in the LSP object for the scheduled LSPs, if the TLV is
missing, the receiving PCEP speaker MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value TBD5 (Scheduled TLV
missing).This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED-
LSP-ATTRIBUTE TLV which does not add any new security concerns beyond
those discussed in and . But 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. Thus, such deployment should employ suitable PCEP security mechanisms like TCP Authentication Option (TCP-AO) or
. The procedure based on Transport Layer Security (TLS) in
is considered a security enhancement and thus is much better
suited for the sensitive service-aware information.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. An implementation SHOULD allow the operator to view the capability
defined in this document. To serve this purpose, the PCEP YANG
module could be extended.Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in .Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
.Mechanisms defined in this document do not imply any new
requirements on other protocols.Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in
.This document defines the following new PCEP TLV. 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 documentThis document defines new bits in the Flags field in the
STATEFUL-PCE-CAPABILITY TLV in the OPEN object. IANA
maintains a sub-registry "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the
"Path Computation Element Protocol (PCEP) Numbers" registry. IANA is requested
to make the following allocations from this sub-registry.The following values are defined in this document:Bit Description Reference
TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document
TBD4 PD-LSP-CAPABLITY (PD-bit) This documentIANA is requested to create a new sub-registry, named "Schedule TLVs Flag Field",
within the "Path Computation Element Protocol (PCEP)
Numbers" registry to manage the Flag field in the SCHED-LSP-ATTRIBUTE and SCHED-PD-LSP-ATTRIBUTE TLVs.
New values are
assigned by Standards Action . Each bit should be tracked
with the following qualities:
Bit number (counting from bit 0 as the most significant bit)Capability descriptionDefining RFCThe following values are defined in this document:
Bit Description Reference
0 R-bit This document
1 C-bit This document
2 A-bit This documentIANA 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
The authors of this document would also like to thank Rafal
Szarecki, Adrian Farrel, Cyril Margaria for the review and comments.As for a stateful PCE, it maintains a database of LSPs (LSP-DB) that
are active in the network, so as to reveal the available network
resources and place new LSPs more cleverly.With the scheduled LSPs, they are not activated while creation, but
should be considered when operating future path computation. Hence, a
scheduled LSP Database (SLSP-DB) is suggested to maintain all scheduled
LSP information.The information of SLSP-DB MUST be shared and synchronized among all
PCEs within the centralized network by using PCRpt and PCUpd message with
scheduled LSP information as per the mechanism described in . 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. Xufeng Liu
Ericsson
USA
Email: xliu@kuatrotech.com
Mehmet Toy
Verizon
USA
Email: mehmet.toy@verizon.com
Vic Liu
China Mobile
No.32 Xuanwumen West Street, Xicheng District
Beijing, 100053
China
Email: liu.cmri@gmail.com
Lei Liu
Fujitsu
USA
Email: lliu@us.fujitsu.com
Khuzema Pithewan
Infinera
Email: kpithewan@infinera.com
Zitao Wang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: wangzitao@huawei.com
Xian Zhang
Huawei Technologies
Research Area F3-1B,
Huawei Industrial Base,
Shenzhen, 518129, China
Email: zhang.xian@huawei.com