idnits 2.17.1 draft-ietf-pce-stateful-pce-lsp-scheduling-22.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 (July 13, 2020) is 1381 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 358, but not defined == Missing Reference: 'Tb' is mentioned on line 358, but not defined == Missing Reference: 'TBD1' is mentioned on line 591, but not defined == Missing Reference: 'TBD2' is mentioned on line 707, but not defined == Unused Reference: 'RFC8232' is defined on line 1052, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 8413 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-13 Summary: 1 error (**), 0 flaws (~~), 7 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: January 14, 2021 Q. Wu 6 Huawei 7 D. Ceccarelli 8 Ericsson 9 July 13, 2020 11 PCEP Extensions for LSP scheduling with stateful PCE 12 draft-ietf-pce-stateful-pce-lsp-scheduling-22 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) scheduling for path computation 19 and LSP setup/deletion based on the actual network resource usage and 20 the duration of a traffic service 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 January 14, 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 . . . . . . . . . . . . . . . . . . . . . . 16 75 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . 17 80 6.6. The PCErr Message . . . . . . . . . . . . . . . . . . . . 18 81 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 9. Manageability Consideration . . . . . . . . . . . . . . . . . 19 84 9.1. Control of Function and Policy . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . 20 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 91 10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 20 92 10.1.1. Opt Field in SCHED-PD-LSP-ATTRIBUTE TLV . . . . . . 20 93 10.1.2. Schedule TLVs Flag Field . . . . . . . . . . . . . . 21 94 10.2. STATEFUL-PCE-CAPABILITY TLV Flag field . . . . . . . . . 21 95 10.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 22 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 99 12.2. Informative References . . . . . . . . . . . . . . . . . 23 100 Appendix A. Contributors Addresses . . . . . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 can not 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 provision is mentioned in [RFC8231] and 137 [RFC7399]. A solution for providing more efficient network resource 138 usage for traffic engineering is desired. Also, for deterministic 139 networks [I-D.ietf-detnet-architecture], the scheduled LSP or 140 temporal LSP can provide a better network resource usage for 141 guaranteed links. This idea can also be applied in segment routing 142 [RFC8402] to schedule the network resources over the whole network in 143 a centralized manner as well. 145 With this in mind, this document defines a set of extensions needed 146 to PCEP used for stateful PCEs so as to enable LSP scheduling for 147 path computation and LSP setup/deletion based on the actual network 148 resource usage duration of a traffic service. A scheduled LSP is 149 characterized by a starting time and a duration. When the end of the 150 LSP life is reached, it is deleted to free up the resources for other 151 LSPs (scheduled or not). 153 2. Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 2.1. Terminology 163 The following terminology is re-used from existing PCE documents. 165 o Active Stateful PCE [RFC8231] 167 o Delegation [RFC8231] 169 o PCE-Initiated LSP [RFC8281] 171 o PCC [RFC5440] 173 o PCE [RFC5440] 175 o TE LSP [RFC5440] 177 o TED [RFC5440] 179 o LSP-DB [RFC8231] 181 In addition, this document defines the following terminologies. 183 Scheduled TE LSP (or Scheduled LSP for short): an LSP with the 184 scheduling attributes, that carries traffic flow demand at a 185 starting time and lasts for a certain duration (or from a starting 186 time to an ending time, where the ending time is the starting time 187 plus the duration). A scheduled LSP is also called a temporal 188 LSP. The PCE operates path computation per LSP availability for 189 the required time and duration. 191 Scheduled LSP-DB: a database of scheduled LSPs. 193 Scheduled TED: Traffic engineering database with the awareness of 194 scheduled resources for TE. This database is generated by the PCE 195 from the information in TED and scheduled LSP-DB and allows 196 knowing, at any time, the amount of available resources (does not 197 include failures in the future). 199 Starting time (start-time): This value indicates when the scheduled 200 LSP is used and the corresponding LSP must be setup and active. 201 In other time (i.e., before the starting time or after the 202 starting time plus Duration), the LSP can be inactive to include 203 the possibility of the resources being used by other services. 205 Duration: This value indicates the length of time that the LSP is 206 undertaken by a traffic flow and the corresponding LSP must be 207 setup and active. At the end of which, the LSP is torn down and 208 removed from the database. 210 3. Motivation and Objectives 212 A stateful PCE [RFC8231] can support better efficiency by using LSP 213 scheduling described in the use case of [RFC8051]. This requires the 214 PCE to maintain the scheduled LSPs and their associated resource 215 usage, e.g. bandwidth for Packet-switched network, as well as have 216 the ability to trigger signaling for the LSP setup/tear-down at the 217 correct time. 219 Note that existing configuration tools can be used for LSP 220 scheduling, but as highlighted in section 3.1.3 of [RFC8231] as well 221 as discussions in [RFC8413], doing this as a part of PCEP in a 222 centralized manner, has obvious advantages. 224 This document provides a set of extensions to PCEP to enable LSP 225 scheduling for LSP creation/deletion under the stateful control of a 226 PCE and according to traffic service requests from customers, so as 227 to improve the usage of network resources. 229 4. Procedures and Mechanisms 231 4.1. LSP Scheduling Overview 233 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for 234 customers' traffic services at its actual usage time, so as to 235 improve the network resource efficient utilization. 237 For stateful PCE supporting LSP scheduling, there are two types of 238 LSP databases used in this document. One is the LSP-DB defined in 239 PCEP [RFC8231], while the other is the scheduled LSP database (SLSP- 240 DB, see section 6). The SLSP-DB records scheduled LSPs and is used 241 in conjunction with the TED and LSP-DB. Note that the two types of 242 LSP databases can be implemented in one physical database or two 243 different databases. This is an implementation matter and this 244 document does not state any preference. 246 Furthermore, a scheduled TED can be generated from the scheduled LSP- 247 DB, LSP-DB and TED to indicate the network links and nodes with 248 resource availability information for now and future. The scheduled 249 TED should be maintained by all PCEs within the network environment. 251 In case of implementing PCC-initiated scheduled LSPs, before a PCC 252 delegates a scheduled LSP, it MAY use the PCReq/PCRep messages to 253 learn the path for the scheduled LSP. A PCC MUST delegate a 254 scheduled LSP with information of its scheduling parameters (see 255 Section 5.2.1), including the starting time and the duration using 256 PCRpt message. Since the LSP is not yet signaled, at the time of 257 delegation the LSP would be in down state. Upon receiving the 258 delegation of the scheduled LSP, a stateful PCE SHALL check the 259 scheduled TED for the network resource availability on network nodes 260 and compute a path for the LSP with the scheduling information and 261 update to the PCC as per the active stateful PCE techniques 262 [RFC8231]. 264 Note that the active stateful PCE can update to the PCC with the path 265 for the scheduled LSP at any time. However, the PCC should not 266 signal the LSP over the path on receiving these messages since the 267 path is not active yet; PCC signals the LSP at the starting time. 269 For a scheduled LSP crossing multiple domains from an ingress domain 270 to an egress domain. There is a PCE responsible for each of these 271 domains. The PCE for the ingress domain is called ingress PCE. The 272 PCE for the egress domain is called egress PCE. The state of the LSP 273 MUST be synchronized among these PCEs. After a path for the LSP is 274 computed, a PCRpt message with the scheduled LSP information MUST be 275 sent to every PCE along the path from the ingress PCE to the egress 276 PCE. After receiving the PCRpt message, the PCE MUST update its 277 SLSP-DB according to the scheduled LSP information. The ingress PCE 278 acting as a PCC sends its next hop PCE the PCRpt message. After 279 receiving the PCRpt message, the next hop PCE acting as a PCC sends 280 its next hop PCE the PCRpt message. This continues until the egress 281 PCE receives the PCRpt message. 283 The scheduled LSP can also be initiated by a PCE itself. In case of 284 implementing PCE-initiated scheduled LSP, the stateful PCE shall 285 check the network resource availability for the traffic and compute a 286 path for the scheduled LSP and initiate a scheduled LSP at the PCC 287 and synchronize the scheduled LSP to other PCEs. Note that, the PCC 288 could be notified immediately or at the starting time of the 289 scheduled LSP based on the local policy. For the former SCHED-LSP- 290 ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the message 291 where as for the latter SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be 292 included. Either way the synchronization to other PCEs should be 293 done when the scheduled LSP is created. 295 In both modes, for activation of scheduled LSPs, the PCC could 296 initiate the setup of scheduled LSP at the start time by itself or 297 wait for the PCE to update the PCC to initiate the setup of an LSP. 298 Similarly on scheduled usage expires, the PCC could initiate the 299 removal by itself or wait for the PCE to request the removal of the 300 LSP. This is based on the Flag set in SCHED-LSP-ATTRIBUTE TLV. 302 4.2. Support of LSP Scheduling 304 4.2.1. LSP Scheduling 306 For a scheduled LSP, a user configures it with an arbitrary 307 scheduling duration from time Ta to time Tb, which may be represented 308 as [Ta, Tb]. 310 When an LSP is configured with arbitrary scheduling duration [Ta, 311 Tb], a path satisfying the constraints for the LSP in the scheduling 312 duration is computed and the LSP along the path is set up to carry 313 traffic from time Ta to time Tb. 315 4.2.2. Periodical LSP Scheduling 317 In addition to LSP Scheduling at an arbitrary time period, there are 318 also periodical LSP Scheduling. 320 A periodical LSP Scheduling means an LSP has multiple time intervals 321 and the LSP is set up to carry traffic in every time interval. It 322 has a scheduling duration such as [Ta, Tb], a number of repeats such 323 as 10 (repeats 10 times), and a repeat cycle/time interval such as a 324 week (repeats every week). The scheduling interval: "[Ta, Tb] 325 repeats n times with repeat cycle C" represents n+1 scheduling 326 intervals as follows: 328 [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC] 330 When an LSP is configured with a scheduling interval such as "[Ta, 331 Tb] repeats 10 times with a repeat cycle a week" (representing 11 332 scheduling intervals), a path satisfying the constraints for the LSP 333 in every interval represented by the periodical scheduling interval 334 is computed once. And then the LSP along the path is set up to carry 335 traffic in each of the scheduling intervals. If there is no path 336 satisfying the constraints for some of the intervals, the LSP will 337 not be set up at all. It SHOULD generate a PCEP Error (PCErr) with 338 Error-type = 29 (Path computation failure) and Error-value = TBD7 339 (Constraints could not be met for some intervals). 341 4.2.2.1. Elastic Time LSP Scheduling 343 In addition to the basic LSP scheduling at an arbitrary time period, 344 another option is elastic time intervals, which is represented as 345 within -P and Q, where P and Q is an amount of time such as 300 346 seconds. P is called elastic range lower bound and Q is called 347 elastic range upper bound. 349 For a simple time interval such as [Ta, Tb] with an elastic range, 350 elastic time interval: "[Ta, Tb] within -P and Q" means a time period 351 from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb 352 are shifted by the same 'X'. 354 When an LSP is configured with elastic time interval "[Ta, Tb] within 355 -P and Q", a path is computed such that the path satisfies the 356 constraints for the LSP in the time period from (Ta+Xv) to (Tb+Xv) 357 and |Xv| is the minimum value for Xv from -P to Q. That is, [Ta+Xv, 358 Tb+Xv] is the time interval closest to time interval [Ta, Tb] within 359 the elastic range. The LSP along the path is set up to carry traffic 360 in the time period from (Ta+Xv) to (Tb+Xv). 362 Similarly, for a recurrent time interval with an elastic range, 363 elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C 364 within -P and Q" represents n+1 simple elastic time intervals as 365 follows: 367 [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn] 368 where -P <= Xi <= Q, i = 0, 1, 2, ..., n. 370 If a user wants to keep the same repeat cycle between any two 371 adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n 372 times with repeat cycle C within -P and Q SYNC" may be used, which 373 represents n+1 simple elastic time intervals as follows: 375 [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X] 376 where -P <= X <= Q. 378 4.2.2.2. Grace Periods 380 Besides the stated time scheduling, a user may want to have some 381 grace periods (short for graceful time periods) for each or some of 382 the time intervals for the LSP. Two grace periods may be configured 383 for a time interval. One is the grace period before the time 384 interval, called grace-before, which extends the lifetime of the LSP 385 for grace-before (such as 30 seconds) before the time interval. The 386 other is the one after the time interval, called grace-after, which 387 extends the lifetime of the LSP for grace-after (such as 60 seconds) 388 after the time interval. 390 When an LSP is configured with a simple time interval such as [Ta, 391 Tb] with grace periods such as grace-before GB and grace-after GA, a 392 path is computed such that the path satisfies the constraints for the 393 LSP in the time period from Ta to Tb. The LSP along the path is set 394 up to carry traffic in the time period from (Ta-GB) to (Tb+GA). 395 During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the 396 LSP is up to carry traffic (maybe in best effort). 398 4.3. Scheduled LSP creation 400 In order to realize PCC-Initiated scheduled LSPs in a centralized 401 network environment, a PCC MUST separate the setup of an LSP into two 402 steps. The first step is to request/delegate and get an LSP but not 403 signal it over the network. The second step is to signal the 404 scheduled LSP over the LSRs (Label Switching Router) at its starting 405 time. 407 For PCC-Initiated scheduled LSPs, a PCC MUST delegate the scheduled 408 LSP by sending a path computation report (PCRpt) message by including 409 its demanded resources with the scheduling information to a stateful 410 PCE. Note the PCC MAY use the PCReq/PCRep with scheduling 411 information before delegating. 413 Upon receiving the delegation via PCRpt message, the stateful PCE 414 computes the path for the scheduled LSP per its starting time and 415 duration based on the network resource availability stored in 416 scheduled TED (see Section 4.1). 418 The stateful PCE will send a PCUpd message with the scheduled path 419 information as well as the scheduled resource information for the 420 scheduled LSP to the PCC. The PCE MUST add the scheduled LSP into 421 its scheduled LSP-DB and update its scheduled TED. 423 For PCE-Initiated Scheduled LSP, the stateful PCE MUST compute a path 424 for the scheduled LSP per requests from network management systems 425 automatically based on the network resource availability in the 426 scheduled TED, send a PCInitiate message with the path information 427 back to the PCC. Based on the local policy, the PCInitiate message 428 could be sent immediately to ask the PCC to create a scheduled LSP 429 (as per this document) or the PCInitiate message could be sent at the 430 start time to the PCC to create a normal LSP (as per [RFC8281]). 432 For both PCC-Initiated and PCE-Initiated Scheduled LSPs: 434 o The stateful PCE MUST update its local scheduled LSP-DB and 435 scheduled TED with the scheduled LSP. Besides, it MUST send a 436 PCRpt message with the scheduled LSP to its next hop PCE along the 437 path of the LSP, so as to achieve the scheduling traffic 438 engineering information synchronization. 440 o Upon receiving the PCUpd message or PCInitiate message for the 441 scheduled LSP from PCEs with a found path, the PCC determines that 442 it is a scheduled path for the LSP by the SCHED-LSP-ATTRIBUTE TLV 443 (see Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see 444 Section 5.2.2) in the message, and does not trigger signaling for 445 the LSP setup on LSRs immediately. 447 o The stateful PCE MUST update the Scheduled LSP parameters on any 448 network events using the PCUpd message to PCC. These changes are 449 also synchronized to other PCEs. 451 o Based on the configuration (and the C flag in scheduled TLVs), 452 when it is time (i.e., at the start time) for the LSP to be set 453 up, either the PCC triggers the LSP to be signaled or the 454 delegated PCE sends a PCUpd message to the head end LSR providing 455 the updated path to be signaled (with A flag set to indicate LSP 456 activation). 458 4.4. Scheduled LSP Modifications 460 After a scheduled LSP is configured, a user may change its parameters 461 including the requested time as well as the bandwidth. 463 In the PCC-Initiated case, the PCC MUST send the PCE a PCRpt message 464 for the scheduled LSP with updated parameters as well as scheduled 465 information included in the SCHED-LSP-ATTRIBUTE TLV (see 466 Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) 467 carried in the LSP Object. The PCE SHOULD take the updated resources 468 and schedule into considerations and update the new path for the 469 scheduled LSP to the PCC as well as synchronize to other PCEs in the 470 network. In case path cannot be set based on new requirements, the 471 previous LSP will not be impacted and the same MUST be conveyed by 472 the use of empty ERO in the PCEP messages. 474 In the PCE-Initiated case, the Stateful PCE would recompute the path 475 based on updated parameters as well as scheduled information. In 476 case it has already conveyed to the PCC this information by sending a 477 PCInitiate message, it should update the path and other scheduling 478 and resource information by sending a PCUpd message. 480 4.5. Scheduled LSP activation and deletion 482 In the PCC-Initiated case, based on the configuration (and the C flag 483 in scheduled TLVs), when it is time (i.e., at the start time) for the 484 LSP to be set up, either the PCC triggers the LSP to be signaled or 485 the delegated PCE sends a PCUpd message to the head end LSR providing 486 the updated path to be signaled (with A flag set to indicate LSP 487 activation). The PCC would report the status of the active LSP as 488 per the procedures in [RFC8231] and at this time the LSP MUST be 489 considered as part of the LSP-DB. The A flag MUST be set in the 490 scheduled TLVs to indicate that the LSP is active now. After the 491 scheduled duration expires, based on the C flag, the PCC triggers the 492 LSP deletion on itself or the delegated PCE sends a PCUpd message to 493 the PCC to delete the LSP as per the procedures in [RFC8231]. 495 In the PCE-Initiated case, based on the local policy, if the 496 scheduled LSP is already conveyed to the PCC at the time of creation, 497 the handling of LSP activation and deletion is handled in the same 498 way as PCC-Initiated case as per the setting of C flag. Otherwise, 499 the PCE would send the PCInitiate message at the start time to the 500 PCC to create a normal LSP without the scheduled TLVs and remove the 501 LSP after the duration expires as per [RFC8281]. 503 5. PCEP Objects and TLVs 505 5.1. Stateful PCE Capability TLV 507 During a PCEP session has been established, a PCC and a PCE indicates 508 its ability to support LSP scheduling during the PCEP session 509 establishment phase. For a multiple-PCE environment, the PCEs should 510 also establish a PCEP session and indicate its ability to support LSP 511 scheduling among PCEP peers. The Open Object in the Open message 512 contains the STATEFUL-PCE-CAPABILITY TLV. Note that the STATEFUL- 513 PCE-CAPABILITY TLV is defined in [RFC8231] and updated in [RFC8281] 514 and [RFC8232]". In this document, we define a new flag bit B (SCHED- 515 LSP-CAPABLITY) in the Flags field of the STATEFUL-PCE-CAPABILITY TLV 516 to indicate the support of LSP scheduling and another flag bit PD 517 (PD-LSP-CAPABLITY) to indicate the support of LSP periodical 518 scheduling. 520 B (LSP-SCHEDULING-CAPABILITY) - 1 bit [Bit Position - TBD3]: If set 521 to 1 by a PCC, the B Flag indicates that the PCC allows LSP 522 scheduling; if set to 1 by a PCE, the B Flag indicates that the 523 PCE is capable of LSP scheduling. The B bit MUST be set by both 524 PCEP peers in order to support LSP scheduling for path 525 computation. 527 PD (PD-LSP-CAPABLITY) - 1 bit: [Bit Position - TBD4] If set to 1 by 528 a PCC, the PD Flag indicates that the PCC allows LSP scheduling 529 periodically; if set to 1 by a PCE, the PD Flag indicates that the 530 PCE is capable of periodical LSP scheduling. The PD bit MUST be 531 set by both PCEP peers in order to support periodical LSP 532 scheduling for path computation. Setting the PD bit requires 533 setting the B bit as specified in 5.2.2. Without setting B which 534 indicates basic capability of LSP scheduling, the advanced 535 capability indicated by Setting PD bit (capability of periodical 536 LSP scheduling) could not be achieved. If the PD Flag is set to 1 537 and B Flag is set to 0, then the periodical LSP scheduling 538 capability MUST be 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. 546 The presence of the SCHED-LSP-ATTRIBUTE TLV in the LSP object 547 indicates that this LSP has scheduled parameters while the SCHED-PD- 548 LSP-ATTRIBUTE TLV indicates that this scheduled LSP is periodical. 549 The SCHED-LSP-ATTRIBUTE TLV MUST be present in LSP Object for each 550 scheduled LSP carried in the PCEP messages. For periodical LSPs, the 551 SCHED-PD-LSP-ATTRIBUTE TLV MUST be used in the LSP Object for each 552 periodic scheduled LSP carried in the PCEP messages. 554 Only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP object. 555 In case more than one SCHED-LSP-ATTRIBUTE TLV is found, the first 556 instance is processed and others ignored. The SCHED-PD-LSP-ATTRIBUTE 557 TLV is the same as the SCHED-LSP-ATTRIBUTE TLV regarding to its 558 presence in the LSP object. 560 5.2.1. SCHED-LSP-ATTRIBUTE TLV 562 The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV within 563 the LSP object for LSP scheduling for the requesting traffic service. 565 This TLV MUST NOT be included unless both PCEP peers have set the B 566 (LSP-SCHEDULING-CAPABILITY) bit in STATEFUL-PCE-CAPABILITY TLV 567 carried in the Open message. If the TLV is received by a peer when 568 both peers didn't set the B bit, the peer MUST ignore the TLV and 569 generate a PCEP Error (PCErr) with a PCEP-ERROR object having Error- 570 type = 4 (Not supported object) and Error-value = 4 (Unsupported 571 parameter). 573 The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type (TBD1) | Length | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Flags |R|C|A|G| Reserved (0) | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Start-Time | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Duration | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 Figure 1: SCHED-LSP-ATTRIBUTE TLV 591 The type of the TLV is [TBD1] and the TLV has a fixed length of 20 592 octets. 594 The fields in the format are: 596 Flags (8 bits): The following flags are defined in this document 598 R (1 bit): Set to 1 to indicate the Start-Time is a relative 599 time, which is the number of seconds from the current time. 600 The PCEs and PCCs MUST synchronized their clocks when relative 601 time is used. It is RECOMMENDED that the Network Time Protocol 602 [RFC5905] be used to synchronize clocks among them. When the 603 transmission delay from a PCE or PCC to another PCE or PCC is 604 too big such as greater than 1 second, the scheduling interval 605 represented is not accurate if the delay is not considered. 606 Set to 0 to indicate that the 32-bit Start-Time is an absolute 607 time, which is the number of seconds since the epoch. The 608 epoch is 1 January 1970 at 00:00 UTC. It wraps around every 609 2^32 seconds, which is roughly 136 years. The next wraparound 610 will occur in the year 2106. After the wraparound, the value 611 of the 32-bit Start-Time is the number of seconds from the time 612 of wraparound because the Start-Time is always a future time. 613 Before the wraparound and within a constant RANGE-START-TIME to 614 reach the wraparound, if the time at which the LSP is to be 615 activated is after the wraparound, the time is represented by 616 the number of seconds from the time of wraparound in the 32-bit 617 Start-Time. RANGE-START-TIME = 2*365*86400 seconds (about 2 618 years). 620 C (1 bit): Set to 1 to indicate the PCC is responsible to setup 621 and remove the scheduled LSP based on the Start-Time and 622 duration. 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; set 629 to 0 indicate the elastic range is included. 631 Reserved (24 bits): This field MUST be set to zero on transmission 632 and MUST be ignored on receipt. 634 Start-Time (32 bits): This value in seconds, indicates when the 635 scheduled LSP is used to carry traffic and the corresponding LSP 636 must be setup and activated. Value of 0 MUST NOT be used in 637 Start-Time. Note that the transmission delay SHOULD be considered 638 when R=1 and the value of Start-Time is small. 640 Duration (32 bits): The value in seconds, indicates the duration 641 that the LSP is undertaken by a traffic flow and the corresponding 642 LSP must be up to carry traffic. At the expiry of this duration, 643 the LSP is torn down and deleted. Value of 0 MUST NOT be used in 644 Duration since it does not make any sense. The value of Duration 645 SHOULD be greater than a constant MINIMUM-DURATION seconds, where 646 MINIMUM-DURATION is 5. 648 The Start-Time indicates a time at or before which the scheduled LSP 649 must be set up. The value of the Start-Time represents the number of 650 seconds since the epoch when R bit is set to 0. When R bit is set to 651 1, it represents the number of seconds from the current time. 653 In addition, it contains an non zero grace-before and grace-after if 654 grace periods are configured. It includes an non zero elastic range 655 lower bound and upper bound if there is an elastic range configured. 656 A TLV can configure a non-zero grace period or elastic range, but it 657 MUST NOT provide both for an LSP. 659 o GrB (Grace-Before -16 bits): The grace period time length in 660 seconds before the starting time. 662 o GrA (Grace-After -16 bits): The grace period time length in 663 seconds after time interval [starting time, starting time + 664 duration]. 666 o Elastic-Lower-Bound (16 bits): The maximum amount of time in 667 seconds that time interval can shift to lower/left. 669 o Elastic-Upper-Bound (16 bits): The maximum amount of time in 670 seconds that time interval can shift to upper/right. 672 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV 674 The periodical LSP is a special case of LSP scheduling. The traffic 675 service happens in a series of repeated time intervals. The SCHED- 676 PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the 677 LSP object for this periodical LSP scheduling. 679 This TLV MUST NOT be included unless both PCEP peers have set the B 680 (LSP-SCHEDULING-CAPABILITY) bit and PD (PD-LSP-CAPABLITY) bit in 681 STATEFUL-PCE-CAPABILITY TLV carried in open message. If the TLV is 682 received by a peer when both bits were not set, the peer MUST ignore 683 the TLV and generate a PCEP Error (PCErr) with a PCEP-ERROR object 684 having Error-type = 4 (Not supported object) and Error-value = 4 685 (Unsupported parameter). 687 The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2. 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Type (TBD2) | Length | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Flags |R|C|A| Opt | NR | Reserved (0) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Start-Time | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Duration | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Repeat-time-length | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | GrB / Elastic-Lower-Bound | GrA / Elastic-Upper-Bound | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Figure 2: SCHED-PD-LSP-ATTRIBUTE TLV 707 The type of the TLV is [TBD2] and the TLV has a fixed length of 24 708 octets. The description, format and meaning of the Flags (R, C and A 709 bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and 710 Elastic-Upper-Bound fields remain the same as in the SCHED-LSP- 711 ATTRIBUTE TLV. 713 The following fields are new : 715 Opt: (4 bits) Indicates options to repeat. When a PCE receives a 716 TLV with a unknown Opt value, it does not compute any path for the 717 LSP. It MUST generate a PCEP Error (PCErr) with a PCEP-ERROR 718 object having Error-type = 4 (Not supported object) and Error- 719 value = 4 (Unsupported parameter). 721 Opt = 1: repeat every day; 723 Opt = 2: repeat every week; 725 Opt = 3: repeat every month; 727 Opt = 4: repeat every year; 729 Opt = 5: repeat every Repeat-time-length. 731 NR: (12 bits) The number of repeats. During each repetition, LSP 732 carries traffic. 734 Reserved (8 bits): This field MUST be set to zero on transmission 735 and MUST be ignored on receipt. 737 Repeat-time-length: (32 bits) The time in seconds between the start- 738 time of one repetition and the start-time of the next repetition. 740 6. The PCEP Messages 742 6.1. The PCRpt Message 744 Path Computation State Report (PCRpt) is a PCEP message sent by a PCC 745 to a PCE to report the status of one or more LSPs as per [RFC8231]. 746 Each LSP State Report in a PCRpt message contains the actual LSP's 747 path, bandwidth, operational and administrative status, etc. An LSP 748 Status Report carried on a PCRpt message is also used in delegation 749 or revocation of control of an LSP to/from a PCE. In case of 750 scheduled LSP, the scheduled TLVs MUST be carried in the LSP object 751 and the ERO conveys the intended path for the scheduled LSP. The 752 scheduled LSP MUST be delegated to a PCE. This message is also used 753 to synchronize the scheduled LSPs to other PCE as described in 754 [RFC8231]. 756 6.2. The PCUpd Message 758 Path Computation Update Request (PCUpd) is a PCEP message sent by a 759 PCE to a PCC to update LSP parameters, on one or more LSPs as per 760 [RFC8231]. Each LSP Update Request on a PCUpd message contains all 761 LSP parameters that a PCE wishes to be set for a given LSP. In case 762 of scheduled LSP, the scheduled TLVs MUST be carried in the LSP 763 object and the ERO conveys the intended path for the scheduled LSP. 764 In case no path can be found, an empty ERO is used. The A bit is 765 used in PCUpd message to indicate the activation of the scheduled LSP 766 in case the PCE is responsible for the activation (as per the C bit). 768 6.3. The PCInitiate Message 770 An LSP Initiate Request (PCInitiate) message is a PCEP message sent 771 by a PCE to a PCC to trigger LSP instantiation or deletion as per 772 [RFC8281]. In case of scheduled LSP, based on the local policy, PCE 773 MAY convey the scheduled LSP to the PCC by including the scheduled 774 TLVs in the LSP object. Or the PCE would initiate the LSP only at 775 the start time of the scheduled LSP as per the [RFC8281] without the 776 use of scheduled TLVs. 778 6.4. The PCReq message 780 The Path Computation Request (PCReq) message is a PCEP message sent 781 by a PCC to a PCE to request a path computation [RFC5440] and it may 782 contain the LSP object [RFC8231] to identify the LSP for which the 783 path computation is requested. In case of scheduled LSP, the 784 scheduled TLVs MUST be carried in the LSP object in PCReq message to 785 request the path computation based on scheduled TED and LSP-DB. A 786 PCC MAY use PCReq message to obtain the scheduled path before 787 delegating the LSP. 789 6.5. The PCRep Message 791 The Path Computation Reply (PCRep) message is a PCEP message sent by 792 a PCE to a PCC in reply to a path computation request [RFC5440] and 793 it may contain the LSP object [RFC8231] to identify the LSP for which 794 the path is computed. A PCRep message can contain either a set of 795 computed paths if the request can be satisfied, or a negative reply 796 if not. The negative reply may indicate the reason why no path could 797 be found. In case of scheduled LSP, the scheduled TLVs MUST be 798 carried in the LSP object in PCRep message to indicate the path 799 computation based on scheduled TED and LSP-DB. A PCC and PCE MAY use 800 PCReq and PCRep message to obtain the scheduled path before 801 delegating the LSP. 803 6.6. The PCErr Message 805 The Path Computation Error (PCErr) message is a PCEP message as 806 described in [RFC5440] for error reporting. The current document 807 defines new error values for several error types to cover failures 808 specific to scheduling and reuse the applicable error types and error 809 values of [RFC5440] and [RFC8231] wherever appropriate. 811 The PCEP extensions for scheduling MUST NOT be used if one or both 812 PCEP speakers have not set the corresponding bits in the STATEFUL- 813 PCE-CAPABILITY TLV in their respective OPEN message. If the PCEP 814 speaker supports the extensions of this specification but did not 815 advertise this capability, then upon receipt of LSP object with the 816 scheduled TLV, it MUST generate a PCEP Error (PCErr) with Error- 817 type=19 (Invalid Operation) and error-value TBD6 (Attempted LSP 818 Scheduling if the scheduling capability was not advertised), and it 819 SHOULD ignore the TLV. As per Section 7.1 of [RFC5440], a legacy 820 PCEP implementation that does not understand this specification, 821 would consider the scheduled TLVs as unknown and ignore them. 823 If the PCC decides that the scheduling parameters proposed in the 824 PCUpd/PCInitiate message are unacceptable, it MUST report this error 825 by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error- 826 value="Unacceptable parameters" in the LSP object (with scheduled 827 TLVs) in the PCRpt message to the PCE. 829 The scheduled TLVs MUST be included in the LSP object for the 830 scheduled LSPs, if the TLV is missing, the receiving PCEP speaker 831 MUST send a PCErr message with Error-type=6 (Mandatory Object 832 missing) and Error-value TBD5 (Scheduled TLV missing). 834 7. Implementation Status 836 [NOTE TO RFC EDITOR : This whole section and the reference to RFC 837 7942 is to be removed before publication as an RFC] 839 This section records the status of known implementations of the 840 protocol defined by this specification at the time of posting of this 841 Internet-Draft, and is based on a proposal described in [RFC7942]. 842 The description of implementations in this section is intended to 843 assist the IETF in its decision processes in progressing drafts to 844 RFCs. Please note that the listing of any individual implementation 845 here does not imply endorsement by the IETF. Furthermore, no effort 846 has been spent to verify the information presented here that was 847 supplied by IETF contributors. This is not intended as, and must not 848 be construed to be, a catalog of available implementations or their 849 features. Readers are advised to note that other implementations may 850 exist. 852 According to [RFC7942], "this will allow reviewers and working groups 853 to assign due consideration to documents that have the benefit of 854 running code, which may serve as evidence of valuable experimentation 855 and feedback that have made the implemented protocols more mature. 856 It is up to the individual working groups to use this information as 857 they see fit". 859 At the time of posting the -09 version of this document, there are no 860 known implementations of this mechanism. It is believed that two 861 vendors/organizations are considering prototype implementations, but 862 these plans are too vague to make any further assertions. 864 8. Security Considerations 866 This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED-LSP- 867 ATTRIBUTE TLV, the security considerations discussed in [RFC5440], 868 [RFC8231], and [RFC8281] continue to apply. In some deployments the 869 scheduling information could provide details about the network 870 operations that could be deemed as extra sensitive. Additionally, 871 snooping of PCEP messages with such data or using PCEP messages for 872 network reconnaissance may give an attacker sensitive information 873 about the operations of the network. A single PCEP message can now 874 instruct a PCC to set up and tear down an LSP every second for a 875 number of times. That single message could have a significant effect 876 on the network. Thus, such deployment should employ suitable PCEP 877 security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] 878 or [RFC8253]. The procedure based on Transport Layer Security (TLS) 879 in [RFC8253] is considered a security enhancement and thus is much 880 better suited for the sensitive information. PCCs may also need to 881 apply some form of rate limit to the processing of scheduled LSPs. 883 9. Manageability Consideration 885 9.1. Control of Function and Policy 887 The LSP-Scheduling feature MUST BE controlled per tunnel by the 888 active stateful PCE, the values for parameters like starting time, 889 duration SHOULD BE configurable by customer applications and based on 890 the local policy at PCE. The suggested default values for starting 891 time and duration are one day in seconds from the current time and 892 one year in seconds respectively. One day has 86,400 seconds. One 893 year has 31,536,000 seconds. 895 When configuring the parameters about time, a user SHOULD consider 896 leap-years and leap-seconds. 898 9.2. Information and Data Models 900 An implementation SHOULD allow the operator to view the capability 901 defined in this document. To serve this purpose, the PCEP YANG 902 module [I-D.ietf-pce-pcep-yang] could be extended. 904 9.3. Liveness Detection and Monitoring 906 Mechanisms defined in this document do not imply any new liveness 907 detection and monitoring requirements in addition to those already 908 listed in [RFC5440]. 910 9.4. Verify Correct Operations 912 Mechanisms defined in this document do not imply any new operation 913 verification requirements in addition to those already listed in 914 [RFC5440]. 916 9.5. Requirements On Other Protocols 918 Mechanisms defined in this document do not imply any new requirements 919 on other protocols. 921 9.6. Impact On Network Operations 923 Mechanisms defined in this document do not have any impact on network 924 operations in addition to those already listed in [RFC5440]. 926 10. IANA Considerations 928 10.1. PCEP TLV Type Indicators 930 This document defines the following new PCEP TLVs. IANA maintains a 931 sub-registry "PCEP TLV Type Indicators" in the "Path Computation 932 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 933 the following allocations from this sub-registry. 935 Value Meaning Reference 936 TBD1 SCHED-LSP-ATTRIBUTE This document 937 TBD2 SCHED-PD-LSP-ATTRIBUTE This document 939 10.1.1. Opt Field in SCHED-PD-LSP-ATTRIBUTE TLV 941 IANA is requested to create and maintain a new sub-registry named 942 "SCHED-PD-LSP-ATTRIBUTE TLV Opt field" within the "Path Computation 943 Element Protocol (PCEP) Numbers" registry. Initial values for the 944 sub-registry are given below. New values are assigned by Standards 945 Action [RFC8126]. 947 Value Name Reference 948 ----- ---- ---------- 949 0 Reserved 950 1 REPEAT-EVERY-DAY This document 951 2 REPEAT-EVERY-WEEK This document 952 3 REPEAT-EVERY-MONTH This document 953 4 REPEAT-EVERY-YEAR This document 954 5 REPEAT-EVERY-REPEAT-TIME-LENGTH This document 955 6-14 Unassigned 956 15 Reserved 958 10.1.2. Schedule TLVs Flag Field 960 IANA is requested to create a new sub-registry, named "Schedule TLVs 961 Flag Field", within the "Path Computation Element Protocol (PCEP) 962 Numbers" registry. New values are assigned by Standards Action 963 [RFC8126]. Each bit should be tracked with the following qualities: 965 o Bit number (counting from bit 0 as the most significant bit) 967 o Capability description 969 o Defining RFC 971 The following values are defined in this document: 973 Bit Description Reference 974 0-3 Unassigned 975 4 Relative Time (R-bit) This document 976 5 PCC Responsible (C-bit) This document 977 6 LSP Activated (A-bit) This document 978 7 Grace Period Included (G-bit) This document 980 10.2. STATEFUL-PCE-CAPABILITY TLV Flag field 982 This document defines new bits in the Flags field in the STATEFUL- 983 PCE-CAPABILITY TLV in the OPEN object. IANA maintains a sub-registry 984 "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "Path Computation 985 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 986 the following allocations from this sub-registry. 988 The following values are defined in this document: 990 Bit Description Reference 991 TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document 992 TBD4 PD-LSP-CAPABLITY (PD-bit) This document 994 10.3. PCEP-Error Object 996 IANA is requested to allocate the following new error types to the 997 existing error values within the "PCEP-ERROR Object Error Types and 998 Values" subregistry of the "Path Computation Element Protocol (PCEP) 999 Numbers" registry: 1001 Error-Type Meaning 1002 6 Mandatory Object missing 1004 Error-value 1005 TBD5: Scheduled TLV missing 1007 19 Invalid Operation 1009 Error-value 1010 TBD6: Attempted LSP Scheduling if the scheduling 1011 capability was not advertised 1013 29 Path computation failure 1015 Error-value 1016 TBD7: Constraints could not be met for some intervals 1018 11. Acknowledgments 1020 The authors of this document would also like to thank Rafal Szarecki, 1021 Adrian Farrel, Cyril Margaria for the review and comments. 1023 12. References 1025 12.1. Normative References 1027 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1028 Requirement Levels", BCP 14, RFC 2119, 1029 DOI 10.17487/RFC2119, March 1997, 1030 . 1032 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1033 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1034 DOI 10.17487/RFC5440, March 2009, 1035 . 1037 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1038 Writing an IANA Considerations Section in RFCs", BCP 26, 1039 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1040 . 1042 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1043 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1044 May 2017, . 1046 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1047 Computation Element Communication Protocol (PCEP) 1048 Extensions for Stateful PCE", RFC 8231, 1049 DOI 10.17487/RFC8231, September 2017, 1050 . 1052 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1053 and D. Dhody, "Optimizations of Label Switched Path State 1054 Synchronization Procedures for a Stateful PCE", RFC 8232, 1055 DOI 10.17487/RFC8232, September 2017, 1056 . 1058 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1059 Computation Element Communication Protocol (PCEP) 1060 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1061 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1062 . 1064 [RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework 1065 for Scheduled Use of Resources", RFC 8413, 1066 DOI 10.17487/RFC8413, July 2018, 1067 . 1069 12.2. Informative References 1071 [I-D.ietf-detnet-architecture] 1072 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1073 "Deterministic Networking Architecture", draft-ietf- 1074 detnet-architecture-13 (work in progress), May 2019. 1076 [I-D.ietf-pce-pcep-yang] 1077 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1078 YANG Data Model for Path Computation Element 1079 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1080 yang-13 (work in progress), October 2019. 1082 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1083 "Network Time Protocol Version 4: Protocol and Algorithms 1084 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1085 . 1087 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1088 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1089 June 2010, . 1091 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1092 Computation Element Architecture", RFC 7399, 1093 DOI 10.17487/RFC7399, October 2014, 1094 . 1096 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1097 Code: The Implementation Status Section", BCP 205, 1098 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1099 . 1101 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1102 Stateful Path Computation Element (PCE)", RFC 8051, 1103 DOI 10.17487/RFC8051, January 2017, 1104 . 1106 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1107 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1108 Path Computation Element Communication Protocol (PCEP)", 1109 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1110 . 1112 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1113 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1114 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1115 July 2018, . 1117 Appendix A. Contributors Addresses 1119 Dhruv Dhody 1120 Huawei 1121 Divyashree Techno Park, Whitefield 1122 Bangalore, Karnataka 560066 1123 India 1125 Email: dhruv.ietf@gmail.com 1127 Xufeng Liu 1128 Ericsson 1129 USA 1130 Email: xliu@kuatrotech.com 1132 Mehmet Toy 1133 Verizon 1134 USA 1135 Email: mehmet.toy@verizon.com 1137 Vic Liu 1138 China Mobile 1139 No.32 Xuanwumen West Street, Xicheng District 1140 Beijing, 100053 1141 China 1142 Email: liu.cmri@gmail.com 1144 Lei Liu 1145 Fujitsu 1146 USA 1147 Email: lliu@us.fujitsu.com 1149 Khuzema Pithewan 1150 Infinera 1151 Email: kpithewan@infinera.com 1153 Zitao Wang 1154 Huawei 1155 101 Software Avenue, Yuhua District 1156 Nanjing, Jiangsu 210012 1157 China 1159 Email: wangzitao@huawei.com 1161 Xian Zhang 1162 Huawei Technologies 1163 Research Area F3-1B, 1164 Huawei Industrial Base, 1165 Shenzhen, 518129, China 1167 Email: zhang.xian@huawei.com 1169 Authors' Addresses 1171 Huaimo Chen (editor) 1172 Futurewei 1173 Boston, MA 1174 USA 1176 Email: huaimo.chen@futurewei.com 1178 Yan Zhuang (editor) 1179 Huawei 1180 101 Software Avenue, Yuhua District 1181 Nanjing, Jiangsu 210012 1182 China 1184 Email: zhuangyan.zhuang@huawei.com 1185 Qin Wu 1186 Huawei 1187 101 Software Avenue, Yuhua District 1188 Nanjing, Jiangsu 210012 1189 China 1191 Email: bill.wu@huawei.com 1193 Daniele Ceccarelli 1194 Ericsson 1195 Via A. Negrone 1/A 1196 Genova - Sestri Ponente 1197 Italy 1199 Email: daniele.ceccarelli@ericsson.com