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 [RFC 8231
], while the other is the scheduled LSP database (SLSP-DB). The SLSP-DB records scheduled LSPs and is used in conjunction with the TED and LSP-DB. Note that the two types of LSP databases can be implemented in one physical database or two different databases. This is an implementation matter, 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 the future. The scheduled TED MUST
be maintained by all PCEs within the network environment.
In the case of implementing PCC-initiated scheduled LSPs, when delegating a scheduled LSP, a PCC MUST
include that LSP's scheduling parameters (see Section 5.2.1
), including the start time and duration, using a Path Computation State Report (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, compute a path for the LSP with the scheduling information, and update to the PCC as per the active stateful PCE techniques [RFC 8231
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 after receiving these messages since the path is not active yet; the PCC signals the LSP at the start time.
In the 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 (see [PCE-STATE-SYNC
]). The technique used to synchronize an SLSP-DB is out of scope for this document. When the scheduling information is out of synchronization among some PCEs, some scheduled LSPs may not be set up successfully.
The scheduled LSP can also be initiated by a PCE itself. In the case of implementing a PCE-initiated scheduled LSP, the stateful PCE SHALL
check the network resource availability for the traffic, 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 start time of the scheduled LSP, based on the local policy. In the former case, the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1
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.
In both modes, for activation of scheduled LSPs, the PCC MUST
initiate the setup of the scheduled LSP at the start time. Similarly, on the scheduled usage expiry, the PCC MUST
initiate the removal of the LSP based on the flag set in the SCHED-LSP-ATTRIBUTE TLV.
For a scheduled LSP, a user configures it with an arbitrary scheduling period from time Ta to time Tb, which may be represented as [Ta, Tb].
When an LSP is configured with arbitrary scheduling period [Ta, Tb], a path satisfying the constraints for the LSP in the scheduling period 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 is also periodical LSP scheduling.
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 period such as [Ta, Tb], a number of repeats such as 10 (repeats 10 times), and a repeat cycle/time interval such as a week (repeats every week). The scheduling interval "[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 of a week" (representing 11 scheduling intervals), a path satisfying the constraints for the LSP in every interval represented by the periodical scheduling interval is computed once. Note that the path computed for one recurrence may be different from the path for another recurrence. And then the LSP along the path is set up to carry traffic in each of the scheduling intervals. If there is no path satisfying the constraints for some of the intervals, the LSP MUST NOT
be set up at all. It MUST
generate a PCEP Error (PCErr) with Error-Type = 29 (Path computation failure) and Error-value = 5 (Constraints could not be met for some 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 are amounts of time such as 300 seconds. P is called the elastic range lower bound, and Q is called the 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] 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.
Besides the stated time scheduling, a user may want to have some grace periods (short for "graceful time periods") for each or some of the time intervals for the LSP. Two grace periods may be configured for a time interval. One is the grace period before the time interval, called "Grace-Before", which extends the lifetime of the LSP by an amount of time (such as 30 seconds) before the time interval. The other grace period is after the time interval and is called "Grace-After"; it extends the lifetime of the LSP by an amount of time (such as 60 seconds) after the time interval. Note that no network resources such as link bandwidth will be reserved for the LSP during the grace periods.
When an LSP is configured with a simple time interval such as [Ta, Tb] with grace periods such as Grace-Before GrB and Grace-After GrA, a path is computed such that the path satisfies the constraints for the LSP in the time period from Ta to Tb. The LSP along the path is set up to carry traffic in the time period from (Ta-GrB) to (Tb+GrA). During grace periods from (Ta-GrB) to Ta and from Tb to (Tb+GrA), the LSP is up to carry traffic in best effort.
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 Label Switching Routers (LSRs) at its start time.
For PCC-initiated scheduled LSPs, a PCC MUST
delegate the scheduled LSP by sending a PCRpt message by including its demanded resources with the scheduling information to a stateful PCE. Note that the PCC MAY
use Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages 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 start time and duration based on the network resource availability stored in the scheduled TED (see Section 4.1
The stateful PCE will send a Path Computation Update Request (PCUpd) message with the scheduled path information and 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 a PCE-initiated scheduled LSP, the stateful PCE MUST
automatically compute a path for the scheduled LSP per requests from network management systems, based on the network resource availability in the scheduled TED, and send an LSP Initiate Request (PCInitiate) message with the path information to the PCC. Based on the local policy, the PCInitiate message could be sent immediately to ask the PCC to create a scheduled LSP (as per this document), or the PCInitiate message could be sent at the start time to the PCC to create a normal LSP (as per [RFC 8281
For both PCC-initiated and PCE-initiated Scheduled LSPs:
The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP.
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.
The stateful PCE MUST update the scheduled LSP parameters on any network events using the PCUpd message to the PCC. These changes are also synchronized to other PCEs.
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 the A flag set to indicate LSP activation).
After a scheduled LSP is configured, a user may change its parameters, including the requested time and the bandwidth. For a periodic-scheduled LSP, its unused recurrences can be modified or canceled. 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 consideration, and update the new path for the scheduled LSP to the PCC, and synchronize to other PCEs in the network. If the path cannot be set based on new requirements, the previous LSP will not be impacted, and this MUST
be conveyed by the use of an empty Explicit Route Object (ERO) in the PCEP messages.
In the PCE-initiated case, the stateful PCE would recompute the path based on updated parameters and scheduled information. If it has already conveyed this information to the PCC by sending a PCInitiate message, it SHOULD
update the path and other scheduling and resource information by sending a PCUpd message.
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 the A flag set to indicate LSP activation). The PCC MUST
report the status of the active LSP as per the procedures in [RFC 8231
], and at this time, the LSP MUST
be considered 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 [RFC 8231
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 the PCC-initiated case, as per the setting of the C flag. Otherwise, the PCE MUST
send the PCInitiate message to the PCC at the start time to create a normal LSP without the scheduled TLV and remove the LSP after the duration expires, as per [RFC 8281