idnits 2.17.1 draft-ietf-pce-stateful-pce-lsp-scheduling-05.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 (December 22, 2018) is 1951 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 349, but not defined == Missing Reference: 'Tb' is mentioned on line 349, but not defined == Missing Reference: 'TBD1' is mentioned on line 580, but not defined == Missing Reference: 'TBD2' is mentioned on line 671, but not defined == 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 (~~), 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 Y. Zhuang, Ed. 4 Intended status: Standards Track Q. Wu 5 Expires: June 25, 2019 D. Dhody, Ed. 6 Huawei 7 D. Ceccarelli 8 Ericsson 9 December 22, 2018 11 PCEP Extensions for LSP scheduling with stateful PCE 12 draft-ietf-pce-stateful-pce-lsp-scheduling-05 14 Abstract 16 This document proposes a set of extensions needed to the stateful 17 Path Computation Element (PCE) communication Protocol (PCEP), so as 18 to enable Labeled Switched Path (LSP) scheduling for path computation 19 and LSP setup/deletion based on the actual network resource usage 20 duration of a traffic service in a centralized network environment as 21 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 June 25, 2019. 40 Copyright Notice 42 Copyright (c) 2018 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. Architecture Overview . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . 19 93 9.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 20 94 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 97 11.2. Informative References . . . . . . . . . . . . . . . . . 21 98 Appendix A. Scheduled LSP information synchronization . . . . . 22 99 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 Path (TE LSP). 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 proposes an appropriate architecture for the scheduled reservation of 126 TE resources. 128 With the scheduled reservation of TE resources, it allows network 129 operators to reserve resources in advance according to the agreements 130 with their customers, and allow them to transmit data with scheduling 131 such as specified starting time and duration, for example for a 132 scheduled bulk data replication between data centers. It enables the 133 activation of bandwidth usage at the time the service really being 134 used while letting other services obtain it in spare time. 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, the scheduled LSP can provide a better 139 network resource usage for guaranteed links. This idea can also be 140 applied in segment routing to schedule the network resources over the 141 whole network in a centralized manner as well. 143 With this in mind, this document proposes a set of extensions needed 144 to the stateful PCE, so as to enable LSP scheduling for path 145 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 LSP (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): a LSP with the 184 scheduling attributes,that carries traffic flow demand at a 185 starting time and last 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 teardown and 208 removed from the data base. 210 3. Motivation and Objectives 212 A stateful PCE can support better efficiency by using LSP scheduling 213 described in the use case of [RFC8231]. This requires the PCE to 214 maintain the scheduled LSPs and their associated resource usage, e.g. 215 bandwidth for Packet-switched network, as well as have the ability to 216 trigger signaling for the LSP setup/tear-down at the correct time. 218 Note that existing configuration tools can be used for LSP 219 scheduling, but as highlighted in section 3.1.3 of [RFC8231] as well 220 as discussions in [RFC8413], doing this as a part of PCEP in a 221 centralized manner, has obvious advantages. 223 The objective of this document is to provide a set of extensions to 224 PCEP to enable LSP scheduling for LSPs creation/deletion under the 225 stateful PCE control, according to traffic services from customers, 226 so as to improve the usage of network resources. 228 4. Architecture Overview 230 4.1. LSP Scheduling Overview 232 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for 233 customers' traffic services at its actual usage time, so as to 234 improve the network resource efficient utilization. 236 For stateful PCE supporting LSP scheduling, there are two types of 237 LSP databases used in this document. One is the LSP-DB defined in 238 PCEP [RFC8231], while the other is the scheduled LSP database (SLSP- 239 DB, see section 6). The SLSP-DB records scheduled LSPs and is used 240 in conjunction with the TED and LSP-DB. Note that the two types of 241 LSP databases can be implemented in one physical database or two 242 different databases. This is an implementation matter and this 243 document does not state any preference. 245 Furthermore, a scheduled TED can be generated from the scheduled LSP- 246 DB, LSP-DB and TED to indicate the network links and nodes with 247 resource availability information for now and future. The scheduled 248 TED should be maintained by all PCEs within the network environment. 250 In case of implementing PCC-initiated scheduled LSPs, before a PCC 251 delegates a scheduled LSP, it MAY use the PCReq/PCRep messages to 252 learn the path for the scheduled LSP. A PCC MUST delegate a 253 scheduled LSP with information of its scheduling parameters, 254 including the starting time and the duration using PCRpt message. 255 Since the LSP is not yet signaled, at the time of delegation the LSP 256 would be in down state. Upon receiving the delegation of the 257 scheduled LSP, a stateful PCE SHALL check the scheduled TED for the 258 network resource availability on network nodes and computes a path 259 for the LSP with the scheduling information and update to the PCC as 260 per the active stateful PCE techniques [RFC8231]. 262 Note that the active stateful PCE can update to the PCC with the path 263 for the scheduled LSP at any time. However, the PCC should not 264 signal the LSP over the path on receiving these messages since the 265 path is not active yet; PCC signals the LSP at the starting time. 267 For a multiple PCE environment, in order to synchronize the scheduled 268 LSP-DB, the mechanism as described in [I-D.litkowski-pce-state-sync] 269 can be used to synchronize between PCEs. The scheduled TED can be 270 determined from the synchronized SLSP-DB. The PCE with delegation 271 for the scheduled LSP would report the scheduled LSP to other PCEs, 272 any future update to the scheduled LSP is also updated to other PCEs. 273 This way the state of all scheduled LSPs are synchronized among the 274 PCEs. [RFC7399] discusses some synchronization issues and 275 considerations, that are also applicable to the scheduled databases. 277 The scheduled LSP can also be initiated by PCE itself. In case of 278 implementing PCE-initiated scheduled LSP, the stateful PCE shall 279 check the network resource availability for the traffic and computes 280 a path for the scheduled LSP and initiate a scheduled LSP at the PCC 281 and synchronize the scheduled LSP to other PCEs. Note that, the PCC 282 could be notified immediately or at the starting time of the 283 scheduled LSP based on the local policy. In case of former SCHED- 284 LSP-ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the message 285 where as for the latter SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be 286 included. Either way the synchronization to other PCEs should be 287 done when the scheduled LSP is created. 289 In both modes, for activation of scheduled LSPs, the PCC could 290 initiate the setup of scheduled LSP at the start time by itself or 291 wait for the PCE to update the PCC to initiate the setup of LSP. 292 Similarly on the scheduling usage expires, the PCC could initiate the 293 removal by itself or wait for the PCE to request the removal of the 294 LSP. This is based on the Flag set in SCHED-LSP-ATTRIBUTE TLV. The 295 state of the scheduled LSP is synchronized to other PCEs using the 296 existing mechanism in [RFC8231] and [I-D.litkowski-pce-state-sync]. 298 4.2. Support of LSP Scheduling 300 4.2.1. LSP Scheduling 302 For a scheduled LSP, a user configures it with an arbitrary 303 scheduling duration time from Ta to time Tb, which may be represented 304 as [Ta, Tb]. 306 When an LSP is configured with arbitrary scheduling duration [Ta, 307 Tb], a path satisfying the constraints for the LSP in the scheduling 308 duration is computed and the LSP along the path is set up to carry 309 traffic from time Ta to time Tb. 311 4.2.2. Periodical LSP Scheduling 313 In addition to LSP Scheduling at an arbitrary time period, there are 314 also periodical LSP Scheduling. 316 A periodical LSP Scheduling represents Scheduling LSP every time 317 interval. It has a scheduling duration such as [Ta, Tb], a number of 318 repeats such as 10 (repeats 10 times), and a repeat cycle/time 319 interval such as a week (repeats every week). The scheduling 320 interval: "[Ta, Tb] repeats n times with repeat cycle C" represents 321 n+1 scheduling intervals as follows: 323 [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC] 325 When an LSP is configured with a scheduling interval such as "[Ta, 326 Tb] repeats 10 times with a repeat cycle a week" (representing 11 327 scheduling intervals), a path satisfying the constraints for the LSP 328 in each of the scheduling intervals represented by the periodical 329 scheduling interval is computed and the LSP along the path is set up 330 to carry traffic in each of the scheduling intervals. 332 4.2.2.1. Elastic Time LSP Scheduling 334 In addition to the basic LSP scheduling at an arbitrary time period, 335 another option is elastic time intervals, which is represented as 336 within -P and Q, where P and Q is an amount of time such as 300 337 seconds. P is called elastic range lower bound and Q is called 338 elastic range upper bound. 340 For a simple time interval such as [Ta, Tb] with an elastic range, 341 elastic time interval: "[Ta, Tb] within -P and Q" means a time period 342 from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb 343 is shifted by the same 'X'. 345 When an LSP is configured with elastic time interval "[Ta, Tb] within 346 -P and Q", a path is computed such that the path satisfies the 347 constraints for the LSP in the time period from (Ta+X) to (Tb+X) 348 and |X| is the minimum value from 0 to max(P, Q). That is, [Ta+X, 349 Tb+X] is the time interval closest to time interval [Ta, Tb] within 350 the elastic range. The LSP along the path is set up to carry traffic 351 in the time period from (Ta+X) to (Tb+X). 353 Similarly, for a recurrent time interval with an elastic range, 354 elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C 355 within -P and Q" represents n+1 simple elastic time intervals as 356 follows: 358 [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn] 359 where -P <= Xi <= Q, i = 0, 1, 2, ..., n. 361 If a user wants to keep the same repeat cycle between any two 362 adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n 363 times with repeat cycle C within -P and Q SYNC" may be used, which 364 represents n+1 simple elastic time intervals as follows: 366 [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X] 367 where -P <= X <= Q. 369 4.2.2.2. Graceful Periods 371 Besides the stated time scheduling, a user may want to have some 372 graceful periods for each or some of the time intervals for the LSP. 373 Two graceful periods may be configured for a time interval. One is 374 the graceful period before the time interval, called grace-before, 375 which extends the lifetime of the LSP for grace-before (such as 30 376 seconds) before the time interval. The other is the one after the 377 time interval, called grace-after, which extends the lifetime of the 378 LSP for grace-after (such as 60 seconds) after the time interval. 380 When an LSP is configured with a simple time interval such as [Ta, 381 Tb] with graceful periods such as grace-before GB and grace-after GA, 382 a path is computed such that the path satisfies the constraints for 383 the LSP in the time period from Ta to Tb. The LSP along the path is 384 set up to carry traffic in the time period from (Ta-GB) to (Tb+GA). 386 During graceful periods from (Ta-GB) to Ta and from Tb to (Tb+GA), 387 the LSP is up to carry traffic (maybe in best effort). 389 4.3. Scheduled LSP creation 391 In order to realize PCC-Initiated scheduled LSP in a centralized 392 network environment, a PCC has to separate the setup of a LSP into 393 two steps. The first step is to request/delegate and get a LSP but 394 not signal it over the network. The second step is to signal the 395 scheduled LSP over the LSRs (Labeled switched Router) at its starting 396 time. 398 For PCC-Initiated scheduled LSPs, a PCC can delegate the scheduled 399 LSP by sending a path computation report (PCRpt) message by including 400 its demanded resources with the scheduling information to a stateful 401 PCE. Note the PCC MAY use the PCReq/PCRep with scheduling 402 information before delegating. 404 Upon receiving the delegation via PCRpt message, the stateful PCE 405 computes the path for the scheduled LSP per its starting time and 406 duration based on the network resource availability stored in 407 scheduled TED (see Section 4.1). 409 The stateful PCE will send a PCUpd message with the scheduled path 410 information as well as the scheduled resource information for the 411 scheduled LSP to the PCC. The PCE SHOULD add the scheduled LSP into 412 its scheduled LSP-DB and update its scheduled TED. The PCE MUST also 413 synchronize to other PCEs within the network if there is any, so as 414 to keep their scheduling information synchronized as per 415 [I-D.litkowski-pce-state-sync]. 417 For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path 418 for the scheduled LSP per requests from network management systems 419 automatically based on the network resource availability in the 420 scheduled TED, send a PCInitiate message with the path information 421 back to the PCC. Based on the local policy, the PCInitiate message 422 could be sent immediately to ask PCC to create a scheduled LSP (as 423 per this document) or the PCInitiate message could be sent at the 424 start time to the PCC to create a normal LSP (as per [RFC8281]). 426 In both modes: 428 o The stateful PCE is required to update its local scheduled LSP DB 429 and scheduled TED with the scheduled LSP. Besides, it shall send 430 a PCRpt message with the scheduled LSP to other PCEs within the 431 network, so as to achieve the scheduling traffic engineering 432 information synchronization as per [I-D.litkowski-pce-state-sync]. 434 o Upon receiving the PCUpd message or PCInitiate message for the 435 scheduled LSP from PCEs with a found path, the PCC knows that it 436 is a scheduled path for the LSP and does not trigger signaling for 437 the LSP setup on LSRs immediately. 439 o The stateful PCE can update the Scheduled LSP parameters on any 440 network events using the PCUpd message to PCC. These changes are 441 also synchronized to other PCEs as per 442 [I-D.litkowski-pce-state-sync]. 444 o Based on the configuration (and the C flag in scheduled TLVs), 445 when it is time (i.e., at the start time) for the LSP to be set 446 up, either the PCC triggers the LSP to be signaled or the 447 delegated PCE sends a PCUpd message to the head end LSR providing 448 the updated path to be signaled (with A flag set to indicate LSP 449 activation). 451 4.4. Scheduled LSP Modifications 453 After a scheduled LSP is configured, a user may change its parameters 454 including the requested time as well as the bandwidth. 456 In PCC-Initiated case, the PCC can send a PCRpt message for the 457 scheduled LSP with updated parameters as well as scheduled 458 information included in the SCHED-LSP-ATTRIBUTE TLV (see 459 Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) 460 carried in the LSP Object. The PCE would take the updated resources 461 and schedule into considerations and update the new path for the 462 scheduled LSP to the PCC as well as synchronize to other PCEs in the 463 network. In case path cannot be set based on new requirements the 464 same should be conveyed by the use of empty ERO in the PCEP messages. 466 In PCE-Initiated case, the Stateful PCE would recompute the path 467 based on updated parameters as well as scheduled information. In 468 case it has already conveyed to the PCC this information by sending a 469 PCInitiate message, it should update the path and other scheduling 470 and resource information by sending a PCUpd message. 472 In any case, the scheduled databases SHALL be updated and the PCE 473 MUST synchronize this information to other PCEs as per 474 [I-D.litkowski-pce-state-sync]. 476 4.5. Scheduled LSP activation and deletion 478 In PCC-Initiated case, based on the configuration (and the C flag in 479 scheduled TLVs), when it is time (i.e., at the start time) for the 480 LSP to be set up, either the PCC triggers the LSP to be signaled or 481 the delegated PCE sends a PCUpd message to the head end LSR providing 482 the updated path to be signaled (with A flag set to indicate LSP 483 activation). The PCC would report the status of the active LSP as 484 per the procedures in [RFC8231] and at this time the LSP MUST be 485 considered as part of the LSP-DB. The A flag MUST be set in the 486 scheduled TLVs to indicate that the LSP is active now. After the 487 scheduled duration expires, based on the C flag, the PCC triggers the 488 LSP deletion on it self or the delegated PCE sends a PCUpd message to 489 the PCC to delete the LSP as per the procedures in [RFC8231]. 491 In PCE-Initiated case, based on the local policy, if the scheduled 492 LSP is already conveyed to the PCC at the time of creation, the 493 handling of LSP activation and deletion is handled in the same way as 494 PCC-Initiated case as per the setting of C flag. In other case, the 495 PCE would send the PCInitiate message at the start time to the PCC to 496 create a normal LSP without the scheduled TLVs and remove the LSP 497 after the duration expires as per [RFC8281]. 499 Additionally, the scheduled databases SHALL be updated and 500 synchronization to other PCEs MUST be done as per 501 [I-D.litkowski-pce-state-sync]. 503 5. PCEP Objects and TLVs 505 5.1. Stateful PCE Capability TLV 507 After a TCP connection for a PCEP session has been established, a PCC 508 and a PCE indicates its ability to support LSP scheduling during the 509 PCEP session establishment phase. For a multiple-PCE environment, 510 the PCEs should also establish PCEP session and indicate its ability 511 to support LSP scheduling among PCEP peers. The Open Object in the 512 Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in 513 [RFC8231]. Note that the STATEFUL- PCE-CAPABILITY TLV is defined in 514 [RFC8231] and updated in [RFC8281] and [RFC8232]". In this document, 515 we define a new flag bit B (SCHED-LSP-CAPABLITY) flag for the 516 STATEFUL- PCE-CAPABILITY TLV to indicate the support of LSP 517 scheduling and another flag bit PD (PD-LSP-CAPABLITY) to indicate the 518 support of LSP periodical scheduling. 520 B (LSP-SCHEDULING-CAPABILITY - 1 bit) [Bit Position - TBD3]: If set 521 to 1 by a PCC, the B Flag indicates that the PCC allows LSP 522 scheduling; if set to 1 by a PCE, the B Flag indicates that the 523 PCE is capable of LSP scheduling. The B bit MUST be set by both 524 PCEP peers in order to support LSP scheduling for path 525 computation. 527 PD (PD-LSP-CAPABLITY - 1 bit): [Bit Position - TBD4] If set to 1 by 528 a PCC, the PD Flag indicates that the PCC allows LSP scheduling 529 periodically; if set to 1 by a PCE, the PD Flag indicates that the 530 PCE is capable of periodical LSP scheduling. The PD bit MUST be 531 set by both PCEP peers in order to support periodical LSP 532 scheduling for path computation. 534 5.2. LSP Object 536 The LSP object is defined in [RFC8231]. This document add an 537 optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an 538 optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP scheduling. 540 The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates 541 that this LSP is requesting scheduled parameters while the SCHED-PD- 542 LSP-ATTRIBUTE TLV indicates that this scheduled LSP is periodical. 543 The scheduled LSP attribute TLV MUST be present in LSP Object for 544 each scheduled LSP carried in the PCEP messages. For periodical 545 LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in LSP Object for 546 each periodic scheduled LSP carried in the PCEP messages. 548 Only one of these TLV SHOULD be present in the LSP object. In case 549 more than one scheduling TLV is found, the first instance is 550 processed and others ignored. 552 5.2.1. SCHED-LSP-ATTRIBUTE TLV 554 The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV within 555 the LSP object for LSP scheduling for the requesting traffic service. 557 This TLV SHOULD be included only if both PCEP peers have set the B 558 (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV 559 carried in open message. 561 The format of the SCHED-LSP-ATTRIBUTE TLV is shown in the following 562 figure: 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Type (TBD1) | Length | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 |R|C|A| Flags | Reserved (0) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Start-Time | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Duration | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | GrB | GrA | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Elastic-Lower-Bound | Elastic-Upper-Bound | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 The type of the TLV is [TBD1] and the TLV has a fixed length of 20 581 octets. 583 The fields in the format are: 585 Flags (8 bits): Following flags are defined in this document 587 R (1 bit): Set to 1 to indicate the Start-Time is a relative 588 time, which is relative to the current time; set to 0 to 589 indicate that the 32-bit Start-Time is an absolute time, which 590 is the number of seconds since the epoch. The epoch is 1 591 January 1900 at 00:00 UTC. It wraps around every 2^32 seconds, 592 which is roughly 136 years. The next wraparound will occur in 593 the year 2036. 595 C (1 bit): Set to 1 to indicate the PCC is responsible to setup 596 and remove the scheduled LSP based on the Start-Time and 597 duration. 599 A (1 bit): Set to 1 to indicate the scheduled LSP has been 600 activated and should be considered as part of LSP-DB (instead 601 of Scheduled LSP-DB). 603 Reserved (24 bits): This field MUST be set to zero on transmission 604 and MUST be ignored on receipt. 606 Start-Time (32 bits): This value in seconds, indicates when the 607 scheduled LSP is used to carry traffic and the corresponding LSP 608 must be setup and activated. 610 Duration (32 bits): The value in seconds, indicates the duration 611 that the LSP is undertaken by a traffic flow and the corresponding 612 LSP must be up to carry traffic. At the expiry of this duration, 613 the LSP is tear down and deleted. 615 The Start-Time indicates a calendar time (e.g.,2018/12/13 8:29:58), 616 at or before which the scheduled LSP must be set up. The value of 617 the Start-Time represents the number of seconds since 00:00 hours,Jan 618 1, 1970 UTC when R bit is set to 0. When R bit is set to 1, it 619 represents the number of seconds from the current time. 621 In addition, it contains an non zero grace-before and grace-after if 622 graceful periods are configured. It includes an non zero elastic 623 range lower bound and upper bound if there is an elastic range 624 configured. 626 o GrB (Grace-Before -16 bits): The graceful period time length in 627 seconds before the starting time. 629 o GrA (Grace-After -16 bits): The graceful period time length in 630 seconds after time interval [starting time, starting time + 631 duration]. 633 o Elastic-Lower-Bound (16 bits): The maximum amount of time in 634 seconds that time interval can shift to lower/left. 636 o Elastic-Upper-Bound (16 bits): The maximum amount of time in 637 seconds that time interval can shift to upper/right. 639 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV 641 The periodical LSP is a special case of LSP scheduling. The traffic 642 service happens in a series of repeated time intervals. The SCHED- 643 PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the 644 LSP object for this periodical LSP scheduling. 646 This TLV SHOULD be included only if both PCEP peers have set the B 647 (LSP-SCHEDULING-CAPABILITY bit) and PD (PD-LSP-CAPABLITY bit) in 648 STATEFUL-PCE-CAPABILITY TLV carried in open message. 650 The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in the 651 following figure: 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Type (TBD2) | Length | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 |R|C|A| Flags | Opt | NR | Reserved (0) | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Start-Time | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Duration | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Repeat-time-length | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | GrB | GrA | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Elastic-Lower-Bound | Elastic-Upper-Bound | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 The type of the TLV is [TBD2] and the TLV has a fixed length of 24 672 octets. The description, format and meaning of the Flags (R, C and A 673 bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and 674 Elastic-Upper-Bound fields remains same as SCHED-LSP-ATTRIBUTE TLV. 676 The following fields are new : 678 Opt: (4 bits) Indicates options to repeat. 680 Options = 1: repeat every day; 682 Options = 2: repeat every week; 684 Options = 3: repeat every month; 686 Options = 4: repeat every year; 688 Options = 5: repeat every Repeat-time-length. 690 NR:(12 bits) The number of repeats. In each of repeats, LSP carries 691 traffic. If value is set to 0xFFF, it indicates forever. 693 Reserved (8 bits): This field MUST be set to zero on transmission 694 and MUST be ignored on receipt. 696 Repeat-time-length:(32 bits) The time length in seconds after which 697 LSP starts to carry traffic again for the Duration. 699 6. The PCEP Messages 701 6.1. The PCRpt Message 703 Path Computation State Report (PCRpt) is a PCEP message sent by a PCC 704 to a PCE to report the status of one or more LSPs as per [RFC8231]. 705 Each LSP State Report in a PCRpt message contains the actual LSP's 706 path, bandwidth, operational and administrative status, etc. An LSP 707 Status Report carried on a PCRpt message is also used in delegation 708 or revocation of control of an LSP to/from a PCE. In case of 709 scheduled LSP, the scheduled TLVs MUST be carried in the LSP object 710 and the ERO conveys the intended path for the scheduled LSP. The 711 scheduled LSP MUST be delegated to a PCE. This message is also used 712 to synchronize the scheduled LSPs to other PCE as described in 713 [RFC8231] and [I-D.litkowski-pce-state-sync]. 715 6.2. The PCUpd Message 717 Path Computation Update Request (PCUpd) is a PCEP message sent by a 718 PCE to a PCC to update LSP parameters, on one or more LSPs as per 719 [RFC8231]. Each LSP Update Request on a PCUpd message contains all 720 LSP parameters that a PCE wishes to be set for a given LSP. In case 721 of scheduled LSP, the scheduled TLVs MUST be carried in the LSP 722 object and the ERO conveys the intended path for the scheduled LSP. 723 In case no path can be found, an empty ERO is used. The A bit is 724 used in PCUpd message to indicate the activation of the scheduled LSP 725 in case the PCE is responsible for the activation (as per the C bit). 726 This message is also used to synchronize the scheduled LSPs to other 727 PCE as described in [I-D.litkowski-pce-state-sync]. 729 6.3. The PCInitiate Message 731 An LSP Initiate Request (PCInitiate) message is a PCEP message sent 732 by a PCE to a PCC to trigger LSP instantiation or deletion as per 733 [RFC8281]. In case of scheduled LSP, based on the local policy, PCE 734 MAY convey the scheduled LSP to the PCC by including the scheduled 735 TLVs in the LSP object. Or the PCE would initiate the LSP only at 736 the start time of the scheduled LSP as per the [RFC8281] without the 737 use of scheduled TLVs. 739 6.4. The PCReq message 741 The Path Computation Request (PCReq) message is a PCEP message sent 742 by a PCC to a PCE to request a path computation [RFC5440] and it may 743 contain the LSP object [RFC8231] to identify the LSP for which the 744 path computation is requested. In case of scheduled LSP, the 745 scheduled TLVs MUST be carried in the LSP object in PCReq message to 746 request the path computation based on scheduled TED and LSP-DB. A 747 PCC MAY use PCReq message to obtain the scheduled path before 748 delegating the LSP. 750 6.5. The PCRep Message 752 The Path Computation Reply (PCRep) message is a PCEP message sent by 753 a PCE to a PCC in reply to a path computation request [RFC5440] and 754 it may contain the LSP object [RFC8231] to identify the LSP for which 755 the path is computed. A PCRep message can contain either a set of 756 computed paths if the request can be satisfied, or a negative reply 757 if not. The negative reply may indicate the reason why no path could 758 be found. In case of scheduled LSP, the scheduled TLVs MUST be 759 carried in the LSP object in PCRep message to indicate the path 760 computation based on scheduled TED and LSP-DB. A PCC and PCE MAY use 761 PCReq and PCRep message to obtain the scheduled path before 762 delegating the LSP. 764 6.6. The PCErr Message 766 The Path Computation Error (PCErr) message is a PCEP message as 767 described in [RFC5440] for error reporting. The current document 768 defines new error values for several error types to cover failures 769 specific to scheduling and reuse the applicable error types and error 770 values of [RFC5440] and [RFC8231] wherever appropriate. 772 The PCEP extensions for scheduling MUST NOT be used if one or both 773 PCEP speakers have not set the corresponding bits in the STATEFUL- 774 PCE-CAPABILITY TLV in their respective OPEN message. If the PCEP 775 speaker supports the extensions of this specification but did not 776 advertise this capability, then upon receipt of LSP object with the 777 scheduled TLV, it MUST generate a PCEP Error (PCErr) with Error- 778 type=19 (Invalid Operation) and error-value TBD6 (Attempted LSP 779 Scheduling if the scheduling capability was not advertised), and it 780 SHOULD terminate the PCEP session. As per Section 7.1 of [RFC5440], 781 a legacy PCEP implementation that does not understand this 782 specification, would consider the scheduled TLVs as unknown and 783 ignore them. 785 If the PCC decides that the scheduling parameters proposed in the 786 PCUpd/PCInitiate message are unacceptable, it MUST report this error 787 by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error- 788 value="Unacceptable parameters" in the LSP object (with scheduled 789 TLVs) in the PCRpt message to the PCE. 791 The scheduled TLVs MUST be included in the LSP object for the 792 scheduled LSPs, if the TLV is missing, the receiving PCEP speaker 793 MUST send a PCErr message with Error-type=6 (Mandatory Object 794 missing) and Error-value TBD5 (Scheduled TLV missing). 796 7. Security Considerations 798 This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED- LSP- 799 ATTRIBUTE TLV, the security considerations discussed in [RFC5440], 800 [RFC8231], and [RFC8281] continue to apply. In some deployments the 801 scheduling information could provide details about the network 802 operations that could be deemed as extra sensitive. Additionally, 803 snooping of PCEP messages with such data or using PCEP messages for 804 network reconnaissance may give an attacker sensitive information 805 about the operations of the network. Thus, such deployment should 806 employ suitable PCEP security mechanisms like TCP Authentication 807 Option (TCP-AO) [RFC5925] or [RFC8253]. The procedure based on 808 Transport Layer Security (TLS) in [RFC8253] is considered a security 809 enhancement and thus is much better suited for the sensitive 810 information. 812 8. Manageability Consideration 814 8.1. Control of Function and Policy 816 The LSP-Scheduling feature MUST BE controlled per tunnel by the 817 active stateful PCE, the values for parameters like starting time, 818 duration SHOULD BE configurable by customer applications and based on 819 the local policy at PCE. 821 8.2. Information and Data Models 823 An implementation SHOULD allow the operator to view the capability 824 defined in this document. To serve this purpose, the PCEP YANG 825 module [I-D.ietf-pce-pcep-yang] could be extended. 827 8.3. Liveness Detection and Monitoring 829 Mechanisms defined in this document do not imply any new liveness 830 detection and monitoring requirements in addition to those already 831 listed in [RFC5440]. 833 8.4. Verify Correct Operations 835 Mechanisms defined in this document do not imply any new operation 836 verification requirements in addition to those already listed in 837 [RFC5440]. 839 8.5. Requirements On Other Protocols 841 Mechanisms defined in this document do not imply any new requirements 842 on other protocols. 844 8.6. Impact On Network Operations 846 Mechanisms defined in this document do not have any impact on network 847 operations in addition to those already listed in [RFC5440]. 849 9. IANA Considerations 851 9.1. PCEP TLV Type Indicators 853 This document defines the following new PCEP TLV. IANA maintains a 854 sub-registry "PCEP TLV Type Indicators" in the "Path Computation 855 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 856 the following allocations from this sub-registry. 858 Value Meaning Reference 859 TBD1 SCHED-LSP-ATTRIBUTE This document 860 TBD2 SCHED-PD-LSP-ATTRIBUTE This document 862 9.2. STATEFUL-PCE-CAPABILITY TLV Flag field 864 This document defines new bits in the Flags field in the STATEFUL- 865 PCE-CAPABILITY TLV in the OPEN object. IANA maintains a sub-registry 866 "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "Path Computation 867 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 868 the following allocations from this sub-registry. 870 The following values are defined in this document: 872 Bit Description Reference 873 TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document 874 TBD4 PD-LSP-CAPABLITY (PD-bit) This document 876 9.3. Schedule TLVs Flag Field 878 IANA is requested to create a new sub-registry, named "Schedule TLVs 879 Flag Field", within the "Path Computation Element Protocol (PCEP) 880 Numbers" registry to manage the Flag field in the SCHED-LSP-ATTRIBUTE 881 and SCHED-PD-LSP-ATTRIBUTE TLVs. New values are assigned by 882 Standards Action [RFC8126]. Each bit should be tracked with the 883 following qualities: 885 o Bit number (counting from bit 0 as the most significant bit) 887 o Capability description 889 o Defining RFC 891 The following values are defined in this document: 893 Bit Description Reference 894 0 R-bit This document 895 1 C-bit This document 896 2 A-bit This document 898 9.4. PCEP-Error Object 900 IANA is requested to allocate the following new error types to the 901 existing error values within the "PCEP-ERROR Object Error Types and 902 Values" subregistry of the "Path Computation Element Protocol (PCEP) 903 Numbers" registry: 905 Error-Type Meaning 906 6 Mandatory Object missing 908 Error-value 909 TBD5: Scheduled TLV missing 911 19 Invalid Operation 913 Error-value 914 TBD6: Attempted LSP Scheduling if the scheduling 915 capability was not advertised 917 10. Acknowledgments 919 The authors of this document would also like to thank Rafal Szarecki, 920 Adrian Farrel, Cyril Margaria for the review and comments. 922 11. References 924 11.1. Normative References 926 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 927 Requirement Levels", BCP 14, RFC 2119, 928 DOI 10.17487/RFC2119, March 1997, 929 . 931 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 932 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 933 DOI 10.17487/RFC5440, March 2009, 934 . 936 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 937 Writing an IANA Considerations Section in RFCs", BCP 26, 938 RFC 8126, DOI 10.17487/RFC8126, June 2017, 939 . 941 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 942 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 943 May 2017, . 945 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 946 Computation Element Communication Protocol (PCEP) 947 Extensions for Stateful PCE", RFC 8231, 948 DOI 10.17487/RFC8231, September 2017, 949 . 951 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 952 and D. Dhody, "Optimizations of Label Switched Path State 953 Synchronization Procedures for a Stateful PCE", RFC 8232, 954 DOI 10.17487/RFC8232, September 2017, 955 . 957 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 958 Computation Element Communication Protocol (PCEP) 959 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 960 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 961 . 963 11.2. Informative References 965 [I-D.ietf-pce-pcep-yang] 966 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 967 YANG Data Model for Path Computation Element 968 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 969 yang-09 (work in progress), October 2018. 971 [I-D.litkowski-pce-state-sync] 972 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 973 Stateful Path Computation Element communication 974 procedures", draft-litkowski-pce-state-sync-04 (work in 975 progress), October 2018. 977 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 978 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 979 June 2010, . 981 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 982 Computation Element Architecture", RFC 7399, 983 DOI 10.17487/RFC7399, October 2014, 984 . 986 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 987 "PCEPS: Usage of TLS to Provide a Secure Transport for the 988 Path Computation Element Communication Protocol (PCEP)", 989 RFC 8253, DOI 10.17487/RFC8253, October 2017, 990 . 992 [RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework 993 for Scheduled Use of Resources", RFC 8413, 994 DOI 10.17487/RFC8413, July 2018, 995 . 997 Appendix A. Scheduled LSP information synchronization 999 As for a stateful PCE, it maintains a database of LSPs (LSP-DB) that 1000 are active in the network, so as to reveal the available network 1001 resources and place new LSPs more cleverly. 1003 With the scheduled LSPs, they are not activated while creation, but 1004 should be considered when operating future path computation. Hence, 1005 a scheduled LSP Database (SLSP-DB) is suggested to maintain all 1006 scheduled LSP information. 1008 The information of SLSP-DB MUST be shared and synchronized among all 1009 PCEs within the centralized network by using PCRpt and PCUpd message 1010 with scheduled LSP information as per the mechanism described in 1011 [I-D.litkowski-pce-state-sync]. 1013 The PCE should generate and maintain a scheduled TED based on LSP DB, 1014 scheduled LSP DB and TED, which is used to indicate the network 1015 resource availability on network nodes for LSP path computation. 1017 Appendix B. Contributor Addresses 1018 Xufeng Liu 1019 Ericsson 1020 USA 1021 Email: xliu@kuatrotech.com 1023 Mehmet Toy 1024 Verizon 1025 USA 1026 Email: mehmet.toy@verizon.com 1028 Vic Liu 1029 China Mobile 1030 No.32 Xuanwumen West Street, Xicheng District 1031 Beijing, 100053 1032 China 1033 Email: liu.cmri@gmail.com 1035 Lei Liu 1036 Fujitsu 1037 USA 1038 Email: lliu@us.fujitsu.com 1040 Khuzema Pithewan 1041 Infinera 1042 Email: kpithewan@infinera.com 1044 Zitao Wang 1045 Huawei 1046 101 Software Avenue, Yuhua District 1047 Nanjing, Jiangsu 210012 1048 China 1050 Email: wangzitao@huawei.com 1052 Xian Zhang 1053 Huawei Technologies 1054 Research Area F3-1B, 1055 Huawei Industrial Base, 1056 Shenzhen, 518129, China 1058 Email: zhang.xian@huawei.com 1060 Authors' Addresses 1061 Huaimo Chen (editor) 1062 Huawei 1063 Boston, MA 1064 USA 1066 Email: huaimo.chen@huawei.com 1068 Yan Zhuang (editor) 1069 Huawei 1070 101 Software Avenue, Yuhua District 1071 Nanjing, Jiangsu 210012 1072 China 1074 Email: zhuangyan.zhuang@huawei.com 1076 Qin Wu 1077 Huawei 1078 101 Software Avenue, Yuhua District 1079 Nanjing, Jiangsu 210012 1080 China 1082 Email: bill.wu@huawei.com 1084 Dhruv Dhody (editor) 1085 Huawei 1086 Divyashree Techno Park, Whitefield 1087 Bangalore, Karnataka 560066 1088 India 1090 Email: dhruv.ietf@gmail.com 1092 Daniele Ceccarelli 1093 Ericsson 1094 Via A. Negrone 1/A 1095 Genova - Sestri Ponente 1096 Italy 1098 Email: daniele.ceccarelli@ericsson.com