idnits 2.17.1 draft-ietf-pce-stateful-pce-lsp-scheduling-18.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 (June 28, 2020) is 1369 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 578, but not defined == Missing Reference: 'TBD2' is mentioned on line 683, but not defined == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-13 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-07 Summary: 0 errors (**), 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: December 30, 2020 Q. Wu 6 Huawei 7 D. Ceccarelli 8 Ericsson 9 June 28, 2020 11 PCEP Extensions for LSP scheduling with stateful PCE 12 draft-ietf-pce-stateful-pce-lsp-scheduling-18 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 December 30, 2020. 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 . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . 19 86 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 21 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 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 terminologies are re-used from existing PCE documents. 165 o Active Stateful PCE [RFC8231]; 167 o Passive Stateful PCE [RFC8231]; 169 o Delegation [RFC8231]; 171 o PCE-Initiated LSP [RFC8281]; 173 o PCC [RFC5440], [RFC8231]; 175 o PCE [RFC5440], [RFC8231]; 177 o TE LSP [RFC5440], [RFC8231]; 179 o TED [RFC5440], [RFC8231]; 181 o LSP-DB [RFC8231]; 183 In addition, this document defines the following terminologies. 185 Scheduled TE LSP (or Scheduled LSP for short): an LSP with the 186 scheduling attributes, that carries traffic flow demand at a 187 starting time and lasts for a certain duration (or from a starting 188 time to an ending time, where the ending time is the starting time 189 plus the duration). A scheduled LSP is also called a temporal 190 LSP. The PCE operates path computation per LSP availability for 191 the required time and duration. 193 Scheduled LSP-DB: a database of scheduled LSPs. 195 Scheduled TED: Traffic engineering database with the awareness of 196 scheduled resources for TE. This database is generated by the PCE 197 from the information in TED and scheduled LSP-DB and allows 198 knowing, at any time, the amount of available resources (does not 199 include failures in the future). 201 Starting time (start-time): This value indicates when the scheduled 202 LSP is used and the corresponding LSP must be setup and active. 203 In other time (i.e., before the starting time or after the 204 starting time plus Duration), the LSP can be inactive to include 205 the possibility of the resources being used by other services. 207 Duration: This value indicates the time duration that the LSP is 208 undertaken by a traffic flow and the corresponding LSP must be 209 setup and active. At the end of which, the LSP is torn down and 210 removed from the database. 212 3. Motivation and Objectives 214 A stateful PCE [RFC8231] can support better efficiency by using LSP 215 scheduling described in the use case of [RFC8051]. This requires the 216 PCE to maintain the scheduled LSPs and their associated resource 217 usage, e.g. bandwidth for Packet-switched network, as well as have 218 the ability to trigger signaling for the LSP setup/tear-down at the 219 correct time. 221 Note that existing configuration tools can be used for LSP 222 scheduling, but as highlighted in section 3.1.3 of [RFC8231] as well 223 as discussions in [RFC8413], doing this as a part of PCEP in a 224 centralized manner, has obvious advantages. 226 This document provides a set of extensions to PCEP to enable LSP 227 scheduling for LSP creation/deletion under the stateful control of a 228 PCE and according to traffic service requests from customers, so as 229 to improve the usage of network resources. 231 4. Procedures and Mechanisms 233 4.1. LSP Scheduling Overview 235 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for 236 customers' traffic services at its actual usage time, so as to 237 improve the network resource efficient utilization. 239 For stateful PCE supporting LSP scheduling, there are two types of 240 LSP databases used in this document. One is the LSP-DB defined in 241 PCEP [RFC8231], while the other is the scheduled LSP database (SLSP- 242 DB, see section 6). The SLSP-DB records scheduled LSPs and is used 243 in conjunction with the TED and LSP-DB. Note that the two types of 244 LSP databases can be implemented in one physical database or two 245 different databases. This is an implementation matter and this 246 document does not state any preference. 248 Furthermore, a scheduled TED can be generated from the scheduled LSP- 249 DB, LSP-DB and TED to indicate the network links and nodes with 250 resource availability information for now and future. The scheduled 251 TED should be maintained by all PCEs within the network environment. 253 In case of implementing PCC-initiated scheduled LSPs, before a PCC 254 delegates a scheduled LSP, it MAY use the PCReq/PCRep messages to 255 learn the path for the scheduled LSP. A PCC MUST delegate a 256 scheduled LSP with information of its scheduling parameters, 257 including the starting time and the duration using PCRpt message. 258 Since the LSP is not yet signaled, at the time of delegation the LSP 259 would be in down state. Upon receiving the delegation of the 260 scheduled LSP, a stateful PCE SHALL check the scheduled TED for the 261 network resource availability on network nodes and computes a path 262 for the LSP with the scheduling information and update to the PCC as 263 per the active stateful PCE techniques [RFC8231]. 265 Note that the active stateful PCE can update to the PCC with the path 266 for the scheduled LSP at any time. However, the PCC should not 267 signal the LSP over the path on receiving these messages since the 268 path is not active yet; PCC signals the LSP at the starting time. 270 For a multiple PCE environment, a PCE MUST synchronize to other PCEs 271 within the network, so as to keep their scheduling information 272 synchronized. There are many ways that this could be achieved: one 273 such mechanism is described in [I-D.litkowski-pce-state-sync]. Which 274 way is used to achieve this is out of scope for this document. The 275 scheduled TED can be determined from the synchronized SLSP-DB. The 276 PCE with delegation for the scheduled LSP would report the scheduled 277 LSP to other PCEs, any future update to the scheduled LSP is also 278 updated to other PCEs. This way the state of all scheduled LSPs are 279 synchronized among the PCEs. [RFC7399] discusses some 280 synchronization issues and considerations, that are also applicable 281 to the scheduled databases. 283 The scheduled LSP can also be initiated by 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 computes 286 a 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 LSP. 298 Similarly on the scheduling 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. 339 4.2.2.1. Elastic Time LSP Scheduling 341 In addition to the basic LSP scheduling at an arbitrary time period, 342 another option is elastic time intervals, which is represented as 343 within -P and Q, where P and Q is an amount of time such as 300 344 seconds. P is called elastic range lower bound and Q is called 345 elastic range upper bound. 347 For a simple time interval such as [Ta, Tb] with an elastic range, 348 elastic time interval: "[Ta, Tb] within -P and Q" means a time period 349 from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb 350 is shifted by the same 'X'. 352 When an LSP is configured with elastic time interval "[Ta, Tb] within 353 -P and Q", a path is computed such that the path satisfies the 354 constraints for the LSP in the time period from (Ta+X) to (Tb+X) 355 and |X| is the minimum value from 0 to max(P, Q). That is, [Ta+X, 356 Tb+X] is the time interval closest to time interval [Ta, Tb] within 357 the elastic range. The LSP along the path is set up to carry traffic 358 in the time period from (Ta+X) to (Tb+X). 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. 388 When an LSP is configured with a simple time interval such as [Ta, 389 Tb] with grace periods such as grace-before GB and grace-after GA, a 390 path is computed such that the path satisfies the constraints for the 391 LSP in the time period from Ta to Tb. The LSP along the path is set 392 up to carry traffic in the time period from (Ta-GB) to (Tb+GA). 393 During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the 394 LSP is up to carry traffic (maybe in best effort). 396 4.3. Scheduled LSP creation 398 In order to realize PCC-Initiated scheduled LSPs in a centralized 399 network environment, a PCC has to separate the setup of an LSP into 400 two steps. The first step is to request/delegate and get an LSP but 401 not signal it over the network. The second step is to signal the 402 scheduled LSP over the LSRs (Label Switching Router) at its starting 403 time. 405 For PCC-Initiated scheduled LSPs, a PCC can delegate the scheduled 406 LSP by sending a path computation report (PCRpt) message by including 407 its demanded resources with the scheduling information to a stateful 408 PCE. Note the PCC MAY use the PCReq/PCRep with scheduling 409 information before delegating. 411 Upon receiving the delegation via PCRpt message, the stateful PCE 412 computes the path for the scheduled LSP per its starting time and 413 duration based on the network resource availability stored in 414 scheduled TED (see Section 4.1). 416 The stateful PCE will send a PCUpd message with the scheduled path 417 information as well as the scheduled resource information for the 418 scheduled LSP to the PCC. The PCE SHOULD add the scheduled LSP into 419 its scheduled LSP-DB and update its scheduled TED. 421 For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path 422 for the scheduled LSP per requests from network management systems 423 automatically based on the network resource availability in the 424 scheduled TED, send a PCInitiate message with the path information 425 back to the PCC. Based on the local policy, the PCInitiate message 426 could be sent immediately to ask PCC to create a scheduled LSP (as 427 per this document) or the PCInitiate message could be sent at the 428 start time to the PCC to create a normal LSP (as per [RFC8281]). 430 For both PCC-Initiated and PCE-Initiated Scheduled LSPs: 432 o The stateful PCE is required to update its local scheduled LSP-DB 433 and scheduled TED with the scheduled LSP. Besides, it shall send 434 a PCRpt message with the scheduled LSP to other PCEs within the 435 network, so as to achieve the scheduling traffic engineering 436 information synchronization. 438 o Upon receiving the PCUpd message or PCInitiate message for the 439 scheduled LSP from PCEs with a found path, the PCC knows that it 440 is a scheduled path for the LSP and does not trigger signaling for 441 the LSP setup on LSRs immediately. 443 o The stateful PCE can update the Scheduled LSP parameters on any 444 network events using the PCUpd message to PCC. These changes are 445 also synchronized to other PCEs. 447 o Based on the configuration (and the C flag in scheduled TLVs), 448 when it is time (i.e., at the start time) for the LSP to be set 449 up, either the PCC triggers the LSP to be signaled or the 450 delegated PCE sends a PCUpd message to the head end LSR providing 451 the updated path to be signaled (with A flag set to indicate LSP 452 activation). 454 4.4. Scheduled LSP Modifications 456 After a scheduled LSP is configured, a user may change its parameters 457 including the requested time as well as the bandwidth. 459 In PCC-Initiated case, the PCC can send a PCRpt message for the 460 scheduled LSP with updated parameters as well as scheduled 461 information included in the SCHED-LSP-ATTRIBUTE TLV (see 462 Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) 463 carried in the LSP Object. The PCE would take the updated resources 464 and schedule into considerations and update the new path for the 465 scheduled LSP to the PCC as well as synchronize to other PCEs in the 466 network. In case path cannot be set based on new requirements, the 467 previous LSP will not be impacted and the same should be conveyed by 468 the use of empty ERO in the PCEP messages. 470 In PCE-Initiated case, the Stateful PCE would recompute the path 471 based on updated parameters as well as scheduled information. In 472 case it has already conveyed to the PCC this information by sending a 473 PCInitiate message, it should update the path and other scheduling 474 and resource information by sending a PCUpd message. 476 4.5. Scheduled LSP activation and deletion 478 In PCC-Initiated case, based on the configuration (and the C flag in 479 scheduled TLVs), when it is time (i.e., at the start time) for the 480 LSP to be set up, either the PCC triggers the LSP to be signaled or 481 the delegated PCE sends a PCUpd message to the head end LSR providing 482 the updated path to be signaled (with A flag set to indicate LSP 483 activation). The PCC would report the status of the active LSP as 484 per the procedures in [RFC8231] and at this time the LSP MUST be 485 considered as part of the LSP-DB. The A flag MUST be set in the 486 scheduled TLVs to indicate that the LSP is active now. After the 487 scheduled duration expires, based on the C flag, the PCC triggers the 488 LSP deletion on itself or the delegated PCE sends a PCUpd message to 489 the PCC to delete the LSP as per the procedures in [RFC8231]. 491 In PCE-Initiated case, based on the local policy, if the scheduled 492 LSP is already conveyed to the PCC at the time of creation, the 493 handling of LSP activation and deletion is handled in the same way as 494 PCC-Initiated case as per the setting of C flag. In other case, the 495 PCE would send the PCInitiate message at the start time to the PCC to 496 create a normal LSP without the scheduled TLVs and remove the LSP 497 after the duration expires as per [RFC8281]. 499 5. PCEP Objects and TLVs 501 5.1. Stateful PCE Capability TLV 503 After a PCEP session has been established, a PCC and a PCE indicates 504 its ability to support LSP scheduling during the PCEP session 505 establishment phase. For a multiple-PCE environment, the PCEs should 506 also establish PCEP session and indicate its ability to support LSP 507 scheduling among PCEP peers. The Open Object in the Open message 508 contains the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231]. Note 509 that the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and 510 updated in [RFC8281] and [RFC8232]". In this document, we define a 511 new flag bit B (SCHED-LSP-CAPABLITY) flag for the STATEFUL-PCE- 512 CAPABILITY TLV to indicate the support of LSP scheduling and another 513 flag bit PD (PD-LSP-CAPABLITY) to indicate the support of LSP 514 periodical scheduling. 516 B (LSP-SCHEDULING-CAPABILITY - 1 bit) [Bit Position - TBD3]: If set 517 to 1 by a PCC, the B Flag indicates that the PCC allows LSP 518 scheduling; if set to 1 by a PCE, the B Flag indicates that the 519 PCE is capable of LSP scheduling. The B bit MUST be set by both 520 PCEP peers in order to support LSP scheduling for path 521 computation. 523 PD (PD-LSP-CAPABLITY - 1 bit): [Bit Position - TBD4] If set to 1 by 524 a PCC, the PD Flag indicates that the PCC allows LSP scheduling 525 periodically; if set to 1 by a PCE, the PD Flag indicates that the 526 PCE is capable of periodical LSP scheduling. The PD bit MUST be 527 set by both PCEP peers in order to support periodical LSP 528 scheduling for path computation. Setting PD bit requires setting 529 B bit as specified in 5.2.2. 531 5.2. LSP Object 533 The LSP object is defined in [RFC8231]. This document adds an 534 optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an 535 optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP scheduling. 537 The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates 538 that this LSP is requesting scheduled parameters while the SCHED-PD- 539 LSP-ATTRIBUTE TLV indicates that this scheduled LSP is periodical. 540 The scheduled LSP attribute TLV MUST be present in LSP Object for 541 each scheduled LSP carried in the PCEP messages. For periodical 542 LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in LSP Object for 543 each periodic scheduled LSP carried in the PCEP messages. 545 Only one of these TLV SHOULD be present in the LSP object. In case 546 more than one scheduling TLV is found, the first instance is 547 processed and others ignored. 549 5.2.1. SCHED-LSP-ATTRIBUTE TLV 551 The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV within 552 the LSP object for LSP scheduling for the requesting traffic service. 554 This TLV MUST NOT be included unless both PCEP peers have set the B 555 (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV 556 carried in the Open message. 558 The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1. 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type (TBD1) | Length | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Flags |R|C|A| Reserved (0) | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Start-Time | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Duration | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | GrB | GrA | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Elastic-Lower-Bound | Elastic-Upper-Bound | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Figure 1: SCHED-LSP-ATTRIBUTE TLV 578 The type of the TLV is [TBD1] and the TLV has a fixed length of 20 579 octets. 581 The fields in the format are: 583 Flags (8 bits): Following flags are defined in this document 585 R (1 bit): Set to 1 to indicate the Start-Time is a relative 586 time, which is the number of seconds from the current time. It 587 is necessary to synchronize the clocks of the PCEs and PCCs 588 when relative time is used. When the transmission delay from a 589 PCE or PCC to another PCE or PCC is too big such as greater 590 than 1 second, the scheduling interval represented is not 591 accurate if the delay is not considered. Set to 0 to indicate 592 that the 32-bit Start-Time is an absolute time, which is the 593 number of seconds since the epoch. The epoch is 1 January 1970 594 at 00:00 UTC. It wraps around every 2^32 seconds, which is 595 roughly 136 years. The next wraparound will occur in the year 596 2106. After the wraparound, the value of the 32-bit Start-Time 597 is the number of seconds from the time of wraparound because 598 the Start-Time is always a future time. Just before the 599 wraparound, if the time at which the LSP is to be activated is 600 after the wraparound, the time is represented by the number of 601 seconds from the time of wraparound in the 32-bit Start-Time. 603 C (1 bit): Set to 1 to indicate the PCC is responsible to setup 604 and remove the scheduled LSP based on the Start-Time and 605 duration. 607 A (1 bit): Set to 1 to indicate the scheduled LSP has been 608 activated and should be considered as part of LSP-DB (instead 609 of Scheduled LSP-DB). 611 Reserved (24 bits): This field MUST be set to zero on transmission 612 and MUST be ignored on receipt. 614 Start-Time (32 bits): This value in seconds, indicates when the 615 scheduled LSP is used to carry traffic and the corresponding LSP 616 must be setup and activated. Value of 0 MUST NOT be used in 617 Start-Time. Note that the transmission delay SHOULD be considered 618 when R=1 and the value of Start-Time is small. 620 Duration (32 bits): The value in seconds, indicates the duration 621 that the LSP is undertaken by a traffic flow and the corresponding 622 LSP must be up to carry traffic. At the expiry of this duration, 623 the LSP is torn down and deleted. Value of 0 MUST NOT be used in 624 Duration since it does not make any sense. 626 The Start-Time indicates a time at or before which the scheduled LSP 627 must be set up. The value of the Start-Time represents the number of 628 seconds since the epoch when R bit is set to 0. When R bit is set to 629 1, it represents the number of seconds from the current time. 631 In addition, it contains an non zero grace-before and grace-after if 632 grace periods are configured. It includes an non zero elastic range 633 lower bound and upper bound if there is an elastic range configured. 634 A TLV can configure a non-zero grace period or elastic range, but it 635 MUST NOT provide both for an LSP. 637 o GrB (Grace-Before -16 bits): The grace period time length in 638 seconds before the starting time. 640 o GrA (Grace-After -16 bits): The grace period time length in 641 seconds after time interval [starting time, starting time + 642 duration]. 644 o Elastic-Lower-Bound (16 bits): The maximum amount of time in 645 seconds that time interval can shift to lower/left. 647 o Elastic-Upper-Bound (16 bits): The maximum amount of time in 648 seconds that time interval can shift to upper/right. 650 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV 652 The periodical LSP is a special case of LSP scheduling. The traffic 653 service happens in a series of repeated time intervals. The SCHED- 654 PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the 655 LSP object for this periodical LSP scheduling. 657 This TLV MUST NOT be included unless both PCEP peers have set the B 658 (LSP-SCHEDULING-CAPABILITY bit) and PD (PD-LSP-CAPABLITY bit) in 659 STATEFUL-PCE-CAPABILITY TLV carried in open message. 661 The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2. 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Type (TBD2) | Length | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Flags |R|C|A| Opt | NR | Reserved (0) | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Start-Time | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Duration | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Repeat-time-length | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | GrB | GrA | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Elastic-Lower-Bound | Elastic-Upper-Bound | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 Figure 2: SCHED-PD-LSP-ATTRIBUTE TLV 683 The type of the TLV is [TBD2] and the TLV has a fixed length of 24 684 octets. The description, format and meaning of the Flags (R, C and A 685 bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and 686 Elastic-Upper-Bound fields remains same as SCHED-LSP-ATTRIBUTE TLV. 688 The following fields are new : 690 Opt: (4 bits) Indicates options to repeat. A new registry "Opt" 691 under SCHED-PD-LSP-ATTRIBUTE is created. When a PCE receives a 692 TLV with a Opt value not defined, it does not compute any path for 693 the LSP. It generates a PCEP Error (PCErr) with a PCEP-ERROR 694 object having Error-type = 4 (Not supported object) and Error- 695 value = 4 (Unsupported parameter). 697 Options = 1: repeat every day; 698 Options = 2: repeat every week; 700 Options = 3: repeat every month; 702 Options = 4: repeat every year; 704 Options = 5: repeat every Repeat-time-length. 706 NR: (12 bits) The number of repeats. In each of repeats, LSP 707 carries traffic. 709 Reserved (8 bits): This field MUST be set to zero on transmission 710 and MUST be ignored on receipt. 712 Repeat-time-length: (32 bits) The time in seconds between the start- 713 time of one repetition and the start-time of the next repetition. 715 6. The PCEP Messages 717 6.1. The PCRpt Message 719 Path Computation State Report (PCRpt) is a PCEP message sent by a PCC 720 to a PCE to report the status of one or more LSPs as per [RFC8231]. 721 Each LSP State Report in a PCRpt message contains the actual LSP's 722 path, bandwidth, operational and administrative status, etc. An LSP 723 Status Report carried on a PCRpt message is also used in delegation 724 or revocation of control of an LSP to/from a PCE. In case of 725 scheduled LSP, the scheduled TLVs MUST be carried in the LSP object 726 and the ERO conveys the intended path for the scheduled LSP. The 727 scheduled LSP MUST be delegated to a PCE. This message is also used 728 to synchronize the scheduled LSPs to other PCE as described in 729 [RFC8231] 731 6.2. The PCUpd Message 733 Path Computation Update Request (PCUpd) is a PCEP message sent by a 734 PCE to a PCC to update LSP parameters, on one or more LSPs as per 735 [RFC8231]. Each LSP Update Request on a PCUpd message contains all 736 LSP parameters that a PCE wishes to be set for a given LSP. In case 737 of scheduled LSP, the scheduled TLVs MUST be carried in the LSP 738 object and the ERO conveys the intended path for the scheduled LSP. 739 In case no path can be found, an empty ERO is used. The A bit is 740 used in PCUpd message to indicate the activation of the scheduled LSP 741 in case the PCE is responsible for the activation (as per the C bit). 743 6.3. The PCInitiate Message 745 An LSP Initiate Request (PCInitiate) message is a PCEP message sent 746 by a PCE to a PCC to trigger LSP instantiation or deletion as per 747 [RFC8281]. In case of scheduled LSP, based on the local policy, PCE 748 MAY convey the scheduled LSP to the PCC by including the scheduled 749 TLVs in the LSP object. Or the PCE would initiate the LSP only at 750 the start time of the scheduled LSP as per the [RFC8281] without the 751 use of scheduled TLVs. 753 6.4. The PCReq message 755 The Path Computation Request (PCReq) message is a PCEP message sent 756 by a PCC to a PCE to request a path computation [RFC5440] and it may 757 contain the LSP object [RFC8231] to identify the LSP for which the 758 path computation is requested. In case of scheduled LSP, the 759 scheduled TLVs MUST be carried in the LSP object in PCReq message to 760 request the path computation based on scheduled TED and LSP-DB. A 761 PCC MAY use PCReq message to obtain the scheduled path before 762 delegating the LSP. 764 6.5. The PCRep Message 766 The Path Computation Reply (PCRep) message is a PCEP message sent by 767 a PCE to a PCC in reply to a path computation request [RFC5440] and 768 it may contain the LSP object [RFC8231] to identify the LSP for which 769 the path is computed. A PCRep message can contain either a set of 770 computed paths if the request can be satisfied, or a negative reply 771 if not. The negative reply may indicate the reason why no path could 772 be found. In case of scheduled LSP, the scheduled TLVs MUST be 773 carried in the LSP object in PCRep message to indicate the path 774 computation based on scheduled TED and LSP-DB. A PCC and PCE MAY use 775 PCReq and PCRep message to obtain the scheduled path before 776 delegating the LSP. 778 6.6. The PCErr Message 780 The Path Computation Error (PCErr) message is a PCEP message as 781 described in [RFC5440] for error reporting. The current document 782 defines new error values for several error types to cover failures 783 specific to scheduling and reuse the applicable error types and error 784 values of [RFC5440] and [RFC8231] wherever appropriate. 786 The PCEP extensions for scheduling MUST NOT be used if one or both 787 PCEP speakers have not set the corresponding bits in the STATEFUL- 788 PCE-CAPABILITY TLV in their respective OPEN message. If the PCEP 789 speaker supports the extensions of this specification but did not 790 advertise this capability, then upon receipt of LSP object with the 791 scheduled TLV, it MUST generate a PCEP Error (PCErr) with Error- 792 type=19 (Invalid Operation) and error-value TBD6 (Attempted LSP 793 Scheduling if the scheduling capability was not advertised), and it 794 SHOULD ignore the TLV. As per Section 7.1 of [RFC5440], a legacy 795 PCEP implementation that does not understand this specification, 796 would consider the scheduled TLVs as unknown and ignore them. 798 If the PCC decides that the scheduling parameters proposed in the 799 PCUpd/PCInitiate message are unacceptable, it MUST report this error 800 by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error- 801 value="Unacceptable parameters" in the LSP object (with scheduled 802 TLVs) in the PCRpt message to the PCE. 804 The scheduled TLVs MUST be included in the LSP object for the 805 scheduled LSPs, if the TLV is missing, the receiving PCEP speaker 806 MUST send a PCErr message with Error-type=6 (Mandatory Object 807 missing) and Error-value TBD5 (Scheduled TLV missing). 809 7. Implementation Status 811 [NOTE TO RFC EDITOR : This whole section and the reference to RFC 812 7942 is to be removed before publication as an RFC] 814 This section records the status of known implementations of the 815 protocol defined by this specification at the time of posting of this 816 Internet-Draft, and is based on a proposal described in [RFC7942]. 817 The description of implementations in this section is intended to 818 assist the IETF in its decision processes in progressing drafts to 819 RFCs. Please note that the listing of any individual implementation 820 here does not imply endorsement by the IETF. Furthermore, no effort 821 has been spent to verify the information presented here that was 822 supplied by IETF contributors. This is not intended as, and must not 823 be construed to be, a catalog of available implementations or their 824 features. Readers are advised to note that other implementations may 825 exist. 827 According to [RFC7942], "this will allow reviewers and working groups 828 to assign due consideration to documents that have the benefit of 829 running code, which may serve as evidence of valuable experimentation 830 and feedback that have made the implemented protocols more mature. 831 It is up to the individual working groups to use this information as 832 they see fit". 834 At the time of posting the -09 version of this document, there are no 835 known implementations of this mechanism. It is believed that two 836 vendors/organizations are considering prototype implementations, but 837 these plans are too vague to make any further assertions. 839 8. Security Considerations 841 This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED-LSP- 842 ATTRIBUTE TLV, the security considerations discussed in [RFC5440], 843 [RFC8231], and [RFC8281] continue to apply. In some deployments the 844 scheduling information could provide details about the network 845 operations that could be deemed as extra sensitive. Additionally, 846 snooping of PCEP messages with such data or using PCEP messages for 847 network reconnaissance may give an attacker sensitive information 848 about the operations of the network. A single PCEP message can now 849 instruct a PCC to set up and tear down an LSP every second for a 850 number of times. That single message could have a significant effect 851 on the network. Thus, such deployment should employ suitable PCEP 852 security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] 853 or [RFC8253]. The procedure based on Transport Layer Security (TLS) 854 in [RFC8253] is considered a security enhancement and thus is much 855 better suited for the sensitive information. PCCs may also need to 856 apply some form of rate limit to the processing of scheduled LSPs. 858 9. Manageability Consideration 860 9.1. Control of Function and Policy 862 The LSP-Scheduling feature MUST BE controlled per tunnel by the 863 active stateful PCE, the values for parameters like starting time, 864 duration SHOULD BE configurable by customer applications and based on 865 the local policy at PCE. The suggested default values for starting 866 time and duration are one day in seconds from the current time and 867 one year in seconds respectively. One day has 86,400 seconds. One 868 year has 31,536,000 seconds. 870 When configuring the parameters about time, a user SHOULD consider 871 leap-years and leap-seconds. 873 9.2. Information and Data Models 875 An implementation SHOULD allow the operator to view the capability 876 defined in this document. To serve this purpose, the PCEP YANG 877 module [I-D.ietf-pce-pcep-yang] could be extended. 879 9.3. Liveness Detection and Monitoring 881 Mechanisms defined in this document do not imply any new liveness 882 detection and monitoring requirements in addition to those already 883 listed in [RFC5440]. 885 9.4. Verify Correct Operations 887 Mechanisms defined in this document do not imply any new operation 888 verification requirements in addition to those already listed in 889 [RFC5440]. 891 9.5. Requirements On Other Protocols 893 Mechanisms defined in this document do not imply any new requirements 894 on other protocols. 896 9.6. Impact On Network Operations 898 Mechanisms defined in this document do not have any impact on network 899 operations in addition to those already listed in [RFC5440]. 901 10. IANA Considerations 903 10.1. PCEP TLV Type Indicators 905 This document defines the following new PCEP TLVs. IANA maintains a 906 sub-registry "PCEP TLV Type Indicators" in the "Path Computation 907 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 908 the following allocations from this sub-registry. 910 Value Meaning Reference 911 TBD1 SCHED-LSP-ATTRIBUTE This document 912 TBD2 SCHED-PD-LSP-ATTRIBUTE This document 914 10.1.1. Opt Field in SCHED-PD-LSP-ATTRIBUTE TLV 916 IANA is requested to create and maintain a new sub-registry named 917 "SCHED-PD-LSP-ATTRIBUTE TLV Opt field" within the "Path Computation 918 Element Protocol (PCEP) Numbers" registry. Initial values for the 919 sub-registry are given below. New values are assigned by Standards 920 Action [RFC8126]. 922 Value Name Reference 923 ----- ---- ---------- 924 0 Reserved 925 1 REPEAT-EVERY-DAY This document 926 2 REPEAT-EVERY-WEEK This document 927 3 REPEAT-EVERY-MONTH This document 928 4 REPEAT-EVERY-YEAR This document 929 5 REPEAT-EVERY-REPEAT-TIME-LENGTH This document 930 6-14 Unassigned 931 15 Reserved 933 10.1.2. Schedule TLVs Flag Field 935 IANA is requested to create a new sub-registry, named "Schedule TLVs 936 Flag Field", within the "Path Computation Element Protocol (PCEP) 937 Numbers" registry. New values are assigned by Standards Action 938 [RFC8126]. Each bit should be tracked with the following qualities: 940 o Bit number (counting from bit 0 as the most significant bit) 942 o Capability description 944 o Defining RFC 946 The following values are defined in this document: 948 Bit Description Reference 949 0-4 Unassigned 950 5 R-bit This document 951 6 C-bit This document 952 7 A-bit This document 954 10.2. STATEFUL-PCE-CAPABILITY TLV Flag field 956 This document defines new bits in the Flags field in the STATEFUL- 957 PCE-CAPABILITY TLV in the OPEN object. IANA maintains a sub-registry 958 "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "Path Computation 959 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 960 the following allocations from this sub-registry. 962 The following values are defined in this document: 964 Bit Description Reference 965 TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document 966 TBD4 PD-LSP-CAPABLITY (PD-bit) This document 968 10.3. PCEP-Error Object 970 IANA is requested to allocate the following new error types to the 971 existing error values within the "PCEP-ERROR Object Error Types and 972 Values" subregistry of the "Path Computation Element Protocol (PCEP) 973 Numbers" registry: 975 Error-Type Meaning 976 6 Mandatory Object missing 978 Error-value 979 TBD5: Scheduled TLV missing 981 19 Invalid Operation 983 Error-value 984 TBD6: Attempted LSP Scheduling if the scheduling 985 capability was not advertised 987 11. Acknowledgments 989 The authors of this document would also like to thank Rafal Szarecki, 990 Adrian Farrel, Cyril Margaria for the review and comments. 992 12. References 994 12.1. Normative References 996 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 997 Requirement Levels", BCP 14, RFC 2119, 998 DOI 10.17487/RFC2119, March 1997, 999 . 1001 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1002 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1003 DOI 10.17487/RFC5440, March 2009, 1004 . 1006 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1007 Writing an IANA Considerations Section in RFCs", BCP 26, 1008 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1009 . 1011 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1012 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1013 May 2017, . 1015 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1016 Computation Element Communication Protocol (PCEP) 1017 Extensions for Stateful PCE", RFC 8231, 1018 DOI 10.17487/RFC8231, September 2017, 1019 . 1021 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1022 and D. Dhody, "Optimizations of Label Switched Path State 1023 Synchronization Procedures for a Stateful PCE", RFC 8232, 1024 DOI 10.17487/RFC8232, September 2017, 1025 . 1027 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1028 Computation Element Communication Protocol (PCEP) 1029 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1030 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1031 . 1033 12.2. Informative References 1035 [I-D.ietf-detnet-architecture] 1036 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1037 "Deterministic Networking Architecture", draft-ietf- 1038 detnet-architecture-13 (work in progress), May 2019. 1040 [I-D.ietf-pce-pcep-yang] 1041 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1042 YANG Data Model for Path Computation Element 1043 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1044 yang-13 (work in progress), October 2019. 1046 [I-D.litkowski-pce-state-sync] 1047 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 1048 Stateful Path Computation Element (PCE) Communication 1049 Procedures.", draft-litkowski-pce-state-sync-07 (work in 1050 progress), January 2020. 1052 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1053 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1054 June 2010, . 1056 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1057 Computation Element Architecture", RFC 7399, 1058 DOI 10.17487/RFC7399, October 2014, 1059 . 1061 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1062 Code: The Implementation Status Section", BCP 205, 1063 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1064 . 1066 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1067 Stateful Path Computation Element (PCE)", RFC 8051, 1068 DOI 10.17487/RFC8051, January 2017, 1069 . 1071 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1072 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1073 Path Computation Element Communication Protocol (PCEP)", 1074 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1075 . 1077 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1078 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1079 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1080 July 2018, . 1082 [RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework 1083 for Scheduled Use of Resources", RFC 8413, 1084 DOI 10.17487/RFC8413, July 2018, 1085 . 1087 Appendix A. Contributors Addresses 1089 Dhruv Dhody 1090 Huawei 1091 Divyashree Techno Park, Whitefield 1092 Bangalore, Karnataka 560066 1093 India 1095 Email: dhruv.ietf@gmail.com 1097 Xufeng Liu 1098 Ericsson 1099 USA 1100 Email: xliu@kuatrotech.com 1102 Mehmet Toy 1103 Verizon 1104 USA 1105 Email: mehmet.toy@verizon.com 1107 Vic Liu 1108 China Mobile 1109 No.32 Xuanwumen West Street, Xicheng District 1110 Beijing, 100053 1111 China 1112 Email: liu.cmri@gmail.com 1113 Lei Liu 1114 Fujitsu 1115 USA 1116 Email: lliu@us.fujitsu.com 1118 Khuzema Pithewan 1119 Infinera 1120 Email: kpithewan@infinera.com 1122 Zitao Wang 1123 Huawei 1124 101 Software Avenue, Yuhua District 1125 Nanjing, Jiangsu 210012 1126 China 1128 Email: wangzitao@huawei.com 1130 Xian Zhang 1131 Huawei Technologies 1132 Research Area F3-1B, 1133 Huawei Industrial Base, 1134 Shenzhen, 518129, China 1136 Email: zhang.xian@huawei.com 1138 Authors' Addresses 1140 Huaimo Chen (editor) 1141 Futurewei 1142 Boston, MA 1143 USA 1145 Email: huaimo.chen@futurewei.com 1147 Yan Zhuang (editor) 1148 Huawei 1149 101 Software Avenue, Yuhua District 1150 Nanjing, Jiangsu 210012 1151 China 1153 Email: zhuangyan.zhuang@huawei.com 1154 Qin Wu 1155 Huawei 1156 101 Software Avenue, Yuhua District 1157 Nanjing, Jiangsu 210012 1158 China 1160 Email: bill.wu@huawei.com 1162 Daniele Ceccarelli 1163 Ericsson 1164 Via A. Negrone 1/A 1165 Genova - Sestri Ponente 1166 Italy 1168 Email: daniele.ceccarelli@ericsson.com