idnits 2.17.1 draft-ietf-pce-stateful-pce-lsp-scheduling-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 16, 2019) is 1715 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 352, but not defined == Missing Reference: 'Tb' is mentioned on line 352, but not defined == Missing Reference: 'TBD1' is mentioned on line 571, but not defined == Missing Reference: 'TBD2' is mentioned on line 662, but not defined == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-12 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-06 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: February 17, 2020 Q. Wu 6 Huawei 7 D. Ceccarelli 8 Ericsson 9 August 16, 2019 11 PCEP Extensions for LSP scheduling with stateful PCE 12 draft-ietf-pce-stateful-pce-lsp-scheduling-09 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 February 17, 2020. 40 Copyright Notice 42 Copyright (c) 2019 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 . . . . . . . . . . 10 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 . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 16 78 6.4. The PCReq message . . . . . . . . . . . . . . . . . . . . 16 79 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 17 80 6.6. The PCErr Message . . . . . . . . . . . . . . . . . . . . 17 81 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . 19 88 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 19 89 9.6. Impact On Network Operations . . . . . . . . . . . . . . 19 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 19 92 10.2. STATEFUL-PCE-CAPABILITY TLV Flag field . . . . . . . . . 20 93 10.3. Schedule TLVs Flag Field . . . . . . . . . . . . . . . . 20 94 10.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 21 95 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 98 12.2. Informative References . . . . . . . . . . . . . . . . . 22 99 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 23 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 102 1. Introduction 104 The Path Computation Element Protocol (PCEP) defined in [RFC5440] is 105 used between a Path Computation Element (PCE) and a Path Computation 106 Client (PCC) (or other PCE) to enable path computation of Multi- 107 protocol Label Switching (MPLS) Traffic Engineering Label Switched 108 Paths (TE LSPs). 110 [RFC8231] describes a set of extensions to PCEP to provide stateful 111 control. A stateful PCE has access to not only the information 112 carried by the network's Interior Gateway Protocol (IGP) but also the 113 set of active paths and their reserved resources for its 114 computations. The additional state allows the PCE to compute 115 constrained paths while considering individual LSPs and their 116 interactions. 118 Traditionally, the usage and allocation of network resources, 119 especially bandwidth, can be supported by a Network Management System 120 (NMS) operation such as path pre-establishment. However, this does 121 not provide efficient network usage since the established paths 122 exclude the possibility of being used by other services even when 123 they are not used for undertaking any service. [RFC8413] then 124 provides a framework that describes and discusses the problem, and 125 defines an appropriate architecture for the scheduled reservation of 126 TE resources. 128 The scheduled reservation of TE resources allows network operators to 129 reserve resources in advance according to the agreements with their 130 customers, and allows them to transmit data about scheduling such as 131 a specified start time and duration, for example for a scheduled bulk 132 data replication between data centers. It enables the activation of 133 bandwidth usage at the time the service really being used while 134 letting other services use it when this service is not using it. The 135 requirement of scheduled LSP provision is mentioned in [RFC8231] and 136 [RFC7399], so as to provide more efficient network resource usage for 137 traffic engineering, which hasn't been solved yet. Also, for 138 deterministic networks [I-D.ietf-detnet-architecture], the scheduled 139 LSP or temporal LSP can provide a better network resource usage for 140 guaranteed links. This idea can also be applied in segment routing 141 [RFC8402] to schedule the network resources over the whole network in 142 a centralized manner as well. 144 With this in mind, this document defines a set of extensions needed 145 to PCEP used for stateful PCEs so as to enable LSP scheduling for 146 path computation and LSP setup/deletion based on the actual network 147 resource usage duration of a traffic service. A scheduled LSP is 148 characterized by a starting time and a duration. When the end of the 149 LSP life is reached, it is deleted to free up the resources for other 150 LSPs (scheduled or not). 152 2. Conventions used in this document 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 2.1. Terminology 162 The following terminologies are re-used from existing PCE documents. 164 o Active Stateful PCE [RFC8231]; 166 o Passive Stateful PCE [RFC8231]; 168 o Delegation [RFC8231]; 170 o PCE-Initiated LSP [RFC8281]; 172 o PCC [RFC5440], [RFC8231]; 174 o PCE [RFC5440], [RFC8231]; 176 o TE LSP [RFC5440], [RFC8231]; 178 o TED [RFC5440], [RFC8231]; 180 o LSP-DB [RFC8231]; 182 In addition, this document defines the following terminologies. 184 Scheduled TE LSP (or Scheduled LSP for short): an LSP with the 185 scheduling attributes, that carries traffic flow demand at a 186 starting time and lasts for a certain duration (or from a starting 187 time to an ending time, where the ending time is the starting time 188 plus the duration). A scheduled LSP is also called a temporal 189 LSP. The PCE operates path computation per LSP availability for 190 the required time and duration. 192 Scheduled LSP-DB: a database of scheduled LSPs. 194 Scheduled TED: Traffic engineering database with the awareness of 195 scheduled resources for TE. This database is generated by the PCE 196 from the information in TED and scheduled LSP-DB and allows 197 knowing, at any time, the amount of available resources (does not 198 include failures in the future). 200 Starting time (start-time): This value indicates when the scheduled 201 LSP is used and the corresponding LSP must be setup and active. 202 In other time (i.e., before the starting time or after the 203 starting time plus Duration), the LSP can be inactive to include 204 the possibility of the resources being used by other services. 206 Duration: This value indicates the time duration that the LSP is 207 undertaken by a traffic flow and the corresponding LSP must be 208 setup and active. At the end of which, the LSP is torn down and 209 removed from the data base. 211 3. Motivation and Objectives 213 A stateful PCE [RFC8231] can support better efficiency by using LSP 214 scheduling described in the use case of [RFC8051]. This requires the 215 PCE to maintain the scheduled LSPs and their associated resource 216 usage, e.g. bandwidth for Packet-switched network, as well as have 217 the ability to trigger signaling for the LSP setup/tear-down at the 218 correct time. 220 Note that existing configuration tools can be used for LSP 221 scheduling, but as highlighted in section 3.1.3 of [RFC8231] as well 222 as discussions in [RFC8413], doing this as a part of PCEP in a 223 centralized manner, has obvious advantages. 225 This document provides a set of extensions to PCEP to enable LSP 226 scheduling for LSP creation/deletion under the stateful control of a 227 PCE and according to traffic service requests from customers, so as 228 to improve the usage of network resources. 230 4. Procedures and Mechanisms 232 4.1. LSP Scheduling Overview 234 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for 235 customers' traffic services at its actual usage time, so as to 236 improve the network resource efficient utilization. 238 For stateful PCE supporting LSP scheduling, there are two types of 239 LSP databases used in this document. One is the LSP-DB defined in 240 PCEP [RFC8231], while the other is the scheduled LSP database (SLSP- 241 DB, see section 6). The SLSP-DB records scheduled LSPs and is used 242 in conjunction with the TED and LSP-DB. Note that the two types of 243 LSP databases can be implemented in one physical database or two 244 different databases. This is an implementation matter and this 245 document does not state any preference. 247 Furthermore, a scheduled TED can be generated from the scheduled LSP- 248 DB, LSP-DB and TED to indicate the network links and nodes with 249 resource availability information for now and future. The scheduled 250 TED should be maintained by all PCEs within the network environment. 252 In case of implementing PCC-initiated scheduled LSPs, before a PCC 253 delegates a scheduled LSP, it MAY use the PCReq/PCRep messages to 254 learn the path for the scheduled LSP. A PCC MUST delegate a 255 scheduled LSP with information of its scheduling parameters, 256 including the starting time and the duration using PCRpt message. 257 Since the LSP is not yet signaled, at the time of delegation the LSP 258 would be in down state. Upon receiving the delegation of the 259 scheduled LSP, a stateful PCE SHALL check the scheduled TED for the 260 network resource availability on network nodes and computes a path 261 for the LSP with the scheduling information and update to the PCC as 262 per the active stateful PCE techniques [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 multiple PCE environment, a PCE MUST synchronize to other PCEs 270 within the network, so as to keep their scheduling information 271 synchronized. There are many ways that this could be achieved: one 272 such mechanism is described in [I-D.litkowski-pce-state-sync]. Which 273 way is used to achieve this is out of scope for this document. The 274 scheduled TED can be determined from the synchronized SLSP-DB. The 275 PCE with delegation for the scheduled LSP would report the scheduled 276 LSP to other PCEs, any future update to the scheduled LSP is also 277 updated to other PCEs. This way the state of all scheduled LSPs are 278 synchronized among the PCEs. [RFC7399] discusses some 279 synchronization issues and considerations, that are also applicable 280 to the scheduled databases. 282 The scheduled LSP can also be initiated by PCE itself. In case of 283 implementing PCE-initiated scheduled LSP, the stateful PCE shall 284 check the network resource availability for the traffic and computes 285 a path for the scheduled LSP and initiate a scheduled LSP at the PCC 286 and synchronize the scheduled LSP to other PCEs. Note that, the PCC 287 could be notified immediately or at the starting time of the 288 scheduled LSP based on the local policy. In case of former SCHED- 289 LSP-ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the message 290 where as for the latter SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be 291 included. Either way the synchronization to other PCEs should be 292 done when the scheduled LSP is created. 294 In both modes, for activation of scheduled LSPs, the PCC could 295 initiate the setup of scheduled LSP at the start time by itself or 296 wait for the PCE to update the PCC to initiate the setup of LSP. 297 Similarly on the scheduling usage expires, the PCC could initiate the 298 removal by itself or wait for the PCE to request the removal of the 299 LSP. This is based on the Flag set in SCHED-LSP-ATTRIBUTE TLV. 301 4.2. Support of LSP Scheduling 303 4.2.1. LSP Scheduling 305 For a scheduled LSP, a user configures it with an arbitrary 306 scheduling duration from time Ta to time Tb, which may be represented 307 as [Ta, Tb]. 309 When an LSP is configured with arbitrary scheduling duration [Ta, 310 Tb], a path satisfying the constraints for the LSP in the scheduling 311 duration is computed and the LSP along the path is set up to carry 312 traffic from time Ta to time Tb. 314 4.2.2. Periodical LSP Scheduling 316 In addition to LSP Scheduling at an arbitrary time period, there are 317 also periodical LSP Scheduling. 319 A periodical LSP Scheduling represents Scheduling LSP every time 320 interval. It has a scheduling duration such as [Ta, Tb], a number of 321 repeats such as 10 (repeats 10 times), and a repeat cycle/time 322 interval such as a week (repeats every week). The scheduling 323 interval: "[Ta, Tb] repeats n times with repeat cycle C" represents 324 n+1 scheduling intervals as follows: 326 [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC] 328 When an LSP is configured with a scheduling interval such as "[Ta, 329 Tb] repeats 10 times with a repeat cycle a week" (representing 11 330 scheduling intervals), a path satisfying the constraints for the LSP 331 in each of the scheduling intervals represented by the periodical 332 scheduling interval is computed and the LSP along the path is set up 333 to carry traffic in each of the scheduling intervals. 335 4.2.2.1. Elastic Time LSP Scheduling 337 In addition to the basic LSP scheduling at an arbitrary time period, 338 another option is elastic time intervals, which is represented as 339 within -P and Q, where P and Q is an amount of time such as 300 340 seconds. P is called elastic range lower bound and Q is called 341 elastic range upper bound. 343 For a simple time interval such as [Ta, Tb] with an elastic range, 344 elastic time interval: "[Ta, Tb] within -P and Q" means a time period 345 from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb 346 is shifted by the same 'X'. 348 When an LSP is configured with elastic time interval "[Ta, Tb] within 349 -P and Q", a path is computed such that the path satisfies the 350 constraints for the LSP in the time period from (Ta+X) to (Tb+X) 351 and |X| is the minimum value from 0 to max(P, Q). That is, [Ta+X, 352 Tb+X] is the time interval closest to time interval [Ta, Tb] within 353 the elastic range. The LSP along the path is set up to carry traffic 354 in the time period from (Ta+X) to (Tb+X). 356 Similarly, for a recurrent time interval with an elastic range, 357 elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C 358 within -P and Q" represents n+1 simple elastic time intervals as 359 follows: 361 [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn] 362 where -P <= Xi <= Q, i = 0, 1, 2, ..., n. 364 If a user wants to keep the same repeat cycle between any two 365 adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n 366 times with repeat cycle C within -P and Q SYNC" may be used, which 367 represents n+1 simple elastic time intervals as follows: 369 [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X] 370 where -P <= X <= Q. 372 4.2.2.2. Grace Periods 374 Besides the stated time scheduling, a user may want to have some 375 grace periods for each or some of the time intervals for the LSP. 376 Two grace periods may be configured for a time interval. One is the 377 grace period before the time interval, called grace-before, which 378 extends the lifetime of the LSP for grace-before (such as 30 seconds) 379 before the time interval. The other is the one after the time 380 interval, called grace-after, which extends the lifetime of the LSP 381 for grace-after (such as 60 seconds) after the time interval. 383 When an LSP is configured with a simple time interval such as [Ta, 384 Tb] with grace periods such as grace-before GB and grace-after GA, a 385 path is computed such that the path satisfies the constraints for the 386 LSP in the time period from Ta to Tb. The LSP along the path is set 387 up to carry traffic in the time period from (Ta-GB) to (Tb+GA). 388 During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the 389 LSP is up to carry traffic (maybe in best effort). 391 4.3. Scheduled LSP creation 393 In order to realize PCC-Initiated scheduled LSPs in a centralized 394 network environment, a PCC has to separate the setup of an LSP into 395 two steps. The first step is to request/delegate and get an LSP but 396 not signal it over the network. The second step is to signal the 397 scheduled LSP over the LSRs (Label Switching Router) at its starting 398 time. 400 For PCC-Initiated scheduled LSPs, a PCC can delegate the scheduled 401 LSP by sending a path computation report (PCRpt) message by including 402 its demanded resources with the scheduling information to a stateful 403 PCE. Note the PCC MAY use the PCReq/PCRep with scheduling 404 information before delegating. 406 Upon receiving the delegation via PCRpt message, the stateful PCE 407 computes the path for the scheduled LSP per its starting time and 408 duration based on the network resource availability stored in 409 scheduled TED (see Section 4.1). 411 The stateful PCE will send a PCUpd message with the scheduled path 412 information as well as the scheduled resource information for the 413 scheduled LSP to the PCC. The PCE SHOULD add the scheduled LSP into 414 its scheduled LSP-DB and update its scheduled TED. 416 For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path 417 for the scheduled LSP per requests from network management systems 418 automatically based on the network resource availability in the 419 scheduled TED, send a PCInitiate message with the path information 420 back to the PCC. Based on the local policy, the PCInitiate message 421 could be sent immediately to ask PCC to create a scheduled LSP (as 422 per this document) or the PCInitiate message could be sent at the 423 start time to the PCC to create a normal LSP (as per [RFC8281]). 425 In both modes: 427 o The stateful PCE is required to update its local scheduled LSP-DB 428 and scheduled TED with the scheduled LSP. Besides, it shall send 429 a PCRpt message with the scheduled LSP to other PCEs within the 430 network, so as to achieve the scheduling traffic engineering 431 information synchronization. 433 o Upon receiving the PCUpd message or PCInitiate message for the 434 scheduled LSP from PCEs with a found path, the PCC knows that it 435 is a scheduled path for the LSP and does not trigger signaling for 436 the LSP setup on LSRs immediately. 438 o The stateful PCE can update the Scheduled LSP parameters on any 439 network events using the PCUpd message to PCC. These changes are 440 also synchronized to other PCEs. 442 o Based on the configuration (and the C flag in scheduled TLVs), 443 when it is time (i.e., at the start time) for the LSP to be set 444 up, either the PCC triggers the LSP to be signaled or the 445 delegated PCE sends a PCUpd message to the head end LSR providing 446 the updated path to be signaled (with A flag set to indicate LSP 447 activation). 449 4.4. Scheduled LSP Modifications 451 After a scheduled LSP is configured, a user may change its parameters 452 including the requested time as well as the bandwidth. 454 In PCC-Initiated case, the PCC can send a PCRpt message for the 455 scheduled LSP with updated parameters as well as scheduled 456 information included in the SCHED-LSP-ATTRIBUTE TLV (see 457 Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) 458 carried in the LSP Object. The PCE would take the updated resources 459 and schedule into considerations and update the new path for the 460 scheduled LSP to the PCC as well as synchronize to other PCEs in the 461 network. In case path cannot be set based on new requirements the 462 same should be conveyed by the use of empty ERO in the PCEP messages. 464 In PCE-Initiated case, the Stateful PCE would recompute the path 465 based on updated parameters as well as scheduled information. In 466 case it has already conveyed to the PCC this information by sending a 467 PCInitiate message, it should update the path and other scheduling 468 and resource information by sending a PCUpd message. 470 4.5. Scheduled LSP activation and deletion 472 In PCC-Initiated case, based on the configuration (and the C flag in 473 scheduled TLVs), when it is time (i.e., at the start time) for the 474 LSP to be set up, either the PCC triggers the LSP to be signaled or 475 the delegated PCE sends a PCUpd message to the head end LSR providing 476 the updated path to be signaled (with A flag set to indicate LSP 477 activation). The PCC would report the status of the active LSP as 478 per the procedures in [RFC8231] and at this time the LSP MUST be 479 considered as part of the LSP-DB. The A flag MUST be set in the 480 scheduled TLVs to indicate that the LSP is active now. After the 481 scheduled duration expires, based on the C flag, the PCC triggers the 482 LSP deletion on itself or the delegated PCE sends a PCUpd message to 483 the PCC to delete the LSP as per the procedures in [RFC8231]. 485 In PCE-Initiated case, based on the local policy, if the scheduled 486 LSP is already conveyed to the PCC at the time of creation, the 487 handling of LSP activation and deletion is handled in the same way as 488 PCC-Initiated case as per the setting of C flag. In other case, the 489 PCE would send the PCInitiate message at the start time to the PCC to 490 create a normal LSP without the scheduled TLVs and remove the LSP 491 after the duration expires as per [RFC8281]. 493 5. PCEP Objects and TLVs 495 5.1. Stateful PCE Capability TLV 497 After a TCP connection for a PCEP session has been established, a PCC 498 and a PCE indicates its ability to support LSP scheduling during the 499 PCEP session establishment phase. For a multiple-PCE environment, 500 the PCEs should also establish PCEP session and indicate its ability 501 to support LSP scheduling among PCEP peers. The Open Object in the 502 Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in 503 [RFC8231]. Note that the STATEFUL-PCE-CAPABILITY TLV is defined in 504 [RFC8231] and updated in [RFC8281] and [RFC8232]". In this document, 505 we define a new flag bit B (SCHED-LSP-CAPABLITY) flag for the 506 STATEFUL-PCE-CAPABILITY TLV to indicate the support of LSP scheduling 507 and another flag bit PD (PD-LSP-CAPABLITY) to indicate the support of 508 LSP periodical scheduling. 510 B (LSP-SCHEDULING-CAPABILITY - 1 bit) [Bit Position - TBD3]: If set 511 to 1 by a PCC, the B Flag indicates that the PCC allows LSP 512 scheduling; if set to 1 by a PCE, the B Flag indicates that the 513 PCE is capable of LSP scheduling. The B bit MUST be set by both 514 PCEP peers in order to support LSP scheduling for path 515 computation. 517 PD (PD-LSP-CAPABLITY - 1 bit): [Bit Position - TBD4] If set to 1 by 518 a PCC, the PD Flag indicates that the PCC allows LSP scheduling 519 periodically; if set to 1 by a PCE, the PD Flag indicates that the 520 PCE is capable of periodical LSP scheduling. The PD bit MUST be 521 set by both PCEP peers in order to support periodical LSP 522 scheduling for path computation. 524 5.2. LSP Object 526 The LSP object is defined in [RFC8231]. This document adds an 527 optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an 528 optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP scheduling. 530 The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates 531 that this LSP is requesting scheduled parameters while the SCHED-PD- 532 LSP-ATTRIBUTE TLV indicates that this scheduled LSP is periodical. 533 The scheduled LSP attribute TLV MUST be present in LSP Object for 534 each scheduled LSP carried in the PCEP messages. For periodical 535 LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in LSP Object for 536 each periodic scheduled LSP carried in the PCEP messages. 538 Only one of these TLV SHOULD be present in the LSP object. In case 539 more than one scheduling TLV is found, the first instance is 540 processed and others ignored. 542 5.2.1. SCHED-LSP-ATTRIBUTE TLV 544 The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV within 545 the LSP object for LSP scheduling for the requesting traffic service. 547 This TLV SHOULD NOT be included unless both PCEP peers have set the B 548 (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV 549 carried in the Open message. 551 The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1. 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Type (TBD1) | Length | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 |R|C|A| Flags | Reserved (0) | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Start-Time | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Duration | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | GrB | GrA | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Elastic-Lower-Bound | Elastic-Upper-Bound | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 1: SCHED-LSP-ATTRIBUTE TLV 571 The type of the TLV is [TBD1] and the TLV has a fixed length of 20 572 octets. 574 The fields in the format are: 576 Flags (8 bits): Following flags are defined in this document 578 R (1 bit): Set to 1 to indicate the Start-Time is a relative 579 time, which is relative to the current time; set to 0 to 580 indicate that the 32-bit Start-Time is an absolute time, which 581 is the number of seconds since the epoch. The epoch is 1 582 January 1900 at 00:00 UTC. It wraps around every 2^32 seconds, 583 which is roughly 136 years. The next wraparound will occur in 584 the year 2036. 586 C (1 bit): Set to 1 to indicate the PCC is responsible to setup 587 and remove the scheduled LSP based on the Start-Time and 588 duration. 590 A (1 bit): Set to 1 to indicate the scheduled LSP has been 591 activated and should be considered as part of LSP-DB (instead 592 of Scheduled LSP-DB). 594 Reserved (24 bits): This field MUST be set to zero on transmission 595 and MUST be ignored on receipt. 597 Start-Time (32 bits): This value in seconds, indicates when the 598 scheduled LSP is used to carry traffic and the corresponding LSP 599 must be setup and activated. 601 Duration (32 bits): The value in seconds, indicates the duration 602 that the LSP is undertaken by a traffic flow and the corresponding 603 LSP must be up to carry traffic. At the expiry of this duration, 604 the LSP is torn down and deleted. 606 The Start-Time indicates a calendar time (e.g.,2018/12/13 8:29:58), 607 at or before which the scheduled LSP must be set up. The value of 608 the Start-Time represents the number of seconds since 00:00 hours,Jan 609 1, 1970 UTC when R bit is set to 0. When R bit is set to 1, it 610 represents the number of seconds from the current time. 612 In addition, it contains an non zero grace-before and grace-after if 613 grace periods are configured. It includes an non zero elastic range 614 lower bound and upper bound if there is an elastic range configured. 616 o GrB (Grace-Before -16 bits): The grace period time length in 617 seconds before the starting time. 619 o GrA (Grace-After -16 bits): The grace period time length in 620 seconds after time interval [starting time, starting time + 621 duration]. 623 o Elastic-Lower-Bound (16 bits): The maximum amount of time in 624 seconds that time interval can shift to lower/left. 626 o Elastic-Upper-Bound (16 bits): The maximum amount of time in 627 seconds that time interval can shift to upper/right. 629 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV 631 The periodical LSP is a special case of LSP scheduling. The traffic 632 service happens in a series of repeated time intervals. The SCHED- 633 PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the 634 LSP object for this periodical LSP scheduling. 636 This TLV SHOULD NOT be included unless both PCEP peers have set the B 637 (LSP-SCHEDULING-CAPABILITY bit) and PD (PD-LSP-CAPABLITY bit) in 638 STATEFUL-PCE-CAPABILITY TLV carried in open message. 640 The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2. 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Type (TBD2) | Length | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 |R|C|A| Flags | Opt | NR | Reserved (0) | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Start-Time | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Duration | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Repeat-time-length | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | GrB | GrA | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Elastic-Lower-Bound | Elastic-Upper-Bound | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Figure 2: SCHED-PD-LSP-ATTRIBUTE TLV 662 The type of the TLV is [TBD2] and the TLV has a fixed length of 24 663 octets. The description, format and meaning of the Flags (R, C and A 664 bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and 665 Elastic-Upper-Bound fields remains same as SCHED-LSP-ATTRIBUTE TLV. 667 The following fields are new : 669 Opt: (4 bits) Indicates options to repeat. 671 Options = 1: repeat every day; 673 Options = 2: repeat every week; 675 Options = 3: repeat every month; 677 Options = 4: repeat every year; 679 Options = 5: repeat every Repeat-time-length. 681 NR: (12 bits) The number of repeats. In each of repeats, LSP 682 carries traffic. 684 Reserved (8 bits): This field MUST be set to zero on transmission 685 and MUST be ignored on receipt. 687 Repeat-time-length: (32 bits) The time length in seconds after which 688 LSP starts to carry traffic again for the Duration. 690 6. The PCEP Messages 692 6.1. The PCRpt Message 694 Path Computation State Report (PCRpt) is a PCEP message sent by a PCC 695 to a PCE to report the status of one or more LSPs as per [RFC8231]. 696 Each LSP State Report in a PCRpt message contains the actual LSP's 697 path, bandwidth, operational and administrative status, etc. An LSP 698 Status Report carried on a PCRpt message is also used in delegation 699 or revocation of control of an LSP to/from a PCE. In case of 700 scheduled LSP, the scheduled TLVs MUST be carried in the LSP object 701 and the ERO conveys the intended path for the scheduled LSP. The 702 scheduled LSP MUST be delegated to a PCE. This message is also used 703 to synchronize the scheduled LSPs to other PCE as described in 704 [RFC8231] 706 6.2. The PCUpd Message 708 Path Computation Update Request (PCUpd) is a PCEP message sent by a 709 PCE to a PCC to update LSP parameters, on one or more LSPs as per 710 [RFC8231]. Each LSP Update Request on a PCUpd message contains all 711 LSP parameters that a PCE wishes to be set for a given LSP. In case 712 of scheduled LSP, the scheduled TLVs MUST be carried in the LSP 713 object and the ERO conveys the intended path for the scheduled LSP. 714 In case no path can be found, an empty ERO is used. The A bit is 715 used in PCUpd message to indicate the activation of the scheduled LSP 716 in case the PCE is responsible for the activation (as per the C bit). 718 6.3. The PCInitiate Message 720 An LSP Initiate Request (PCInitiate) message is a PCEP message sent 721 by a PCE to a PCC to trigger LSP instantiation or deletion as per 722 [RFC8281]. In case of scheduled LSP, based on the local policy, PCE 723 MAY convey the scheduled LSP to the PCC by including the scheduled 724 TLVs in the LSP object. Or the PCE would initiate the LSP only at 725 the start time of the scheduled LSP as per the [RFC8281] without the 726 use of scheduled TLVs. 728 6.4. The PCReq message 730 The Path Computation Request (PCReq) message is a PCEP message sent 731 by a PCC to a PCE to request a path computation [RFC5440] and it may 732 contain the LSP object [RFC8231] to identify the LSP for which the 733 path computation is requested. In case of scheduled LSP, the 734 scheduled TLVs MUST be carried in the LSP object in PCReq message to 735 request the path computation based on scheduled TED and LSP-DB. A 736 PCC MAY use PCReq message to obtain the scheduled path before 737 delegating the LSP. 739 6.5. The PCRep Message 741 The Path Computation Reply (PCRep) message is a PCEP message sent by 742 a PCE to a PCC in reply to a path computation request [RFC5440] and 743 it may contain the LSP object [RFC8231] to identify the LSP for which 744 the path is computed. A PCRep message can contain either a set of 745 computed paths if the request can be satisfied, or a negative reply 746 if not. The negative reply may indicate the reason why no path could 747 be found. In case of scheduled LSP, the scheduled TLVs MUST be 748 carried in the LSP object in PCRep message to indicate the path 749 computation based on scheduled TED and LSP-DB. A PCC and PCE MAY use 750 PCReq and PCRep message to obtain the scheduled path before 751 delegating the LSP. 753 6.6. The PCErr Message 755 The Path Computation Error (PCErr) message is a PCEP message as 756 described in [RFC5440] for error reporting. The current document 757 defines new error values for several error types to cover failures 758 specific to scheduling and reuse the applicable error types and error 759 values of [RFC5440] and [RFC8231] wherever appropriate. 761 The PCEP extensions for scheduling MUST NOT be used if one or both 762 PCEP speakers have not set the corresponding bits in the STATEFUL- 763 PCE-CAPABILITY TLV in their respective OPEN message. If the PCEP 764 speaker supports the extensions of this specification but did not 765 advertise this capability, then upon receipt of LSP object with the 766 scheduled TLV, it MUST generate a PCEP Error (PCErr) with Error- 767 type=19 (Invalid Operation) and error-value TBD6 (Attempted LSP 768 Scheduling if the scheduling capability was not advertised), and it 769 SHOULD ignore the TLV. As per Section 7.1 of [RFC5440], a legacy 770 PCEP implementation that does not understand this specification, 771 would consider the scheduled TLVs as unknown and ignore them. 773 If the PCC decides that the scheduling parameters proposed in the 774 PCUpd/PCInitiate message are unacceptable, it MUST report this error 775 by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error- 776 value="Unacceptable parameters" in the LSP object (with scheduled 777 TLVs) in the PCRpt message to the PCE. 779 The scheduled TLVs MUST be included in the LSP object for the 780 scheduled LSPs, if the TLV is missing, the receiving PCEP speaker 781 MUST send a PCErr message with Error-type=6 (Mandatory Object 782 missing) and Error-value TBD5 (Scheduled TLV missing). 784 7. Implementation Status 786 [NOTE TO RFC EDITOR : This whole section and the reference to RFC 787 7942 is to be removed before publication as an RFC] 789 This section records the status of known implementations of the 790 protocol defined by this specification at the time of posting of this 791 Internet-Draft, and is based on a proposal described in [RFC7942]. 792 The description of implementations in this section is intended to 793 assist the IETF in its decision processes in progressing drafts to 794 RFCs. Please note that the listing of any individual implementation 795 here does not imply endorsement by the IETF. Furthermore, no effort 796 has been spent to verify the information presented here that was 797 supplied by IETF contributors. This is not intended as, and must not 798 be construed to be, a catalog of available implementations or their 799 features. Readers are advised to note that other implementations may 800 exist. 802 According to [RFC7942], "this will allow reviewers and working groups 803 to assign due consideration to documents that have the benefit of 804 running code, which may serve as evidence of valuable experimentation 805 and feedback that have made the implemented protocols more mature. 806 It is up to the individual working groups to use this information as 807 they see fit". 809 At the time of posting the -09 version of this document, there are no 810 known implementations of this mechanism. It is believed that two 811 vendors/organizations are considering prototype implementations, but 812 these plans are too vague to make any further assertions. 814 8. Security Considerations 816 This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED-LSP- 817 ATTRIBUTE TLV, the security considerations discussed in [RFC5440], 818 [RFC8231], and [RFC8281] continue to apply. In some deployments the 819 scheduling information could provide details about the network 820 operations that could be deemed as extra sensitive. Additionally, 821 snooping of PCEP messages with such data or using PCEP messages for 822 network reconnaissance may give an attacker sensitive information 823 about the operations of the network. A single PCEP message can now 824 instruct a PCC to set up and tear down an LSP every second for a 825 number of times. That single message could have a significant effect 826 on the network. Thus, such deployment should employ suitable PCEP 827 security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] 828 or [RFC8253]. The procedure based on Transport Layer Security (TLS) 829 in [RFC8253] is considered a security enhancement and thus is much 830 better suited for the sensitive information. PCCs may also need to 831 apply some form of rate limit to the processing of scheduled LSPs. 833 9. Manageability Consideration 835 9.1. Control of Function and Policy 837 The LSP-Scheduling feature MUST BE controlled per tunnel by the 838 active stateful PCE, the values for parameters like starting time, 839 duration SHOULD BE configurable by customer applications and based on 840 the local policy at PCE. 842 9.2. Information and Data Models 844 An implementation SHOULD allow the operator to view the capability 845 defined in this document. To serve this purpose, the PCEP YANG 846 module [I-D.ietf-pce-pcep-yang] could be extended. 848 9.3. Liveness Detection and Monitoring 850 Mechanisms defined in this document do not imply any new liveness 851 detection and monitoring requirements in addition to those already 852 listed in [RFC5440]. 854 9.4. Verify Correct Operations 856 Mechanisms defined in this document do not imply any new operation 857 verification requirements in addition to those already listed in 858 [RFC5440]. 860 9.5. Requirements On Other Protocols 862 Mechanisms defined in this document do not imply any new requirements 863 on other protocols. 865 9.6. Impact On Network Operations 867 Mechanisms defined in this document do not have any impact on network 868 operations in addition to those already listed in [RFC5440]. 870 10. IANA Considerations 872 10.1. PCEP TLV Type Indicators 874 This document defines the following new PCEP TLV. IANA maintains a 875 sub-registry "PCEP TLV Type Indicators" in the "Path Computation 876 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 877 the following allocations from this sub-registry. 879 Value Meaning Reference 880 TBD1 SCHED-LSP-ATTRIBUTE This document 881 TBD2 SCHED-PD-LSP-ATTRIBUTE This document 883 IANA is requested to create and maintain a new registry "Opt" under 884 SCHED-PD-LSP-ATTRIBUTE (TLV Type: TBD2). Initial values for the 885 registry are given below. 887 Value Name Definition 888 ----- ---- ---------- 889 0 Reserved 890 1 REPEAT-EVERY-DAY Section 5.2.2 891 2 REPEAT-EVERY-WEEK Section 5.2.2 892 3 REPEAT-EVERY-MONTH Section 5.2.2 893 4 REPEAT-EVERY-YEAR Section 5.2.2 894 5 REPEAT-EVERY-REPEAT-TIME-LENGTH Section 5.2.2 895 6-14 Unassigned 896 15 Reserved 898 10.2. STATEFUL-PCE-CAPABILITY TLV Flag field 900 This document defines new bits in the Flags field in the STATEFUL- 901 PCE-CAPABILITY TLV in the OPEN object. IANA maintains a sub-registry 902 "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "Path Computation 903 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 904 the following allocations from this sub-registry. 906 The following values are defined in this document: 908 Bit Description Reference 909 TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document 910 TBD4 PD-LSP-CAPABLITY (PD-bit) This document 912 10.3. Schedule TLVs Flag Field 914 IANA is requested to create a new sub-registry, named "Schedule TLVs 915 Flag Field", within the "Path Computation Element Protocol (PCEP) 916 Numbers" registry to manage the Flag field in the SCHED-LSP-ATTRIBUTE 917 and SCHED-PD-LSP-ATTRIBUTE TLVs. New values are assigned by 918 Standards Action [RFC8126]. Each bit should be tracked with the 919 following qualities: 921 o Bit number (counting from bit 0 as the most significant bit) 923 o Capability description 925 o Defining RFC 926 The following values are defined in this document: 928 Bit Description Reference 929 0 R-bit This document 930 1 C-bit This document 931 2 A-bit This document 933 10.4. PCEP-Error Object 935 IANA is requested to allocate the following new error types to the 936 existing error values within the "PCEP-ERROR Object Error Types and 937 Values" subregistry of the "Path Computation Element Protocol (PCEP) 938 Numbers" registry: 940 Error-Type Meaning 941 6 Mandatory Object missing 943 Error-value 944 TBD5: Scheduled TLV missing 946 19 Invalid Operation 948 Error-value 949 TBD6: Attempted LSP Scheduling if the scheduling 950 capability was not advertised 952 11. Acknowledgments 954 The authors of this document would also like to thank Rafal Szarecki, 955 Adrian Farrel, Cyril Margaria for the review and comments. 957 12. References 959 12.1. Normative References 961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 962 Requirement Levels", BCP 14, RFC 2119, 963 DOI 10.17487/RFC2119, March 1997, 964 . 966 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 967 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 968 DOI 10.17487/RFC5440, March 2009, 969 . 971 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 972 Writing an IANA Considerations Section in RFCs", BCP 26, 973 RFC 8126, DOI 10.17487/RFC8126, June 2017, 974 . 976 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 977 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 978 May 2017, . 980 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 981 Computation Element Communication Protocol (PCEP) 982 Extensions for Stateful PCE", RFC 8231, 983 DOI 10.17487/RFC8231, September 2017, 984 . 986 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 987 and D. Dhody, "Optimizations of Label Switched Path State 988 Synchronization Procedures for a Stateful PCE", RFC 8232, 989 DOI 10.17487/RFC8232, September 2017, 990 . 992 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 993 Computation Element Communication Protocol (PCEP) 994 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 995 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 996 . 998 12.2. Informative References 1000 [I-D.ietf-detnet-architecture] 1001 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1002 "Deterministic Networking Architecture", draft-ietf- 1003 detnet-architecture-13 (work in progress), May 2019. 1005 [I-D.ietf-pce-pcep-yang] 1006 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1007 YANG Data Model for Path Computation Element 1008 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1009 yang-12 (work in progress), July 2019. 1011 [I-D.litkowski-pce-state-sync] 1012 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 1013 Stateful Path Computation Element (PCE) Communication 1014 Procedures.", draft-litkowski-pce-state-sync-06 (work in 1015 progress), July 2019. 1017 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1018 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1019 June 2010, . 1021 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1022 Computation Element Architecture", RFC 7399, 1023 DOI 10.17487/RFC7399, October 2014, 1024 . 1026 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1027 Code: The Implementation Status Section", BCP 205, 1028 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1029 . 1031 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1032 Stateful Path Computation Element (PCE)", RFC 8051, 1033 DOI 10.17487/RFC8051, January 2017, 1034 . 1036 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1037 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1038 Path Computation Element Communication Protocol (PCEP)", 1039 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1040 . 1042 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1043 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1044 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1045 July 2018, . 1047 [RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework 1048 for Scheduled Use of Resources", RFC 8413, 1049 DOI 10.17487/RFC8413, July 2018, 1050 . 1052 Appendix A. Contributor Addresses 1054 Dhruv Dhody 1055 Huawei 1056 Divyashree Techno Park, Whitefield 1057 Bangalore, Karnataka 560066 1058 India 1060 Email: dhruv.ietf@gmail.com 1062 Xufeng Liu 1063 Ericsson 1064 USA 1065 Email: xliu@kuatrotech.com 1067 Mehmet Toy 1068 Verizon 1069 USA 1070 Email: mehmet.toy@verizon.com 1072 Vic Liu 1073 China Mobile 1074 No.32 Xuanwumen West Street, Xicheng District 1075 Beijing, 100053 1076 China 1077 Email: liu.cmri@gmail.com 1079 Lei Liu 1080 Fujitsu 1081 USA 1082 Email: lliu@us.fujitsu.com 1084 Khuzema Pithewan 1085 Infinera 1086 Email: kpithewan@infinera.com 1088 Zitao Wang 1089 Huawei 1090 101 Software Avenue, Yuhua District 1091 Nanjing, Jiangsu 210012 1092 China 1094 Email: wangzitao@huawei.com 1096 Xian Zhang 1097 Huawei Technologies 1098 Research Area F3-1B, 1099 Huawei Industrial Base, 1100 Shenzhen, 518129, China 1102 Email: zhang.xian@huawei.com 1104 Authors' Addresses 1106 Huaimo Chen (editor) 1107 Futurewei 1108 Boston, MA 1109 USA 1111 Email: huaimo.chen@futurewei.com 1112 Yan Zhuang (editor) 1113 Huawei 1114 101 Software Avenue, Yuhua District 1115 Nanjing, Jiangsu 210012 1116 China 1118 Email: zhuangyan.zhuang@huawei.com 1120 Qin Wu 1121 Huawei 1122 101 Software Avenue, Yuhua District 1123 Nanjing, Jiangsu 210012 1124 China 1126 Email: bill.wu@huawei.com 1128 Daniele Ceccarelli 1129 Ericsson 1130 Via A. Negrone 1/A 1131 Genova - Sestri Ponente 1132 Italy 1134 Email: daniele.ceccarelli@ericsson.com