idnits 2.17.1 draft-ietf-pce-stateful-pce-lsp-scheduling-26.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 8, 2020) is 1357 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Ta' is mentioned on line 356, but not defined == Missing Reference: 'Tb' is mentioned on line 356, but not defined == Missing Reference: 'TBD1' is mentioned on line 594, but not defined == Missing Reference: 'TBD2' is mentioned on line 712, but not defined ** Downref: Normative reference to an Informational RFC: RFC 8413 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-14 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group H. Chen, Ed. 3 Internet-Draft Futurewei 4 Intended status: Standards Track Y. Zhuang, Ed. 5 Expires: February 9, 2021 Q. Wu 6 Huawei 7 D. Ceccarelli 8 Ericsson 9 August 8, 2020 11 PCEP Extensions for LSP scheduling with stateful PCE 12 draft-ietf-pce-stateful-pce-lsp-scheduling-26 14 Abstract 16 This document defines a set of extensions needed to the stateful Path 17 Computation Element (PCE) communication Protocol (PCEP), so as to 18 enable Labeled Switched Path (LSP) path computation, activation, 19 setup and deletion based on scheduled time intervals for the LSP and 20 the actual network resource usage in a centralized network 21 environment as stated in RFC 8413. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 9, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions used in this document . . . . . . . . . . . . . . 4 59 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Motivation and Objectives . . . . . . . . . . . . . . . . . . 5 61 4. Procedures and Mechanisms . . . . . . . . . . . . . . . . . . 5 62 4.1. LSP Scheduling Overview . . . . . . . . . . . . . . . . . 5 63 4.2. Support of LSP Scheduling . . . . . . . . . . . . . . . . 7 64 4.2.1. LSP Scheduling . . . . . . . . . . . . . . . . . . . 7 65 4.2.2. Periodical LSP Scheduling . . . . . . . . . . . . . . 7 66 4.3. Scheduled LSP creation . . . . . . . . . . . . . . . . . 9 67 4.4. Scheduled LSP Modifications . . . . . . . . . . . . . . . 10 68 4.5. Scheduled LSP activation and deletion . . . . . . . . . . 11 69 5. PCEP Objects and TLVs . . . . . . . . . . . . . . . . . . . . 11 70 5.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 11 71 5.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.2.1. SCHED-LSP-ATTRIBUTE TLV . . . . . . . . . . . . . . . 12 73 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV . . . . . . . . . . . . . 15 74 6. The PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 17 75 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 17 76 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 17 77 6.3. The PCInitiate Message . . . . . . . . . . . . . . . . . 17 78 6.4. The PCReq message . . . . . . . . . . . . . . . . . . . . 17 79 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 18 80 6.6. The PCErr Message . . . . . . . . . . . . . . . . . . . . 18 81 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 9. Manageability Consideration . . . . . . . . . . . . . . . . . 20 84 9.1. Control of Function and Policy . . . . . . . . . . . . . 20 85 9.2. Information and Data Models . . . . . . . . . . . . . . . 20 86 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 87 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20 88 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 89 9.6. Impact On Network Operations . . . . . . . . . . . . . . 21 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 21 92 10.1.1. Opt Field in SCHED-PD-LSP-ATTRIBUTE TLV . . . . . . 21 93 10.1.2. Schedule TLVs Flag Field . . . . . . . . . . . . . . 21 94 10.2. STATEFUL-PCE-CAPABILITY TLV Flag field . . . . . . . . . 22 95 10.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 22 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 99 12.2. Informative References . . . . . . . . . . . . . . . . . 24 100 Appendix A. Contributors Addresses . . . . . . . . . . . . . . . 25 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 103 1. Introduction 105 The Path Computation Element Protocol (PCEP) defined in [RFC5440] is 106 used between a Path Computation Element (PCE) and a Path Computation 107 Client (PCC) (or other PCE) to enable path computation of Multi- 108 protocol Label Switching (MPLS) Traffic Engineering Label Switched 109 Paths (TE LSPs). 111 [RFC8231] describes a set of extensions to PCEP to provide stateful 112 control. A stateful PCE has access to not only the information 113 carried by the network's Interior Gateway Protocol (IGP) but also the 114 set of active paths and their reserved resources for its 115 computations. The additional state allows the PCE to compute 116 constrained paths while considering individual LSPs and their 117 interactions. 119 Traditionally, the usage and allocation of network resources, 120 especially bandwidth, can be supported by a Network Management System 121 (NMS) operation such as path pre-establishment. However, this does 122 not provide efficient usage of network resources. The established 123 paths reserve the resources forever, which cannot be used by other 124 services even when they are not used for transporting any service. 125 [RFC8413] then provides a framework that describes and discusses the 126 problem, and defines an appropriate architecture for the scheduled 127 reservation of TE resources. 129 The scheduled reservation of TE resources allows network operators to 130 reserve resources in advance according to the agreements with their 131 customers, and allows them to transmit data about scheduling such as 132 a specified start time and duration, for example for a scheduled bulk 133 data replication between data centers. It enables the activation of 134 bandwidth usage at the time the service is really being used while 135 letting other services use it when this service is not using it. The 136 requirement of scheduled LSP provisioning is mentioned in [RFC8231] 137 and [RFC7399]. Also, for deterministic networks 138 [I-D.ietf-detnet-architecture], the scheduled LSP or temporal LSP can 139 provide a better network resource usage for guaranteed links. This 140 idea can also be applied in segment routing [RFC8402] to schedule the 141 network resources over the whole network in a centralized manner as 142 well. 144 With this in mind, this document defines a set of extensions needed 145 to PCEP used for stateful PCEs so as to enable LSP scheduling for 146 path computation and LSP setup/deletion based on the actual network 147 resource usage duration of a traffic service. A scheduled LSP is 148 characterized by a starting time and a duration. When the end of the 149 LSP life is reached, it is deleted to free up the resources for other 150 LSPs (scheduled or not). 152 2. Conventions used in this document 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 2.1. Terminology 162 The following terminology is re-used from existing PCE documents. 164 o Active Stateful PCE [RFC8051] 166 o Delegation [RFC8051] 168 o PCE-Initiated LSP [RFC8281] 170 o PCC [RFC5440] 172 o PCE [RFC5440] 174 o TE LSP [RFC5440] 176 o TED [RFC5440] 178 o LSP-DB [RFC8051] 180 In addition, this document defines the following terminologies. 182 Scheduled TE LSP (or Scheduled LSP for short): an LSP with the 183 scheduling attributes, that carries traffic flow demand at a 184 starting time and lasts for a certain duration (or from a starting 185 time to an ending time, where the ending time is the starting time 186 plus the duration). A scheduled LSP is also called a temporal 187 LSP. The PCE operates path computation per LSP availability for 188 the required time and duration. 190 Scheduled LSP-DB: a database of scheduled LSPs. 192 Scheduled TED: Traffic engineering database with the awareness of 193 scheduled resources for TE. This database is generated by the PCE 194 from the information in TED and scheduled LSP-DB and allows 195 knowing, at any time, the expected amount of available resources 196 (discounting the possibility of failures in the future). 198 Starting time (start-time): This value indicates when the scheduled 199 LSP is used and the corresponding LSP must be setup and active. 200 In other time (i.e., before the starting time or after the 201 starting time plus Duration), the LSP can be inactive to include 202 the possibility of the resources being used by other services. 204 Duration: This value indicates the length of time that the LSP is 205 undertaken by a traffic flow and the corresponding LSP must be 206 setup and active. At the end of which, the LSP is torn down and 207 removed from the database. 209 3. Motivation and Objectives 211 A stateful PCE [RFC8231] can support better efficiency by using LSP 212 scheduling described in the use case of [RFC8051]. This requires the 213 PCE to maintain the scheduled LSPs and their associated resource 214 usage, e.g. bandwidth for Packet-switched network, as well as have 215 the ability to trigger signaling for the LSP setup/tear-down at the 216 correct time. 218 Note that existing configuration tools can be used for LSP 219 scheduling, but as highlighted in section 3.1.3 of [RFC8231] as well 220 as discussions in [RFC8413], doing this as a part of PCEP in a 221 centralized manner, has obvious advantages. 223 This document provides a set of extensions to PCEP to enable LSP 224 scheduling for LSP creation/deletion under the stateful control of a 225 PCE and according to traffic service requests from customers, so as 226 to improve the usage of network resources. 228 4. Procedures and Mechanisms 230 4.1. LSP Scheduling Overview 232 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for 233 customers' traffic services at its actual usage time, so as to 234 improve the network resource utilization efficiency. 236 For stateful PCE supporting LSP scheduling, there are two types of 237 LSP databases used in this document. One is the LSP-DB defined in 238 PCEP [RFC8231], while the other is the scheduled LSP database (SLSP- 239 DB, see section 6). The SLSP-DB records scheduled LSPs and is used 240 in conjunction with the TED and LSP-DB. Note that the two types of 241 LSP databases can be implemented in one physical database or two 242 different databases. This is an implementation matter and this 243 document does not state any preference. 245 Furthermore, a scheduled TED can be generated from the scheduled LSP- 246 DB, LSP-DB and TED to indicate the network links and nodes with 247 resource availability information for now and future. The scheduled 248 TED MUST be maintained by all PCEs within the network environment. 250 In case of implementing PCC-initiated scheduled LSPs, when delegating 251 a scheduled LSP, a PCC MUST include its scheduling parameters (see 252 Section 5.2.1), including the starting time and the duration using 253 PCRpt message. Since the LSP is not yet signaled, at the time of 254 delegation the LSP would be in down state. Upon receiving the 255 delegation of the scheduled LSP, a stateful PCE MUST check whether 256 the parameters are valid. If they are valid, it SHALL check the 257 scheduled TED for the network resource availability on network nodes 258 and compute a path for the LSP with the scheduling information and 259 update to the PCC as per the active stateful PCE techniques 260 [RFC8231]. 262 Note that the active stateful PCE can update to the PCC with the path 263 for the scheduled LSP at any time. However, the PCC should not 264 signal the LSP over the path on receiving these messages since the 265 path is not active yet; PCC signals the LSP at the starting time. 267 In case of multiple PCEs within a single domain, the PCE would need 268 to synchronize their scheduling information with other PCEs within 269 the domain. This could be achieved by proprietary database 270 synchronization techniques or via a possible PCEP extension [I- 271 D.litkowski-pce-state-sync]. The technique used to synchronize SLSP- 272 DB is out of scope for this document. When the scheduling 273 information is out of synchronization among some PCEs, some of 274 scheduled LSPs may not be set up successfully. 276 The scheduled LSP can also be initiated by a PCE itself. In case of 277 implementing PCE-initiated scheduled LSP, the stateful PCE SHALL 278 check the network resource availability for the traffic and compute a 279 path for the scheduled LSP and initiate a scheduled LSP at the PCC 280 and synchronize the scheduled LSP to other PCEs. Note that, the PCC 281 could be notified immediately or at the starting time of the 282 scheduled LSP based on the local policy. In the former case, the 283 SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the 284 message whereas, for the latter the SCHED-LSP-ATTRIBUTE TLV SHOULD 285 NOT be included. Either way the synchronization to other PCEs MUST 286 be done when the scheduled LSP is created. 288 In both modes, for activation of scheduled LSPs, the PCC MUST 289 initiate the setup of scheduled LSP at the start time. Similarly on 290 scheduled usage expiry, the PCC MUST initiate the removal of the LSP 291 based on the Flag set in SCHED-LSP-ATTRIBUTE TLV. 293 4.2. Support of LSP Scheduling 295 4.2.1. LSP Scheduling 297 For a scheduled LSP, a user configures it with an arbitrary 298 scheduling duration from time Ta to time Tb, which may be represented 299 as [Ta, Tb]. 301 When an LSP is configured with arbitrary scheduling duration [Ta, 302 Tb], a path satisfying the constraints for the LSP in the scheduling 303 duration is computed and the LSP along the path is set up to carry 304 traffic from time Ta to time Tb. 306 4.2.2. Periodical LSP Scheduling 308 In addition to LSP Scheduling at an arbitrary time period, there are 309 also periodical LSP Scheduling. 311 A periodical LSP Scheduling means an LSP has multiple time intervals 312 and the LSP is set up to carry traffic in every time interval. It 313 has a scheduling duration such as [Ta, Tb], a number of repeats such 314 as 10 (repeats 10 times), and a repeat cycle/time interval such as a 315 week (repeats every week). The scheduling interval: "[Ta, Tb] 316 repeats n times with repeat cycle C" represents n+1 scheduling 317 intervals as follows: 319 [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC] 321 When an LSP is configured with a scheduling interval such as "[Ta, 322 Tb] repeats 10 times with a repeat cycle a week" (representing 11 323 scheduling intervals), a path satisfying the constraints for the LSP 324 in every interval represented by the periodical scheduling interval 325 is computed once. Note that the path computed for one recurrence may 326 be different from the path for another recurrence. And then the LSP 327 along the path is set up to carry traffic in each of the scheduling 328 intervals. If there is no path satisfying the constraints for some 329 of the intervals, the LSP MUST NOT be set up at all. It MUST 330 generate a PCEP Error (PCErr) with Error-type = 29 (Path computation 331 failure) and Error-value = TBD7 (Path could not be found for some 332 intervals). 334 4.2.2.1. Elastic Time LSP Scheduling 336 In addition to the basic LSP scheduling at an arbitrary time period, 337 another option is elastic time intervals, which is represented as 338 within -P and Q, where P and Q is an amount of time such as 300 339 seconds. P is called elastic range lower bound and Q is called 340 elastic range upper bound. 342 For a simple time interval such as [Ta, Tb] with an elastic range, 343 elastic time interval: "[Ta, Tb] within -P and Q" means a time period 344 from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb 345 are shifted by the same 'X'. This elastic time interval is suitable 346 for the case where a user wants to have a scheduled LSP up to carry 347 the traffic in time interval [Ta, Tb] and has some flexibility on 348 shifting the time interval a little bit such as up to P seconds 349 earlier/left or some time such as up to Q seconds later/right. 351 When an LSP is configured with elastic time interval "[Ta, Tb] within 352 -P and Q", a path is computed such that the path satisfies the 353 constraints for the LSP in the time period from (Ta+Xv) to (Tb+Xv) 354 and an optimization is performed on Xv from -P to Q. The 355 optimization makes [Ta+Xv, Tb+Xv] to be the time interval closest to 356 time interval [Ta, Tb] within the elastic range. The LSP along the 357 path is set up to carry traffic in the time period from (Ta+Xv) to 358 (Tb+Xv). 360 Similarly, for a recurrent time interval with an elastic range, 361 elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C 362 within -P and Q" represents n+1 simple elastic time intervals as 363 follows: 365 [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn] 366 where -P <= Xi <= Q, i = 0, 1, 2, ..., n. 368 If a user wants to keep the same repeat cycle between any two 369 adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n 370 times with repeat cycle C within -P and Q SYNC" may be used, which 371 represents n+1 simple elastic time intervals as follows: 373 [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X] 374 where -P <= X <= Q. 376 4.2.2.2. Grace Periods 378 Besides the stated time scheduling, a user may want to have some 379 grace periods (short for graceful time periods) for each or some of 380 the time intervals for the LSP. Two grace periods may be configured 381 for a time interval. One is the grace period before the time 382 interval, called grace-before, which extends the lifetime of the LSP 383 for grace-before (such as 30 seconds) before the time interval. The 384 other is the one after the time interval, called grace-after, which 385 extends the lifetime of the LSP for grace-after (such as 60 seconds) 386 after the time interval. Note that no network resources such as link 387 bandwidth will be reserved for the LSP during the grace periods. 389 When an LSP is configured with a simple time interval such as [Ta, 390 Tb] with grace periods such as grace-before GB and grace-after GA, a 391 path is computed such that the path satisfies the constraints for the 392 LSP in the time period from Ta to Tb. The LSP along the path is set 393 up to carry traffic in the time period from (Ta-GB) to (Tb+GA). 394 During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the 395 LSP is up to carry traffic in best effort. 397 4.3. Scheduled LSP creation 399 In order to realize PCC-Initiated scheduled LSPs in a centralized 400 network environment, a PCC MUST separate the setup of an LSP into two 401 steps. The first step is to request/delegate and get an LSP but not 402 signal it over the network. The second step is to signal the 403 scheduled LSP over the LSRs (Label Switching Router) at its starting 404 time. 406 For PCC-Initiated scheduled LSPs, a PCC MUST delegate the scheduled 407 LSP by sending a path computation report (PCRpt) message by including 408 its demanded resources with the scheduling information to a stateful 409 PCE. Note the PCC MAY use the PCReq/PCRep with scheduling 410 information before delegating. 412 Upon receiving the delegation via PCRpt message, the stateful PCE 413 MUST compute a path for the scheduled LSP per its starting time and 414 duration based on the network resource availability stored in 415 scheduled TED (see Section 4.1). 417 The stateful PCE will send a PCUpd message with the scheduled path 418 information as well as the scheduled resource information for the 419 scheduled LSP to the PCC. The stateful PCE MUST update its local 420 scheduled LSP-DB and scheduled TED with the scheduled LSP and would 421 need to synchronize the scheduling information with other PCEs in the 422 domain. 424 For PCE-Initiated Scheduled LSP, the stateful PCE MUST compute a path 425 for the scheduled LSP per requests from network management systems 426 automatically based on the network resource availability in the 427 scheduled TED and send a PCInitiate message with the path information 428 back to the PCC. Based on the local policy, the PCInitiate message 429 could be sent immediately to ask the PCC to create a scheduled LSP 430 (as per this document) or the PCInitiate message could be sent at the 431 start time to the PCC to create a normal LSP (as per [RFC8281]). 433 For both PCC-Initiated and PCE-Initiated Scheduled LSPs: 435 o The stateful PCE MUST update its local scheduled LSP-DB and 436 scheduled TED with the scheduled LSP. Additionally, it MUST send 437 a PCRpt message with the scheduled LSP to its next hop PCE along 438 the path of the LSP, so as to achieve the scheduling traffic 439 engineering information synchronization. 441 o Upon receiving the PCUpd message or PCInitiate message for the 442 scheduled LSP from PCEs with a found path, the PCC determines that 443 it is a scheduled path for the LSP by the SCHED-LSP-ATTRIBUTE TLV 444 (see Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see 445 Section 5.2.2) in the message, and does not trigger signaling for 446 the LSP setup on LSRs immediately. 448 o The stateful PCE MUST update the Scheduled LSP parameters on any 449 network events using the PCUpd message to PCC. These changes are 450 also synchronized to other PCEs. 452 o When it is time for the LSP to be set up (i.e., at the start 453 time), based on the value of the C flag for the scheduled TLV, 454 either the PCC MUST trigger the LSP to be signaled or the 455 delegated PCE MUST send a PCUpd message to the head end LSR 456 providing the updated path to be signaled (with A flag set to 457 indicate LSP activation). 459 4.4. Scheduled LSP Modifications 461 After a scheduled LSP is configured, a user may change its parameters 462 including the requested time as well as the bandwidth. For a 463 periodic scheduled LSP, its unused recurrences can be modified or 464 cancelled. For a scheduled LSP that is currently active, its 465 duration (the lifetime) can be reduced. 467 In the PCC-Initiated case, the PCC MUST send the PCE a PCRpt message 468 for the scheduled LSP with updated parameters as well as scheduled 469 information included in the SCHED-LSP-ATTRIBUTE TLV (see 470 Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) 471 carried in the LSP Object. The PCE SHOULD take the updated resources 472 and schedule into considerations and update the new path for the 473 scheduled LSP to the PCC as well as synchronize to other PCEs in the 474 network. In case path cannot be set based on new requirements, the 475 previous LSP will not be impacted and the same MUST be conveyed by 476 the use of empty ERO in the PCEP messages. 478 In the PCE-Initiated case, the Stateful PCE would recompute the path 479 based on updated parameters as well as scheduled information. In 480 case it has already conveyed to the PCC this information by sending a 481 PCInitiate message, it SHOULD update the path and other scheduling 482 and resource information by sending a PCUpd message. 484 4.5. Scheduled LSP activation and deletion 486 In the PCC-Initiated case, when it is time for the LSP to be set up 487 (i.e., at the start time), based on the value of the C flag for the 488 scheduled TLV, either the PCC MUST trigger the LSP to be signaled or 489 the delegated PCE MUST send a PCUpd message to the head end LSR 490 providing the updated path to be signaled (with A flag set to 491 indicate LSP activation). The PCC MUST report the status of the 492 active LSP as per the procedures in [RFC8231] and at this time the 493 LSP MUST be considered as part of the LSP-DB. The A flag MUST be set 494 in the scheduled TLV to indicate that the LSP is active now. After 495 the scheduled duration expires, based on the C flag, the PCC MUST 496 trigger the LSP deletion on itself or the delegated PCE MUST send a 497 PCUpd message to the PCC to delete the LSP as per the procedures in 498 [RFC8231]. 500 In the PCE-Initiated case, based on the local policy, if the 501 scheduled LSP is already conveyed to the PCC at the time of creation, 502 the handling of LSP activation and deletion is handled in the same 503 way as PCC-Initiated case as per the setting of C flag. Otherwise, 504 the PCE MUST send the PCInitiate message at the start time to the PCC 505 to create a normal LSP without the scheduled TLV and remove the LSP 506 after the duration expires as per [RFC8281]. 508 5. PCEP Objects and TLVs 510 5.1. Stateful PCE Capability TLV 512 A PCC and a PCE indicate their ability to support LSP scheduling 513 during their PCEP session establishment phase. For a multiple-PCE 514 environment, the PCEs SHOULD also establish a PCEP session and 515 indicate its ability to support LSP scheduling among PCEP peers. The 516 Open Object in the Open message contains the STATEFUL-PCE-CAPABILITY 517 TLV. Note that the STATEFUL-PCE-CAPABILITY TLV is defined in 518 [RFC8231] and updated in [RFC8281] and [RFC8232]". In this document, 519 we define a new flag bit B (SCHED-LSP-CAPABLITY) in the Flags field 520 of the STATEFUL-PCE-CAPABILITY TLV to indicate the support of LSP 521 scheduling and another flag bit PD (PD-LSP-CAPABLITY) to indicate the 522 support of LSP periodical scheduling. 524 B (LSP-SCHEDULING-CAPABILITY) - 1 bit [Bit Position - TBD3]: If set 525 to 1 by a PCC, the B Flag indicates that the PCC allows LSP 526 scheduling; if set to 1 by a PCE, the B Flag indicates that the 527 PCE is capable of LSP scheduling. The B bit MUST be set by both 528 PCEP peers in order to support LSP scheduling for path 529 computation. 531 PD (PD-LSP-CAPABLITY) - 1 bit: [Bit Position - TBD4] If set to 1 by 532 a PCC, the PD Flag indicates that the PCC allows LSP scheduling 533 periodically; if set to 1 by a PCE, the PD Flag indicates that the 534 PCE is capable of periodical LSP scheduling. Both the PD bit and 535 the B bit MUST be set to 1 by both PCEP peers in order to support 536 periodical LSP scheduling for path computation. If the PD bit or 537 B bit is 0, then the periodical LSP scheduling capability MUST be 538 ignored. 540 5.2. LSP Object 542 The LSP object is defined in [RFC8231]. This document adds an 543 optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an 544 optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP scheduling. 545 The LSP Object for a scheduled LSP MUST NOT include these two TLVs. 546 Only one scheduling, either normal or periodical, is allowed for a 547 scheduled LSP. 549 The presence of the SCHED-LSP-ATTRIBUTE TLV in the LSP object 550 indicates that this LSP is normal scheduling while the SCHED-PD-LSP- 551 ATTRIBUTE TLV indicates that this scheduled LSP is periodical. The 552 SCHED-LSP-ATTRIBUTE TLV MUST be present in LSP Object for each normal 553 scheduled LSP carried in the PCEP messages. The SCHED-PD-LSP- 554 ATTRIBUTE TLV MUST be used in the LSP Object for each periodic 555 scheduled LSP carried in the PCEP messages. 557 Only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP object. 558 In case more than one SCHED-LSP-ATTRIBUTE TLV is found, the first 559 instance is processed and others ignored. The SCHED-PD-LSP-ATTRIBUTE 560 TLV is the same as the SCHED-LSP-ATTRIBUTE TLV regarding to its 561 presence in the LSP object. 563 5.2.1. SCHED-LSP-ATTRIBUTE TLV 565 The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV within 566 the LSP object for LSP scheduling for the requesting traffic service. 568 This TLV MUST NOT be included unless both PCEP peers have set the B 569 (LSP-SCHEDULING-CAPABILITY) bit in STATEFUL-PCE-CAPABILITY TLV 570 carried in the Open message to one. If the TLV is received by a peer 571 when both peers didn't set the B bit to one, the peer MUST generate a 572 PCEP Error (PCErr) with a PCEP-ERROR object having Error-type = 19 573 (Invalid Operation) and Error-value = TBD6 (Attempted LSP Scheduling 574 if the scheduling capability was not advertised). 576 The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1. 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Type (TBD1) | Length | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Flags |R|C|A|G| Reserved (0) | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Start-Time | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Duration | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Figure 1: SCHED-LSP-ATTRIBUTE TLV 594 The type of the TLV is [TBD1] and the TLV has a fixed length of 16 595 octets. 597 The fields in the format are: 599 Flags (8 bits): The following flags are defined in this document 601 R (1 bit): Set to 1 to indicate the Start-Time is a relative 602 time, which is the number of seconds from the current time. 603 The PCEs and PCCs MUST synchronized their clocks when relative 604 time is used. It is RECOMMENDED that the Network Time Protocol 605 [RFC5905] be used to synchronize clocks among them. When the 606 transmission delay from a PCE or PCC to another PCE or PCC is 607 too big such as greater than 1 second, the scheduling interval 608 represented is not accurate if the delay is not considered. 609 Set to 0 to indicate that the 32-bit Start-Time is an absolute 610 time, which is the number of seconds since the epoch. The 611 epoch is 1 January 1970 at 00:00 UTC. It wraps around every 612 2^32 seconds, which is roughly 136 years. The next wraparound 613 will occur in the year 2106. The received Start-Time is 614 considered after the wraparound if the resulting value is less 615 than the current time. In which case, the value of the 32-bit 616 Start-Time is considered as the number of seconds from the time 617 of wraparound (because the Start-Time is always a future time). 619 C (1 bit): Set to 1 to indicate the PCC is responsible to setup 620 and remove the scheduled LSP based on the Start-Time and 621 duration. The PCE holds these responsibilities when the bit is 622 set to zero. 624 A (1 bit): Set to 1 to indicate the scheduled LSP has been 625 activated and should be considered as part of LSP-DB (instead 626 of Scheduled LSP-DB). 628 G (1 bit): Set to 1 to indicate the Grace period is included in 629 the fields GrB/Elastic-Lower-Bound and GrA/Elastic-Upper-Bound; 630 set to 0 indicate the elastic range is included in the fields. 632 Reserved (24 bits): This field MUST be set to zero on transmission 633 and MUST be ignored on receipt. 635 Start-Time (32 bits): This value in seconds, indicates when the 636 scheduled LSP is used to carry traffic and the corresponding LSP 637 MUST be setup and activated. Note that the transmission delay 638 SHOULD be considered when R=1 and the value of Start-Time is 639 small. 641 Duration (32 bits): The value in seconds, indicates the duration 642 that the LSP is undertaken by a traffic flow and the corresponding 643 LSP MUST be up to carry traffic. At the expiry of this duration, 644 the LSP MUST be torn down and deleted. Value of 0 MUST NOT be 645 used in Duration since it does not make any sense. The value of 646 Duration SHOULD be greater than a constant MINIMUM-DURATION 647 seconds, where MINIMUM-DURATION is 5. 649 The Start-Time indicates a time at or before which the scheduled LSP 650 MUST be set up. The value of the Start-Time represents the number of 651 seconds since the epoch when R bit is set to 0. When R bit is set to 652 1, the value of the Start-Time represents the number of seconds from 653 the current time. 655 In addition, it contains G flag set to 1 and a non zero grace-before 656 and grace-after in the fields GrB/Elastic-Lower-Bound and GrA/ 657 Elastic-Upper-Bound if grace periods are configured. It includes G 658 flag set to 0 and a non zero elastic range lower bound and upper 659 bound in the fields if there is an elastic range configured. A TLV 660 can configure a non-zero grace period or elastic range, but it MUST 661 NOT provide both for an LSP. 663 o GrB (Grace-Before -16 bits): The grace period time length in 664 seconds before the starting time. 666 o GrA (Grace-After -16 bits): The grace period time length in 667 seconds after time interval [starting time, starting time + 668 duration]. 670 o Elastic-Lower-Bound (16 bits): The maximum amount of time in 671 seconds that time interval can shift to lower/left. 673 o Elastic-Upper-Bound (16 bits): The maximum amount of time in 674 seconds that time interval can shift to upper/right. 676 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV 678 The periodical LSP is a special case of LSP scheduling. The traffic 679 service happens in a series of repeated time intervals. The SCHED- 680 PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the 681 LSP object for this periodical LSP scheduling. 683 This TLV MUST NOT be included unless both PCEP peers have set the B 684 (LSP-SCHEDULING-CAPABILITY) bit and PD (PD-LSP-CAPABLITY) bit in 685 STATEFUL-PCE-CAPABILITY TLV carried in open message to one. If the 686 TLV is received by a peer when either (or both) bit is zero, the peer 687 MUST generate a PCEP Error (PCErr) with a PCEP-ERROR object having 688 Error-type = 19 (Invalid Operation) and Error-value = TBD6 ( 689 Attempted LSP Scheduling if the scheduling capability was not 690 advertised). 692 The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2. 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Type (TBD2) | Length | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Flags|R|C|A|G| Opt | NR | Reserved (0) | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Start-Time | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Duration | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Repeat-time-length | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Figure 2: SCHED-PD-LSP-ATTRIBUTE TLV 712 The type of the TLV is [TBD2] and the TLV has a fixed length of 20 713 octets. The description, format and meaning of the Flags (R, C, A 714 and G bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and 715 Elastic-Upper-Bound fields remain the same as in the SCHED-LSP- 716 ATTRIBUTE TLV. 718 The following fields are new : 720 Opt: (4 bits) Indicates options to repeat. When a PCE receives a 721 TLV with a unknown Opt value, it does not compute any path for the 722 LSP. It MUST generate a PCEP Error (PCErr) with a PCEP-ERROR 723 object having Error-type = 4 (Not supported object) and Error- 724 value = 4 (Unsupported parameter). 726 Opt = 1: repeat every month; 728 Opt = 2: repeat every year; 730 Opt = 3: repeat every Repeat-time-length. 732 A user may configure a Repeat-time-length in time units weeks, 733 days, hours, minutes, and/or seconds. The value represented by 734 these units is converted to the number of seconds in the TLV. For 735 example, repeat every 2 weeks is equivalent to repeat every 736 Repeat-time-length = 2*7*86,400 (seconds), where 86,400 is the 737 number of seconds per day. 739 NR: (12 bits) The number of repeats. During each repetition, LSP 740 carries traffic. 742 Reserved (8 bits): This field MUST be set to zero on transmission 743 and MUST be ignored on receipt. 745 Repeat-time-length: (32 bits) The time in seconds between the start- 746 time of one repetition and the start-time of the next repetition. 748 6. The PCEP Messages 750 6.1. The PCRpt Message 752 Path Computation State Report (PCRpt) is a PCEP message sent by a PCC 753 to a PCE to report the status of one or more LSPs as per [RFC8231]. 754 Each LSP State Report in a PCRpt message contains the actual LSP's 755 path, bandwidth, operational and administrative status, etc. An LSP 756 Status Report carried on a PCRpt message is also used in delegation 757 or revocation of control of an LSP to/from a PCE. In case of 758 scheduled LSP, a scheduled TLV MUST be carried in the LSP object and 759 the ERO conveys the intended path for the scheduled LSP. The 760 scheduled LSP MUST be delegated to a PCE. 762 6.2. The PCUpd Message 764 Path Computation Update Request (PCUpd) is a PCEP message sent by a 765 PCE to a PCC to update LSP parameters, on one or more LSPs as per 766 [RFC8231]. Each LSP Update Request on a PCUpd message contains all 767 LSP parameters that a PCE wishes to be set for a given LSP. In case 768 of scheduled LSP, a scheduled TLV MUST be carried in the LSP object 769 and the ERO conveys the intended path for the scheduled LSP. In case 770 no path can be found, an empty ERO is used. The A bit is used in 771 PCUpd message to indicate the activation of the scheduled LSP in case 772 the PCE is responsible for the activation (as per the C bit). 774 6.3. The PCInitiate Message 776 An LSP Initiate Request (PCInitiate) message is a PCEP message sent 777 by a PCE to a PCC to trigger LSP instantiation or deletion as per 778 [RFC8281]. In case of scheduled LSP, based on the local policy, PCE 779 MAY convey the scheduled LSP to the PCC by including a scheduled TLV 780 in the LSP object. Or the PCE would initiate the LSP only at the 781 start time of the scheduled LSP as per the [RFC8281] without the use 782 of scheduled TLVs. 784 6.4. The PCReq message 786 The Path Computation Request (PCReq) message is a PCEP message sent 787 by a PCC to a PCE to request a path computation [RFC5440] and it may 788 contain the LSP object [RFC8231] to identify the LSP for which the 789 path computation is requested. In case of scheduled LSP, a scheduled 790 TLV MUST be carried in the LSP object in PCReq message to request the 791 path computation based on scheduled TED and LSP-DB. A PCC MAY use 792 PCReq message to obtain the scheduled path before delegating the LSP. 793 The parameters of the LSP may be changed (refer to Section 4.4). 795 6.5. The PCRep Message 797 The Path Computation Reply (PCRep) message is a PCEP message sent by 798 a PCE to a PCC in reply to a path computation request [RFC5440] and 799 it may contain the LSP object [RFC8231] to identify the LSP for which 800 the path is computed. A PCRep message can contain either a set of 801 computed paths if the request can be satisfied, or a negative reply 802 if not. The negative reply may indicate the reason why no path could 803 be found. In case of scheduled LSP, a scheduled TLV MUST be carried 804 in the LSP object in PCRep message to indicate the path computation 805 based on scheduled TED and LSP-DB. A PCC and PCE MAY use PCReq and 806 PCRep message to obtain the scheduled path before delegating the LSP. 808 6.6. The PCErr Message 810 The Path Computation Error (PCErr) message is a PCEP message as 811 described in [RFC5440] for error reporting. The current document 812 defines new error values for several error types to cover failures 813 specific to scheduling and reuse the applicable error types and error 814 values of [RFC5440] and [RFC8231] wherever appropriate. 816 The PCEP extensions for scheduling MUST NOT be used if one or both 817 PCEP speakers have not set the corresponding bits in the STATEFUL- 818 PCE-CAPABILITY TLV in their respective OPEN message to ones. If the 819 PCEP speaker supports the extensions of this specification but did 820 not advertise this capability, then upon receipt of LSP object with 821 the scheduled TLV, it MUST generate a PCEP Error (PCErr) with Error- 822 type=19 (Invalid Operation) and error-value TBD6 (Attempted LSP 823 Scheduling if the scheduling capability was not advertised), and it 824 SHOULD ignore the TLV. As per Section 7.1 of [RFC5440], a legacy 825 PCEP implementation that does not understand this specification, 826 would consider a scheduled TLV as unknown and ignore them. 828 If the PCC decides that the scheduling parameters proposed in the 829 PCUpd/PCInitiate message are unacceptable, it MUST report this error 830 by including the LSP-ERROR-CODE TLV (Section 7.3.3 of [RFC8231]) with 831 LSP error-value = 4 "Unacceptable parameters" in the LSP object (with 832 the scheduled TLV) in the PCRpt message to the PCE. 834 The scheduled TLV MUST be included in the LSP object for the 835 scheduled LSPs, if the TLV is missing, the receiving PCEP speaker 836 MUST send a PCErr message with Error-type=6 (Mandatory Object 837 missing) and Error-value TBD5 (Scheduled TLV missing). 839 7. Implementation Status 841 [NOTE TO RFC EDITOR : This whole section and the reference to RFC 842 7942 is to be removed before publication as an RFC] 844 This section records the status of known implementations of the 845 protocol defined by this specification at the time of posting of this 846 Internet-Draft, and is based on a proposal described in [RFC7942]. 847 The description of implementations in this section is intended to 848 assist the IETF in its decision processes in progressing drafts to 849 RFCs. Please note that the listing of any individual implementation 850 here does not imply endorsement by the IETF. Furthermore, no effort 851 has been spent to verify the information presented here that was 852 supplied by IETF contributors. This is not intended as, and must not 853 be construed to be, a catalog of available implementations or their 854 features. Readers are advised to note that other implementations may 855 exist. 857 According to [RFC7942], "this will allow reviewers and working groups 858 to assign due consideration to documents that have the benefit of 859 running code, which may serve as evidence of valuable experimentation 860 and feedback that have made the implemented protocols more mature. 861 It is up to the individual working groups to use this information as 862 they see fit". 864 At the time of posting the -09 version of this document, there are no 865 known implementations of this mechanism. It is believed that two 866 vendors/organizations are considering prototype implementations, but 867 these plans are too vague to make any further assertions. 869 8. Security Considerations 871 This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED-LSP- 872 ATTRIBUTE TLV, the security considerations discussed in [RFC5440], 873 [RFC8231], and [RFC8281] continue to apply. In some deployments the 874 scheduling information could provide details about the network 875 operations that could be deemed as extra sensitive. Additionally, 876 snooping of PCEP messages with such data or using PCEP messages for 877 network reconnaissance may give an attacker sensitive information 878 about the operations of the network. A single PCEP message can now 879 instruct a PCC to set up and tear down an LSP every second for a 880 number of times. That single message could have a significant effect 881 on the network. Thus, such deployments SHOULD employ suitable PCEP 882 security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] 883 or [RFC8253], which [RFC8253] is considered a security enhancement 884 and thus is much better suited for the sensitive information. PCCs 885 may also need to apply some form of rate limit to the processing of 886 scheduled LSPs. 888 9. Manageability Consideration 890 9.1. Control of Function and Policy 892 The LSP-Scheduling feature MUST be controlled per tunnel by the 893 active stateful PCE, the values for parameters like starting time, 894 duration SHOULD be configurable by customer applications and based on 895 the local policy at PCE. The suggested default values for starting 896 time and duration are one day in seconds from the current time and 897 one year in seconds respectively. One day has 86,400 seconds. One 898 year has 31,536,000 seconds. 900 When configuring the parameters about time, a user SHOULD consider 901 leap-years and leap-seconds. If a scheduled LSP has a time interval 902 containing a leap-year, the duration of the LSP is 366 days plus the 903 rest of the interval. 905 9.2. Information and Data Models 907 An implementation SHOULD allow the operator to view the information 908 about each scheduled LSP defined in this document. To serve this 909 purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] could be 910 extended. 912 9.3. Liveness Detection and Monitoring 914 Mechanisms defined in this document do not imply any new liveness 915 detection and monitoring requirements in addition to those already 916 listed in [RFC5440]. 918 9.4. Verify Correct Operations 920 Mechanisms defined in this document do not imply any new operation 921 verification requirements in addition to those already listed in 922 [RFC5440]. An implementation SHOULD allow a user to view the 923 information including status about a scheduled LSP through CLI. In 924 addition, it SHOULD check and handle the cases where there is a 925 significant time correction or a clock skew between PCC and PCE. 927 9.5. Requirements On Other Protocols 929 Mechanisms defined in this document do not imply any new requirements 930 on other protocols. 932 9.6. Impact On Network Operations 934 Mechanisms defined in this document do not have any impact on network 935 operations in addition to those already listed in [RFC5440]. 937 10. IANA Considerations 939 10.1. PCEP TLV Type Indicators 941 This document defines the following new PCEP TLVs. IANA maintains a 942 sub-registry "PCEP TLV Type Indicators" in the "Path Computation 943 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 944 the following allocations from this sub-registry. 946 Value Meaning Reference 947 TBD1 SCHED-LSP-ATTRIBUTE This document 948 TBD2 SCHED-PD-LSP-ATTRIBUTE This document 950 10.1.1. Opt Field in SCHED-PD-LSP-ATTRIBUTE TLV 952 IANA is requested to create and maintain a new sub-registry named 953 "SCHED-PD-LSP-ATTRIBUTE TLV Opt field" within the "Path Computation 954 Element Protocol (PCEP) Numbers" registry. Initial values for the 955 sub-registry are given below. New values are assigned by Standards 956 Action [RFC8126]. 958 Value Name Reference 959 ----- ---- ---------- 960 0 Reserved 961 1 REPEAT-EVERY-MONTH This document 962 2 REPEAT-EVERY-YEAR This document 963 3 REPEAT-EVERY-REPEAT-TIME-LENGTH This document 964 4-14 Unassigned 965 15 Reserved 967 10.1.2. Schedule TLVs Flag Field 969 IANA is requested to create a new sub-registry, named "Schedule TLVs 970 Flag Field", within the "Path Computation Element Protocol (PCEP) 971 Numbers" registry. New values are assigned by Standards Action 972 [RFC8126]. Each bit should be tracked with the following qualities: 974 o Bit number (counting from bit 0 as the most significant bit) 976 o Capability description 978 o Defining RFC 979 The following values are defined in this document: 981 Bit Description Reference 982 0-3 Unassigned 983 4 Relative Time (R-bit) This document 984 5 PCC Responsible (C-bit) This document 985 6 LSP Activated (A-bit) This document 986 7 Grace Period Included (G-bit) This document 988 10.2. STATEFUL-PCE-CAPABILITY TLV Flag field 990 This document defines new bits in the Flags field in the STATEFUL- 991 PCE-CAPABILITY TLV in the OPEN object. IANA maintains a sub-registry 992 "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "Path Computation 993 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 994 the following allocations from this sub-registry. 996 The following values are defined in this document: 998 Bit Description Reference 999 TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document 1000 TBD4 PD-LSP-CAPABLITY (PD-bit) This document 1002 10.3. PCEP-Error Object 1004 IANA is requested to allocate the following new error types to the 1005 existing error values within the "PCEP-ERROR Object Error Types and 1006 Values" subregistry of the "Path Computation Element Protocol (PCEP) 1007 Numbers" registry: 1009 Error-Type Meaning 1010 6 Mandatory Object missing 1012 Error-value 1013 TBD5: Scheduled TLV missing 1015 19 Invalid Operation 1017 Error-value 1018 TBD6: Attempted LSP Scheduling if the scheduling 1019 capability was not advertised 1021 29 Path computation failure 1023 Error-value 1024 TBD7: Constraints could not be met for some intervals 1026 11. Acknowledgments 1028 The authors of this document would also like to thank Rafal Szarecki, 1029 Adrian Farrel, Cyril Margaria for the review and comments. 1031 12. References 1033 12.1. Normative References 1035 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1036 Requirement Levels", BCP 14, RFC 2119, 1037 DOI 10.17487/RFC2119, March 1997, 1038 . 1040 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1041 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1042 DOI 10.17487/RFC5440, March 2009, 1043 . 1045 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1046 "Network Time Protocol Version 4: Protocol and Algorithms 1047 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1048 . 1050 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1051 Writing an IANA Considerations Section in RFCs", BCP 26, 1052 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1053 . 1055 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1056 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1057 May 2017, . 1059 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1060 Computation Element Communication Protocol (PCEP) 1061 Extensions for Stateful PCE", RFC 8231, 1062 DOI 10.17487/RFC8231, September 2017, 1063 . 1065 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1066 and D. Dhody, "Optimizations of Label Switched Path State 1067 Synchronization Procedures for a Stateful PCE", RFC 8232, 1068 DOI 10.17487/RFC8232, September 2017, 1069 . 1071 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1072 Computation Element Communication Protocol (PCEP) 1073 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1074 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1075 . 1077 [RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework 1078 for Scheduled Use of Resources", RFC 8413, 1079 DOI 10.17487/RFC8413, July 2018, 1080 . 1082 12.2. Informative References 1084 [I-D.ietf-detnet-architecture] 1085 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1086 "Deterministic Networking Architecture", draft-ietf- 1087 detnet-architecture-13 (work in progress), May 2019. 1089 [I-D.ietf-pce-pcep-yang] 1090 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1091 YANG Data Model for Path Computation Element 1092 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1093 yang-14 (work in progress), July 2020. 1095 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1096 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1097 June 2010, . 1099 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1100 Computation Element Architecture", RFC 7399, 1101 DOI 10.17487/RFC7399, October 2014, 1102 . 1104 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1105 Code: The Implementation Status Section", BCP 205, 1106 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1107 . 1109 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1110 Stateful Path Computation Element (PCE)", RFC 8051, 1111 DOI 10.17487/RFC8051, January 2017, 1112 . 1114 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1115 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1116 Path Computation Element Communication Protocol (PCEP)", 1117 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1118 . 1120 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1121 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1122 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1123 July 2018, . 1125 Appendix A. Contributors Addresses 1127 Dhruv Dhody 1128 Huawei 1129 Divyashree Techno Park, Whitefield 1130 Bangalore, Karnataka 560066 1131 India 1133 Email: dhruv.ietf@gmail.com 1135 Xufeng Liu 1136 Ericsson 1137 USA 1138 Email: xliu@kuatrotech.com 1140 Mehmet Toy 1141 Verizon 1142 USA 1143 Email: mehmet.toy@verizon.com 1145 Vic Liu 1146 China Mobile 1147 No.32 Xuanwumen West Street, Xicheng District 1148 Beijing, 100053 1149 China 1150 Email: liu.cmri@gmail.com 1152 Lei Liu 1153 Fujitsu 1154 USA 1155 Email: lliu@us.fujitsu.com 1157 Khuzema Pithewan 1158 Infinera 1159 Email: kpithewan@infinera.com 1161 Zitao Wang 1162 Huawei 1163 101 Software Avenue, Yuhua District 1164 Nanjing, Jiangsu 210012 1165 China 1167 Email: wangzitao@huawei.com 1168 Xian Zhang 1169 Huawei Technologies 1170 Research Area F3-1B, 1171 Huawei Industrial Base, 1172 Shenzhen, 518129, China 1174 Email: zhang.xian@huawei.com 1176 Authors' Addresses 1178 Huaimo Chen (editor) 1179 Futurewei 1180 Boston, MA 1181 USA 1183 Email: huaimo.chen@futurewei.com 1185 Yan Zhuang (editor) 1186 Huawei 1187 101 Software Avenue, Yuhua District 1188 Nanjing, Jiangsu 210012 1189 China 1191 Email: zhuangyan.zhuang@huawei.com 1193 Qin Wu 1194 Huawei 1195 101 Software Avenue, Yuhua District 1196 Nanjing, Jiangsu 210012 1197 China 1199 Email: bill.wu@huawei.com 1201 Daniele Ceccarelli 1202 Ericsson 1203 Via A. Negrone 1/A 1204 Genova - Sestri Ponente 1205 Italy 1207 Email: daniele.ceccarelli@ericsson.com