idnits 2.17.1 draft-ietf-pce-stateful-pce-lsp-scheduling-06.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 (February 16, 2019) is 1893 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 351, but not defined == Missing Reference: 'Tb' is mentioned on line 351, but not defined == Missing Reference: 'TBD1' is mentioned on line 570, but not defined == Missing Reference: 'TBD2' is mentioned on line 661, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-11 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-09 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-04 Summary: 0 errors (**), 0 flaws (~~), 8 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 Y. Zhuang, Ed. 4 Intended status: Standards Track Q. Wu 5 Expires: August 20, 2019 D. Dhody, Ed. 6 Huawei 7 D. Ceccarelli 8 Ericsson 9 February 16, 2019 11 PCEP Extensions for LSP scheduling with stateful PCE 12 draft-ietf-pce-stateful-pce-lsp-scheduling-06 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 August 20, 2019. 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. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 8. Manageability Consideration . . . . . . . . . . . . . . . . . 18 83 8.1. Control of Function and Policy . . . . . . . . . . . . . 18 84 8.2. Information and Data Models . . . . . . . . . . . . . . . 18 85 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 18 86 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18 87 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 19 88 8.6. Impact On Network Operations . . . . . . . . . . . . . . 19 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 90 9.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 19 91 9.2. STATEFUL-PCE-CAPABILITY TLV Flag field . . . . . . . . . 19 92 9.3. Schedule TLVs Flag Field . . . . . . . . . . . . . . . . 20 93 9.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 20 94 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 97 11.2. Informative References . . . . . . . . . . . . . . . . . 22 98 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 23 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 101 1. Introduction 103 The Path Computation Element Protocol (PCEP) defined in [RFC5440] is 104 used between a Path Computation Element (PCE) and a Path Computation 105 Client (PCC) (or other PCE) to enable path computation of Multi- 106 protocol Label Switching (MPLS) Traffic Engineering Label Switched 107 Paths (TE LSPs). 109 [RFC8231] describes a set of extensions to PCEP to provide stateful 110 control. A stateful PCE has access to not only the information 111 carried by the network's Interior Gateway Protocol (IGP) but also the 112 set of active paths and their reserved resources for its 113 computations. The additional state allows the PCE to compute 114 constrained paths while considering individual LSPs and their 115 interactions. 117 Traditionally, the usage and allocation of network resources, 118 especially bandwidth, can be supported by a Network Management System 119 (NMS) operation such as path pre-establishment. However, this does 120 not provide efficient network usage since the established paths 121 exclude the possibility of being used by other services even when 122 they are not used for undertaking any service. [RFC8413] then 123 provides a framework that describes and discusses the problem, and 124 defines an appropriate architecture for the scheduled reservation of 125 TE resources. 127 The scheduled reservation of TE resources allows network operators to 128 reserve resources in advance according to the agreements with their 129 customers, and allows them to transmit data about scheduling such as 130 a specified start time and duration, for example for a scheduled bulk 131 data replication between data centers. It enables the activation of 132 bandwidth usage at the time the service really being used while 133 letting other services use it when this service is not using it. The 134 requirement of scheduled LSP provision is mentioned in [RFC8231] and 135 [RFC7399], so as to provide more efficient network resource usage for 136 traffic engineering, which hasn't been solved yet. Also, for 137 deterministic networks [I-D.ietf-detnet-architecture], the scheduled 138 LSP or temporal LSP can provide a better network resource usage for 139 guaranteed links. This idea can also be applied in segment routing 140 [RFC8402] to schedule the network resources over the whole network in 141 a centralized manner as well. 143 With this in mind, this document defines a set of extensions needed 144 to PCEP used for stateful PCEs so as to enable LSP scheduling for 145 path computation and LSP setup/deletion based on the actual network 146 resource usage duration of a traffic service. A scheduled LSP is 147 characterized by a starting time and a duration. When the end of the 148 LSP life is reached, it is deleted to free up the resources for other 149 LSPs (scheduled or not). 151 2. Conventions used in this document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 2.1. Terminology 161 The following terminologies are re-used from existing PCE documents. 163 o Active Stateful PCE [RFC8231]; 165 o Passive Stateful PCE [RFC8231]; 167 o Delegation [RFC8231]; 169 o PCE-Initiated LSP [RFC8281]; 171 o PCC [RFC5440], [RFC8231]; 173 o PCE [RFC5440], [RFC8231]; 175 o TE LSP [RFC5440], [RFC8231]; 177 o TED [RFC5440], [RFC8231]; 179 o LSP-DB [RFC8231]; 181 In addition, this document defines the following terminologies. 183 Scheduled TE LSP (or Scheduled LSP for short): an LSP with the 184 scheduling attributes, that carries traffic flow demand at a 185 starting time and lasts for a certain duration (or from a starting 186 time to an ending time, where the ending time is the starting time 187 plus the duration). A scheduled LSP is also called a temporal 188 LSP. The PCE operates path computation per LSP availability for 189 the required time and duration. 191 Scheduled LSP-DB: a database of scheduled LSPs. 193 Scheduled TED: Traffic engineering database with the awareness of 194 scheduled resources for TE. This database is generated by the PCE 195 from the information in TED and scheduled LSP-DB and allows 196 knowing, at any time, the amount of available resources (does not 197 include failures in the future). 199 Starting time (start-time): This value indicates when the scheduled 200 LSP is used and the corresponding LSP must be setup and active. 201 In other time (i.e., before the starting time or after the 202 starting time plus Duration), the LSP can be inactive to include 203 the possibility of the resources being used by other services. 205 Duration: This value indicates the time duration that the LSP is 206 undertaken by a traffic flow and the corresponding LSP must be 207 setup and active. At the end of which, the LSP is torn down and 208 removed from the data base. 210 3. Motivation and Objectives 212 A stateful PCE [RFC8231] can support better efficiency by using LSP 213 scheduling described in the use case of [RFC8051]. This requires the 214 PCE to maintain the scheduled LSPs and their associated resource 215 usage, e.g. bandwidth for Packet-switched network, as well as have 216 the ability to trigger signaling for the LSP setup/tear-down at the 217 correct time. 219 Note that existing configuration tools can be used for LSP 220 scheduling, but as highlighted in section 3.1.3 of [RFC8231] as well 221 as discussions in [RFC8413], doing this as a part of PCEP in a 222 centralized manner, has obvious advantages. 224 This document provides a set of extensions to PCEP to enable LSP 225 scheduling for LSP creation/deletion under the stateful control of a 226 PCE and according to traffic service requests from customers, so as 227 to improve the usage of network resources. 229 4. Procedures and Mechanisms 231 4.1. LSP Scheduling Overview 233 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for 234 customers' traffic services at its actual usage time, so as to 235 improve the network resource efficient utilization. 237 For stateful PCE supporting LSP scheduling, there are two types of 238 LSP databases used in this document. One is the LSP-DB defined in 239 PCEP [RFC8231], while the other is the scheduled LSP database (SLSP- 240 DB, see section 6). The SLSP-DB records scheduled LSPs and is used 241 in conjunction with the TED and LSP-DB. Note that the two types of 242 LSP databases can be implemented in one physical database or two 243 different databases. This is an implementation matter and this 244 document does not state any preference. 246 Furthermore, a scheduled TED can be generated from the scheduled LSP- 247 DB, LSP-DB and TED to indicate the network links and nodes with 248 resource availability information for now and future. The scheduled 249 TED should be maintained by all PCEs within the network environment. 251 In case of implementing PCC-initiated scheduled LSPs, before a PCC 252 delegates a scheduled LSP, it MAY use the PCReq/PCRep messages to 253 learn the path for the scheduled LSP. A PCC MUST delegate a 254 scheduled LSP with information of its scheduling parameters, 255 including the starting time and the duration using PCRpt message. 256 Since the LSP is not yet signaled, at the time of delegation the LSP 257 would be in down state. Upon receiving the delegation of the 258 scheduled LSP, a stateful PCE SHALL check the scheduled TED for the 259 network resource availability on network nodes and computes a path 260 for the LSP with the scheduling information and update to the PCC as 261 per the active stateful PCE techniques [RFC8231]. 263 Note that the active stateful PCE can update to the PCC with the path 264 for the scheduled LSP at any time. However, the PCC should not 265 signal the LSP over the path on receiving these messages since the 266 path is not active yet; PCC signals the LSP at the starting time. 268 For a multiple PCE environment, a PCE MUST synchronize to other PCEs 269 within the network, so as to keep their scheduling information 270 synchronized. There are many ways that this could be achieved: one 271 such mechanism is described in [I-D.litkowski-pce-state-sync]. Which 272 way is used to achieve this is out of scope for this document. The 273 scheduled TED can be determined from the synchronized SLSP-DB. The 274 PCE with delegation for the scheduled LSP would report the scheduled 275 LSP to other PCEs, any future update to the scheduled LSP is also 276 updated to other PCEs. This way the state of all scheduled LSPs are 277 synchronized among the PCEs. [RFC7399] discusses some 278 synchronization issues and considerations, that are also applicable 279 to the scheduled databases. 281 The scheduled LSP can also be initiated by PCE itself. In case of 282 implementing PCE-initiated scheduled LSP, the stateful PCE shall 283 check the network resource availability for the traffic and computes 284 a path for the scheduled LSP and initiate a scheduled LSP at the PCC 285 and synchronize the scheduled LSP to other PCEs. Note that, the PCC 286 could be notified immediately or at the starting time of the 287 scheduled LSP based on the local policy. In case of former SCHED- 288 LSP-ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the message 289 where as for the latter SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be 290 included. Either way the synchronization to other PCEs should be 291 done when the scheduled LSP is created. 293 In both modes, for activation of scheduled LSPs, the PCC could 294 initiate the setup of scheduled LSP at the start time by itself or 295 wait for the PCE to update the PCC to initiate the setup of LSP. 296 Similarly on the scheduling usage expires, the PCC could initiate the 297 removal by itself or wait for the PCE to request the removal of the 298 LSP. This is based on the Flag set in SCHED-LSP-ATTRIBUTE TLV. 300 4.2. Support of LSP Scheduling 302 4.2.1. LSP Scheduling 304 For a scheduled LSP, a user configures it with an arbitrary 305 scheduling duration from time Ta to time Tb, which may be represented 306 as [Ta, Tb]. 308 When an LSP is configured with arbitrary scheduling duration [Ta, 309 Tb], a path satisfying the constraints for the LSP in the scheduling 310 duration is computed and the LSP along the path is set up to carry 311 traffic from time Ta to time Tb. 313 4.2.2. Periodical LSP Scheduling 315 In addition to LSP Scheduling at an arbitrary time period, there are 316 also periodical LSP Scheduling. 318 A periodical LSP Scheduling represents Scheduling LSP every time 319 interval. It has a scheduling duration such as [Ta, Tb], a number of 320 repeats such as 10 (repeats 10 times), and a repeat cycle/time 321 interval such as a week (repeats every week). The scheduling 322 interval: "[Ta, Tb] repeats n times with repeat cycle C" represents 323 n+1 scheduling intervals as follows: 325 [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC] 327 When an LSP is configured with a scheduling interval such as "[Ta, 328 Tb] repeats 10 times with a repeat cycle a week" (representing 11 329 scheduling intervals), a path satisfying the constraints for the LSP 330 in each of the scheduling intervals represented by the periodical 331 scheduling interval is computed and the LSP along the path is set up 332 to carry traffic in each of the scheduling intervals. 334 4.2.2.1. Elastic Time LSP Scheduling 336 In addition to the basic LSP scheduling at an arbitrary time period, 337 another option is elastic time intervals, which is represented as 338 within -P and Q, where P and Q is an amount of time such as 300 339 seconds. P is called elastic range lower bound and Q is called 340 elastic range upper bound. 342 For a simple time interval such as [Ta, Tb] with an elastic range, 343 elastic time interval: "[Ta, Tb] within -P and Q" means a time period 344 from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb 345 is shifted by the same 'X'. 347 When an LSP is configured with elastic time interval "[Ta, Tb] within 348 -P and Q", a path is computed such that the path satisfies the 349 constraints for the LSP in the time period from (Ta+X) to (Tb+X) 350 and |X| is the minimum value from 0 to max(P, Q). That is, [Ta+X, 351 Tb+X] is the time interval closest to time interval [Ta, Tb] within 352 the elastic range. The LSP along the path is set up to carry traffic 353 in the time period from (Ta+X) to (Tb+X). 355 Similarly, for a recurrent time interval with an elastic range, 356 elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C 357 within -P and Q" represents n+1 simple elastic time intervals as 358 follows: 360 [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn] 361 where -P <= Xi <= Q, i = 0, 1, 2, ..., n. 363 If a user wants to keep the same repeat cycle between any two 364 adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n 365 times with repeat cycle C within -P and Q SYNC" may be used, which 366 represents n+1 simple elastic time intervals as follows: 368 [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X] 369 where -P <= X <= Q. 371 4.2.2.2. Grace Periods 373 Besides the stated time scheduling, a user may want to have some 374 grace periods for each or some of the time intervals for the LSP. 375 Two grace periods may be configured for a time interval. One is the 376 grace period before the time interval, called grace-before, which 377 extends the lifetime of the LSP for grace-before (such as 30 seconds) 378 before the time interval. The other is the one after the time 379 interval, called grace-after, which extends the lifetime of the LSP 380 for grace-after (such as 60 seconds) after the time interval. 382 When an LSP is configured with a simple time interval such as [Ta, 383 Tb] with grace periods such as grace-before GB and grace-after GA, a 384 path is computed such that the path satisfies the constraints for the 385 LSP in the time period from Ta to Tb. The LSP along the path is set 386 up to carry traffic in the time period from (Ta-GB) to (Tb+GA). 387 During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the 388 LSP is up to carry traffic (maybe in best effort). 390 4.3. Scheduled LSP creation 392 In order to realize PCC-Initiated scheduled LSPs in a centralized 393 network environment, a PCC has to separate the setup of an LSP into 394 two steps. The first step is to request/delegate and get an LSP but 395 not signal it over the network. The second step is to signal the 396 scheduled LSP over the LSRs (Label Switching Router) at its starting 397 time. 399 For PCC-Initiated scheduled LSPs, a PCC can delegate the scheduled 400 LSP by sending a path computation report (PCRpt) message by including 401 its demanded resources with the scheduling information to a stateful 402 PCE. Note the PCC MAY use the PCReq/PCRep with scheduling 403 information before delegating. 405 Upon receiving the delegation via PCRpt message, the stateful PCE 406 computes the path for the scheduled LSP per its starting time and 407 duration based on the network resource availability stored in 408 scheduled TED (see Section 4.1). 410 The stateful PCE will send a PCUpd message with the scheduled path 411 information as well as the scheduled resource information for the 412 scheduled LSP to the PCC. The PCE SHOULD add the scheduled LSP into 413 its scheduled LSP-DB and update its scheduled TED. 415 For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path 416 for the scheduled LSP per requests from network management systems 417 automatically based on the network resource availability in the 418 scheduled TED, send a PCInitiate message with the path information 419 back to the PCC. Based on the local policy, the PCInitiate message 420 could be sent immediately to ask PCC to create a scheduled LSP (as 421 per this document) or the PCInitiate message could be sent at the 422 start time to the PCC to create a normal LSP (as per [RFC8281]). 424 In both modes: 426 o The stateful PCE is required to update its local scheduled LSP-DB 427 and scheduled TED with the scheduled LSP. Besides, it shall send 428 a PCRpt message with the scheduled LSP to other PCEs within the 429 network, so as to achieve the scheduling traffic engineering 430 information synchronization. 432 o Upon receiving the PCUpd message or PCInitiate message for the 433 scheduled LSP from PCEs with a found path, the PCC knows that it 434 is a scheduled path for the LSP and does not trigger signaling for 435 the LSP setup on LSRs immediately. 437 o The stateful PCE can update the Scheduled LSP parameters on any 438 network events using the PCUpd message to PCC. These changes are 439 also synchronized to other PCEs. 441 o Based on the configuration (and the C flag in scheduled TLVs), 442 when it is time (i.e., at the start time) for the LSP to be set 443 up, either the PCC triggers the LSP to be signaled or the 444 delegated PCE sends a PCUpd message to the head end LSR providing 445 the updated path to be signaled (with A flag set to indicate LSP 446 activation). 448 4.4. Scheduled LSP Modifications 450 After a scheduled LSP is configured, a user may change its parameters 451 including the requested time as well as the bandwidth. 453 In PCC-Initiated case, the PCC can send a PCRpt message for the 454 scheduled LSP with updated parameters as well as scheduled 455 information included in the SCHED-LSP-ATTRIBUTE TLV (see 456 Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) 457 carried in the LSP Object. The PCE would take the updated resources 458 and schedule into considerations and update the new path for the 459 scheduled LSP to the PCC as well as synchronize to other PCEs in the 460 network. In case path cannot be set based on new requirements the 461 same should be conveyed by the use of empty ERO in the PCEP messages. 463 In PCE-Initiated case, the Stateful PCE would recompute the path 464 based on updated parameters as well as scheduled information. In 465 case it has already conveyed to the PCC this information by sending a 466 PCInitiate message, it should update the path and other scheduling 467 and resource information by sending a PCUpd message. 469 4.5. Scheduled LSP activation and deletion 471 In PCC-Initiated case, based on the configuration (and the C flag in 472 scheduled TLVs), when it is time (i.e., at the start time) for the 473 LSP to be set up, either the PCC triggers the LSP to be signaled or 474 the delegated PCE sends a PCUpd message to the head end LSR providing 475 the updated path to be signaled (with A flag set to indicate LSP 476 activation). The PCC would report the status of the active LSP as 477 per the procedures in [RFC8231] and at this time the LSP MUST be 478 considered as part of the LSP-DB. The A flag MUST be set in the 479 scheduled TLVs to indicate that the LSP is active now. After the 480 scheduled duration expires, based on the C flag, the PCC triggers the 481 LSP deletion on itself or the delegated PCE sends a PCUpd message to 482 the PCC to delete the LSP as per the procedures in [RFC8231]. 484 In PCE-Initiated case, based on the local policy, if the scheduled 485 LSP is already conveyed to the PCC at the time of creation, the 486 handling of LSP activation and deletion is handled in the same way as 487 PCC-Initiated case as per the setting of C flag. In other case, the 488 PCE would send the PCInitiate message at the start time to the PCC to 489 create a normal LSP without the scheduled TLVs and remove the LSP 490 after the duration expires as per [RFC8281]. 492 5. PCEP Objects and TLVs 494 5.1. Stateful PCE Capability TLV 496 After a TCP connection for a PCEP session has been established, a PCC 497 and a PCE indicates its ability to support LSP scheduling during the 498 PCEP session establishment phase. For a multiple-PCE environment, 499 the PCEs should also establish PCEP session and indicate its ability 500 to support LSP scheduling among PCEP peers. The Open Object in the 501 Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in 502 [RFC8231]. Note that the STATEFUL-PCE-CAPABILITY TLV is defined in 503 [RFC8231] and updated in [RFC8281] and [RFC8232]". In this document, 504 we define a new flag bit B (SCHED-LSP-CAPABLITY) flag for the 505 STATEFUL-PCE-CAPABILITY TLV to indicate the support of LSP scheduling 506 and another flag bit PD (PD-LSP-CAPABLITY) to indicate the support of 507 LSP periodical scheduling. 509 B (LSP-SCHEDULING-CAPABILITY - 1 bit) [Bit Position - TBD3]: If set 510 to 1 by a PCC, the B Flag indicates that the PCC allows LSP 511 scheduling; if set to 1 by a PCE, the B Flag indicates that the 512 PCE is capable of LSP scheduling. The B bit MUST be set by both 513 PCEP peers in order to support LSP scheduling for path 514 computation. 516 PD (PD-LSP-CAPABLITY - 1 bit): [Bit Position - TBD4] If set to 1 by 517 a PCC, the PD Flag indicates that the PCC allows LSP scheduling 518 periodically; if set to 1 by a PCE, the PD Flag indicates that the 519 PCE is capable of periodical LSP scheduling. The PD bit MUST be 520 set by both PCEP peers in order to support periodical LSP 521 scheduling for path computation. 523 5.2. LSP Object 525 The LSP object is defined in [RFC8231]. This document adds an 526 optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an 527 optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP scheduling. 529 The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates 530 that this LSP is requesting scheduled parameters while the SCHED-PD- 531 LSP-ATTRIBUTE TLV indicates that this scheduled LSP is periodical. 532 The scheduled LSP attribute TLV MUST be present in LSP Object for 533 each scheduled LSP carried in the PCEP messages. For periodical 534 LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in LSP Object for 535 each periodic scheduled LSP carried in the PCEP messages. 537 Only one of these TLV SHOULD be present in the LSP object. In case 538 more than one scheduling TLV is found, the first instance is 539 processed and others ignored. 541 5.2.1. SCHED-LSP-ATTRIBUTE TLV 543 The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV within 544 the LSP object for LSP scheduling for the requesting traffic service. 546 This TLV SHOULD NOT be included unless both PCEP peers have set the B 547 (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV 548 carried in the Open message. 550 The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Type (TBD1) | Length | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 |R|C|A| Flags | Reserved (0) | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Start-Time | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Duration | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | GrB | GrA | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Elastic-Lower-Bound | Elastic-Upper-Bound | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Figure 1: SCHED-LSP-ATTRIBUTE TLV 570 The type of the TLV is [TBD1] and the TLV has a fixed length of 20 571 octets. 573 The fields in the format are: 575 Flags (8 bits): Following flags are defined in this document 577 R (1 bit): Set to 1 to indicate the Start-Time is a relative 578 time, which is relative to the current time; set to 0 to 579 indicate that the 32-bit Start-Time is an absolute time, which 580 is the number of seconds since the epoch. The epoch is 1 581 January 1900 at 00:00 UTC. It wraps around every 2^32 seconds, 582 which is roughly 136 years. The next wraparound will occur in 583 the year 2036. 585 C (1 bit): Set to 1 to indicate the PCC is responsible to setup 586 and remove the scheduled LSP based on the Start-Time and 587 duration. 589 A (1 bit): Set to 1 to indicate the scheduled LSP has been 590 activated and should be considered as part of LSP-DB (instead 591 of Scheduled LSP-DB). 593 Reserved (24 bits): This field MUST be set to zero on transmission 594 and MUST be ignored on receipt. 596 Start-Time (32 bits): This value in seconds, indicates when the 597 scheduled LSP is used to carry traffic and the corresponding LSP 598 must be setup and activated. 600 Duration (32 bits): The value in seconds, indicates the duration 601 that the LSP is undertaken by a traffic flow and the corresponding 602 LSP must be up to carry traffic. At the expiry of this duration, 603 the LSP is torn down and deleted. 605 The Start-Time indicates a calendar time (e.g.,2018/12/13 8:29:58), 606 at or before which the scheduled LSP must be set up. The value of 607 the Start-Time represents the number of seconds since 00:00 hours,Jan 608 1, 1970 UTC when R bit is set to 0. When R bit is set to 1, it 609 represents the number of seconds from the current time. 611 In addition, it contains an non zero grace-before and grace-after if 612 grace periods are configured. It includes an non zero elastic range 613 lower bound and upper bound if there is an elastic range configured. 615 o GrB (Grace-Before -16 bits): The grace period time length in 616 seconds before the starting time. 618 o GrA (Grace-After -16 bits): The grace period time length in 619 seconds after time interval [starting time, starting time + 620 duration]. 622 o Elastic-Lower-Bound (16 bits): The maximum amount of time in 623 seconds that time interval can shift to lower/left. 625 o Elastic-Upper-Bound (16 bits): The maximum amount of time in 626 seconds that time interval can shift to upper/right. 628 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV 630 The periodical LSP is a special case of LSP scheduling. The traffic 631 service happens in a series of repeated time intervals. The SCHED- 632 PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the 633 LSP object for this periodical LSP scheduling. 635 This TLV SHOULD NOT be included unless both PCEP peers have set the B 636 (LSP-SCHEDULING-CAPABILITY bit) and PD (PD-LSP-CAPABLITY bit) in 637 STATEFUL-PCE-CAPABILITY TLV carried in open message. 639 The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2. 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Type (TBD2) | Length | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 |R|C|A| Flags | Opt | NR | Reserved (0) | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Start-Time | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Duration | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Repeat-time-length | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | GrB | GrA | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Elastic-Lower-Bound | Elastic-Upper-Bound | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Figure 2: SCHED-PD-LSP-ATTRIBUTE TLV 661 The type of the TLV is [TBD2] and the TLV has a fixed length of 24 662 octets. The description, format and meaning of the Flags (R, C and A 663 bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and 664 Elastic-Upper-Bound fields remains same as SCHED-LSP-ATTRIBUTE TLV. 666 The following fields are new : 668 Opt: (4 bits) Indicates options to repeat. 670 Options = 1: repeat every day; 672 Options = 2: repeat every week; 674 Options = 3: repeat every month; 676 Options = 4: repeat every year; 678 Options = 5: repeat every Repeat-time-length. 680 NR: (12 bits) The number of repeats. In each of repeats, LSP 681 carries traffic. 683 Reserved (8 bits): This field MUST be set to zero on transmission 684 and MUST be ignored on receipt. 686 Repeat-time-length: (32 bits) The time length in seconds after which 687 LSP starts to carry traffic again for the Duration. 689 6. The PCEP Messages 691 6.1. The PCRpt Message 693 Path Computation State Report (PCRpt) is a PCEP message sent by a PCC 694 to a PCE to report the status of one or more LSPs as per [RFC8231]. 695 Each LSP State Report in a PCRpt message contains the actual LSP's 696 path, bandwidth, operational and administrative status, etc. An LSP 697 Status Report carried on a PCRpt message is also used in delegation 698 or revocation of control of an LSP to/from a PCE. In case of 699 scheduled LSP, the scheduled TLVs MUST be carried in the LSP object 700 and the ERO conveys the intended path for the scheduled LSP. The 701 scheduled LSP MUST be delegated to a PCE. This message is also used 702 to synchronize the scheduled LSPs to other PCE as described in 703 [RFC8231] 705 6.2. The PCUpd Message 707 Path Computation Update Request (PCUpd) is a PCEP message sent by a 708 PCE to a PCC to update LSP parameters, on one or more LSPs as per 709 [RFC8231]. Each LSP Update Request on a PCUpd message contains all 710 LSP parameters that a PCE wishes to be set for a given LSP. In case 711 of scheduled LSP, the scheduled TLVs MUST be carried in the LSP 712 object and the ERO conveys the intended path for the scheduled LSP. 713 In case no path can be found, an empty ERO is used. The A bit is 714 used in PCUpd message to indicate the activation of the scheduled LSP 715 in case the PCE is responsible for the activation (as per the C bit). 717 6.3. The PCInitiate Message 719 An LSP Initiate Request (PCInitiate) message is a PCEP message sent 720 by a PCE to a PCC to trigger LSP instantiation or deletion as per 721 [RFC8281]. In case of scheduled LSP, based on the local policy, PCE 722 MAY convey the scheduled LSP to the PCC by including the scheduled 723 TLVs in the LSP object. Or the PCE would initiate the LSP only at 724 the start time of the scheduled LSP as per the [RFC8281] without the 725 use of scheduled TLVs. 727 6.4. The PCReq message 729 The Path Computation Request (PCReq) message is a PCEP message sent 730 by a PCC to a PCE to request a path computation [RFC5440] and it may 731 contain the LSP object [RFC8231] to identify the LSP for which the 732 path computation is requested. In case of scheduled LSP, the 733 scheduled TLVs MUST be carried in the LSP object in PCReq message to 734 request the path computation based on scheduled TED and LSP-DB. A 735 PCC MAY use PCReq message to obtain the scheduled path before 736 delegating the LSP. 738 6.5. The PCRep Message 740 The Path Computation Reply (PCRep) message is a PCEP message sent by 741 a PCE to a PCC in reply to a path computation request [RFC5440] and 742 it may contain the LSP object [RFC8231] to identify the LSP for which 743 the path is computed. A PCRep message can contain either a set of 744 computed paths if the request can be satisfied, or a negative reply 745 if not. The negative reply may indicate the reason why no path could 746 be found. In case of scheduled LSP, the scheduled TLVs MUST be 747 carried in the LSP object in PCRep message to indicate the path 748 computation based on scheduled TED and LSP-DB. A PCC and PCE MAY use 749 PCReq and PCRep message to obtain the scheduled path before 750 delegating the LSP. 752 6.6. The PCErr Message 754 The Path Computation Error (PCErr) message is a PCEP message as 755 described in [RFC5440] for error reporting. The current document 756 defines new error values for several error types to cover failures 757 specific to scheduling and reuse the applicable error types and error 758 values of [RFC5440] and [RFC8231] wherever appropriate. 760 The PCEP extensions for scheduling MUST NOT be used if one or both 761 PCEP speakers have not set the corresponding bits in the STATEFUL- 762 PCE-CAPABILITY TLV in their respective OPEN message. If the PCEP 763 speaker supports the extensions of this specification but did not 764 advertise this capability, then upon receipt of LSP object with the 765 scheduled TLV, it MUST generate a PCEP Error (PCErr) with Error- 766 type=19 (Invalid Operation) and error-value TBD6 (Attempted LSP 767 Scheduling if the scheduling capability was not advertised), and it 768 SHOULD ignore the TLV. As per Section 7.1 of [RFC5440], a legacy 769 PCEP implementation that does not understand this specification, 770 would consider the scheduled TLVs as unknown and ignore them. 772 If the PCC decides that the scheduling parameters proposed in the 773 PCUpd/PCInitiate message are unacceptable, it MUST report this error 774 by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error- 775 value="Unacceptable parameters" in the LSP object (with scheduled 776 TLVs) in the PCRpt message to the PCE. 778 The scheduled TLVs MUST be included in the LSP object for the 779 scheduled LSPs, if the TLV is missing, the receiving PCEP speaker 780 MUST send a PCErr message with Error-type=6 (Mandatory Object 781 missing) and Error-value TBD5 (Scheduled TLV missing). 783 7. Security Considerations 785 This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED-LSP- 786 ATTRIBUTE TLV, the security considerations discussed in [RFC5440], 787 [RFC8231], and [RFC8281] continue to apply. In some deployments the 788 scheduling information could provide details about the network 789 operations that could be deemed as extra sensitive. Additionally, 790 snooping of PCEP messages with such data or using PCEP messages for 791 network reconnaissance may give an attacker sensitive information 792 about the operations of the network. A single PCEP message can now 793 instruct a PCC to set up and tear down an LSP every second for a 794 number of times. That single message could have a significant effect 795 on the network. Thus, such deployment should employ suitable PCEP 796 security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] 797 or [RFC8253]. The procedure based on Transport Layer Security (TLS) 798 in [RFC8253] is considered a security enhancement and thus is much 799 better suited for the sensitive information. PCCs may also need to 800 apply some form of rate limit to the processing of scheduled LSPs. 802 8. Manageability Consideration 804 8.1. Control of Function and Policy 806 The LSP-Scheduling feature MUST BE controlled per tunnel by the 807 active stateful PCE, the values for parameters like starting time, 808 duration SHOULD BE configurable by customer applications and based on 809 the local policy at PCE. 811 8.2. Information and Data Models 813 An implementation SHOULD allow the operator to view the capability 814 defined in this document. To serve this purpose, the PCEP YANG 815 module [I-D.ietf-pce-pcep-yang] could be extended. 817 8.3. Liveness Detection and Monitoring 819 Mechanisms defined in this document do not imply any new liveness 820 detection and monitoring requirements in addition to those already 821 listed in [RFC5440]. 823 8.4. Verify Correct Operations 825 Mechanisms defined in this document do not imply any new operation 826 verification requirements in addition to those already listed in 827 [RFC5440]. 829 8.5. Requirements On Other Protocols 831 Mechanisms defined in this document do not imply any new requirements 832 on other protocols. 834 8.6. Impact On Network Operations 836 Mechanisms defined in this document do not have any impact on network 837 operations in addition to those already listed in [RFC5440]. 839 9. IANA Considerations 841 9.1. PCEP TLV Type Indicators 843 This document defines the following new PCEP TLV. IANA maintains a 844 sub-registry "PCEP TLV Type Indicators" in the "Path Computation 845 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 846 the following allocations from this sub-registry. 848 Value Meaning Reference 849 TBD1 SCHED-LSP-ATTRIBUTE This document 850 TBD2 SCHED-PD-LSP-ATTRIBUTE This document 852 IANA is requested to create and maintain a new registry "Opt" under 853 SCHED-PD-LSP-ATTRIBUTE (TLV Type: TBD2). Initial values for the 854 registry are given below. 856 Value Name Definition 857 ----- ---- ---------- 858 0 Reserved 859 1 REPEAT-EVERY-DAY Section 5.2.2 860 2 REPEAT-EVERY-WEEK Section 5.2.2 861 3 REPEAT-EVERY-MONTH Section 5.2.2 862 4 REPEAT-EVERY-YEAR Section 5.2.2 863 5 REPEAT-EVERY-REPEAT-TIME-LENGTH Section 5.2.2 864 6-14 Unassigned 865 15 Reserved 867 9.2. STATEFUL-PCE-CAPABILITY TLV Flag field 869 This document defines new bits in the Flags field in the STATEFUL- 870 PCE-CAPABILITY TLV in the OPEN object. IANA maintains a sub-registry 871 "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "Path Computation 872 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 873 the following allocations from this sub-registry. 875 The following values are defined in this document: 877 Bit Description Reference 878 TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document 879 TBD4 PD-LSP-CAPABLITY (PD-bit) This document 881 9.3. Schedule TLVs Flag Field 883 IANA is requested to create a new sub-registry, named "Schedule TLVs 884 Flag Field", within the "Path Computation Element Protocol (PCEP) 885 Numbers" registry to manage the Flag field in the SCHED-LSP-ATTRIBUTE 886 and SCHED-PD-LSP-ATTRIBUTE TLVs. New values are assigned by 887 Standards Action [RFC8126]. Each bit should be tracked with the 888 following qualities: 890 o Bit number (counting from bit 0 as the most significant bit) 892 o Capability description 894 o Defining RFC 896 The following values are defined in this document: 898 Bit Description Reference 899 0 R-bit This document 900 1 C-bit This document 901 2 A-bit This document 903 9.4. PCEP-Error Object 905 IANA is requested to allocate the following new error types to the 906 existing error values within the "PCEP-ERROR Object Error Types and 907 Values" subregistry of the "Path Computation Element Protocol (PCEP) 908 Numbers" registry: 910 Error-Type Meaning 911 6 Mandatory Object missing 913 Error-value 914 TBD5: Scheduled TLV missing 916 19 Invalid Operation 918 Error-value 919 TBD6: Attempted LSP Scheduling if the scheduling 920 capability was not advertised 922 10. Acknowledgments 924 The authors of this document would also like to thank Rafal Szarecki, 925 Adrian Farrel, Cyril Margaria for the review and comments. 927 11. References 929 11.1. Normative References 931 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 932 Requirement Levels", BCP 14, RFC 2119, 933 DOI 10.17487/RFC2119, March 1997, 934 . 936 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 937 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 938 DOI 10.17487/RFC5440, March 2009, 939 . 941 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 942 Writing an IANA Considerations Section in RFCs", BCP 26, 943 RFC 8126, DOI 10.17487/RFC8126, June 2017, 944 . 946 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 947 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 948 May 2017, . 950 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 951 Computation Element Communication Protocol (PCEP) 952 Extensions for Stateful PCE", RFC 8231, 953 DOI 10.17487/RFC8231, September 2017, 954 . 956 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 957 and D. Dhody, "Optimizations of Label Switched Path State 958 Synchronization Procedures for a Stateful PCE", RFC 8232, 959 DOI 10.17487/RFC8232, September 2017, 960 . 962 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 963 Computation Element Communication Protocol (PCEP) 964 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 965 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 966 . 968 11.2. Informative References 970 [I-D.ietf-detnet-architecture] 971 Finn, N., Thubert, P., Varga, B., and J. Farkas, 972 "Deterministic Networking Architecture", draft-ietf- 973 detnet-architecture-11 (work in progress), February 2019. 975 [I-D.ietf-pce-pcep-yang] 976 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 977 YANG Data Model for Path Computation Element 978 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 979 yang-09 (work in progress), October 2018. 981 [I-D.litkowski-pce-state-sync] 982 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 983 Stateful Path Computation Element communication 984 procedures", draft-litkowski-pce-state-sync-04 (work in 985 progress), October 2018. 987 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 988 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 989 June 2010, . 991 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 992 Computation Element Architecture", RFC 7399, 993 DOI 10.17487/RFC7399, October 2014, 994 . 996 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 997 Stateful Path Computation Element (PCE)", RFC 8051, 998 DOI 10.17487/RFC8051, January 2017, 999 . 1001 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1002 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1003 Path Computation Element Communication Protocol (PCEP)", 1004 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1005 . 1007 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1008 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1009 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1010 July 2018, . 1012 [RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework 1013 for Scheduled Use of Resources", RFC 8413, 1014 DOI 10.17487/RFC8413, July 2018, 1015 . 1017 Appendix A. Contributor Addresses 1019 Xufeng Liu 1020 Ericsson 1021 USA 1022 Email: xliu@kuatrotech.com 1024 Mehmet Toy 1025 Verizon 1026 USA 1027 Email: mehmet.toy@verizon.com 1029 Vic Liu 1030 China Mobile 1031 No.32 Xuanwumen West Street, Xicheng District 1032 Beijing, 100053 1033 China 1034 Email: liu.cmri@gmail.com 1036 Lei Liu 1037 Fujitsu 1038 USA 1039 Email: lliu@us.fujitsu.com 1041 Khuzema Pithewan 1042 Infinera 1043 Email: kpithewan@infinera.com 1045 Zitao Wang 1046 Huawei 1047 101 Software Avenue, Yuhua District 1048 Nanjing, Jiangsu 210012 1049 China 1051 Email: wangzitao@huawei.com 1053 Xian Zhang 1054 Huawei Technologies 1055 Research Area F3-1B, 1056 Huawei Industrial Base, 1057 Shenzhen, 518129, China 1059 Email: zhang.xian@huawei.com 1061 Authors' Addresses 1063 Huaimo Chen (editor) 1064 Huawei 1065 Boston, MA 1066 USA 1068 Email: huaimo.chen@huawei.com 1070 Yan Zhuang (editor) 1071 Huawei 1072 101 Software Avenue, Yuhua District 1073 Nanjing, Jiangsu 210012 1074 China 1076 Email: zhuangyan.zhuang@huawei.com 1078 Qin Wu 1079 Huawei 1080 101 Software Avenue, Yuhua District 1081 Nanjing, Jiangsu 210012 1082 China 1084 Email: bill.wu@huawei.com 1086 Dhruv Dhody (editor) 1087 Huawei 1088 Divyashree Techno Park, Whitefield 1089 Bangalore, Karnataka 560066 1090 India 1092 Email: dhruv.ietf@gmail.com 1094 Daniele Ceccarelli 1095 Ericsson 1096 Via A. Negrone 1/A 1097 Genova - Sestri Ponente 1098 Italy 1100 Email: daniele.ceccarelli@ericsson.com