| PCE Working Group | H. Chen, Ed. |
| Internet-Draft | Futurewei |
| Intended status: Standards Track | Y. Zhuang, Ed. |
| Expires: February 8, 2021 | Q. Wu |
| Huawei | |
| D. Ceccarelli | |
| Ericsson | |
| August 7, 2020 |
PCEP Extensions for LSP scheduling with stateful PCE
draft-ietf-pce-stateful-pce-lsp-scheduling-23
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.
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 8, 2021.
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 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.
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 can not 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.
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).
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.
The following terminology is re-used from existing PCE documents.
In addition, this document defines the following terminologies.
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.
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 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.
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.
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.
In addition to LSP Scheduling at an arbitrary time period, there are also periodical LSP Scheduling.
[Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC]
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:
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).
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'.
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).
[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.
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+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X]
where -P <= X <= Q.
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:
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 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 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.
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 (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:
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 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 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].
A PCC and a PCE indicates its 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.
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 presence of the SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates that this LSP has scheduled parameters 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 scheduled LSP carried in the PCEP messages. For periodical LSPs, 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.
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. 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).
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:
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 an 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 an 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.
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 the B bit or PD 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).
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 format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2.
The type of the TLV is [TBD2] and the TLV has a fixed length of 20 octets. The description, format and meaning of the Flags (R, C, A and G bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and Elastic-Upper-Bound fields remain the same as in the SCHED-LSP-ATTRIBUTE TLV.
The following fields are new :
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.
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).
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.
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).
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.
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).
[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.
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.
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.
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.
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.
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
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.
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 [RFC5440].
Value Meaning Reference TBD1 SCHED-LSP-ATTRIBUTE This document TBD2 SCHED-PD-LSP-ATTRIBUTE This document
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.
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-DAY This document 2 REPEAT-EVERY-WEEK This document 3 REPEAT-EVERY-MONTH This document 4 REPEAT-EVERY-YEAR This document 5 REPEAT-EVERY-REPEAT-TIME-LENGTH This document 6-14 Unassigned 15 Reserved
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:
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
The following values are defined in this document:
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.
Bit Description Reference TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document TBD4 PD-LSP-CAPABLITY (PD-bit) This document
The following values are defined in this document:
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
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:
The authors of this document would also like to thank Rafal Szarecki, Adrian Farrel, Cyril Margaria for the review and comments.
Dhruv Dhody Huawei Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Xufeng Liu Ericsson USA Email: xliu@kuatrotech.com Mehmet Toy Verizon USA Email: mehmet.toy@verizon.com Vic Liu China Mobile No.32 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