idnits 2.17.1 draft-ietf-pce-stateful-pce-lsp-scheduling-04.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 19, 2018) is 1953 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 346, but not defined == Missing Reference: 'Tb' is mentioned on line 346, but not defined == Missing Reference: 'TBD1' is mentioned on line 575, but not defined == Missing Reference: 'TBD2' is mentioned on line 662, but not defined == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-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 22, 2019 D. Dhody, Ed. 6 Huawei 7 D. Ceccarelli 8 Ericsson 9 December 19, 2018 11 PCEP Extensions for LSP scheduling with stateful PCE 12 draft-ietf-pce-stateful-pce-lsp-scheduling-04 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 22, 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 . . . . . . . . . . . . . . . . . . . . . . 15 75 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 15 76 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 15 77 6.3. The PCInitiate Message . . . . . . . . . . . . . . . . . 16 78 6.4. The PCReq message . . . . . . . . . . . . . . . . . . . . 16 79 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 16 80 6.6. The PCErr Message . . . . . . . . . . . . . . . . . . . . 17 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . 18 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 9.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 18 91 9.2. STATEFUL-PCE-CAPABILITY TLV Flag field . . . . . . . . . 19 92 9.3. Schedule TLVs Flag Field . . . . . . . . . . . . . . . . 19 93 9.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 19 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: a LSP with the scheduling attributes,that carries 184 traffic flow demand at a starting time and last for a certain 185 duration. The PCE operates path computation per LSP availability 186 for the required time and duration. 188 Scheduled LSP DB: a database of scheduled LSPs. 190 Scheduled TED: Traffic engineering database with the awareness of 191 scheduled resources for TE. This database is generated by the PCE 192 from the information in TED and scheduled LSP DB and allows 193 knowing, at any time, the amount of available resources (does not 194 include failures in the future). 196 Starting time(start-time): This value indicates when the scheduled 197 LSP is used and the corresponding LSP must be setup and active. 198 In other time (i.e., before the starting time or after the 199 starting time plus Duration), the LSP can be inactive to include 200 the possibility of the resources being used by other services. 202 Duration: This value indicates the time duration that the LSP is 203 undertaken by a traffic flow and the corresponding LSP must be 204 setup and active. At the end of which, the LSP is teardown and 205 removed from the data base. 207 3. Motivation and Objectives 209 A stateful PCE can support better efficiency by using LSP scheduling 210 described in the use case of [RFC8231]. This requires the PCE to 211 maintain the scheduled LSPs and their associated resource usage, e.g. 212 bandwidth for Packet-switched network, as well as have the ability to 213 trigger signaling for the LSP setup/tear-down at the correct time. 215 Note that existing configuration tools can be used for LSP 216 scheduling, but as highlighted in section 3.1.3 of [RFC8231] as well 217 as discussions in [RFC8413], doing this as a part of PCEP in a 218 centralized manner, has obvious advantages. 220 The objective of this document is to provide a set of extensions to 221 PCEP to enable LSP scheduling for LSPs creation/deletion under the 222 stateful PCE control, according to traffic services from customers, 223 so as to improve the usage of network resources. 225 4. Architecture Overview 227 4.1. LSP Scheduling Overview 229 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for 230 customers' traffic services at its actual usage time, so as to 231 improve the network resource efficient utilization. 233 For stateful PCE supporting LSP scheduling, there are two types of 234 LSP databases used in this document. One is the LSP-DB defined in 235 PCEP [RFC8231], while the other is the scheduled LSP database (SLSP- 236 DB, see section 6). The SLSP-DB records scheduled LSPs and is used 237 in conjunction with the TED and LSP-DB. Note that the two types of 238 LSP databases can be implemented in one physical database or two 239 different databases. This is an implementation matter and this 240 document does not state any preference. 242 Furthermore, a scheduled TED can be generated from the scheduled LSP- 243 DB, LSP-DB and TED to indicate the network links and nodes with 244 resource availability information for now and future. The scheduled 245 TED should be maintained by all PCEs within the network environment. 247 In case of implementing PCC-initiated scheduled LSPs, before a PCC 248 delegates a scheduled LSP, it MAY use the PCReq/PCRep messages to 249 learn the path for the scheduled LSP. A PCC MUST delegate a 250 scheduled LSP with information of its scheduling parameters, 251 including the starting time and the duration using PCRpt message. 252 Since the LSP is not yet signaled, at the time of delegation the LSP 253 would be in down state. Upon receiving the delegation of the 254 scheduled LSP, a stateful PCE SHALL check the scheduled TED for the 255 network resource availability on network nodes and computes a path 256 for the LSP with the scheduling information and update to the PCC as 257 per the active stateful PCE techniques [RFC8231]. 259 Note that the active stateful PCE can update to the PCC with the path 260 for the scheduled LSP at any time. However, the PCC should not 261 signal the LSP over the path on receiving these messages since the 262 path is not active yet; PCC signals the LSP at the starting time. 264 For a multiple PCE environment, in order to synchronize the scheduled 265 LSP-DB, the mechanism as described in [I-D.litkowski-pce-state-sync] 266 can be used to synchronize between PCEs. The scheduled TED can be 267 determined from the synchronized SLSP-DB. The PCE with delegation 268 for the scheduled LSP would report the scheduled LSP to other PCEs, 269 any future update to the scheduled LSP is also updated to other PCEs. 270 This way the state of all scheduled LSPs are synchronized among the 271 PCEs. [RFC7399] discusses some synchronization issues and 272 considerations, that are also applicable to the scheduled databases. 274 The scheduled LSP can also be initiated by PCE itself. In case of 275 implementing PCE-initiated scheduled LSP, the stateful PCE shall 276 check the network resource availability for the traffic and computes 277 a path for the scheduled LSP and initiate a scheduled LSP at the PCC 278 and synchronize the scheduled LSP to other PCEs. Note that, the PCC 279 could be notified immediately or at the starting time of the 280 scheduled LSP based on the local policy. In case of former SCHED- 281 LSP-ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the message 282 where as for the latter SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be 283 included. Either way the synchronization to other PCEs should be 284 done when the scheduled LSP is created. 286 In both modes, for activation of scheduled LSPs, the PCC could 287 initiate the setup of scheduled LSP at the start time by itself or 288 wait for the PCE to update the PCC to initiate the setup of LSP. 289 Similarly on the scheduling usage expires, the PCC could initiate the 290 removal by itself or wait for the PCE to request the removal of the 291 LSP. This is based on the Flag set in SCHED-LSP-ATTRIBUTE TLV. The 292 state of the scheduled LSP is synchronized to other PCEs using the 293 existing mechanism in [RFC8231] and [I-D.litkowski-pce-state-sync]. 295 4.2. Support of LSP Scheduling 297 4.2.1. LSP Scheduling 299 For a scheduled LSP, a user configures it with an arbitrary 300 scheduling duration time from Ta to time Tb, which may be represented 301 as [Ta, Tb]. 303 When an LSP is configured with arbitrary scheduling duration [Ta, 304 Tb], a path satisfying the constraints for the LSP in the scheduling 305 duration is computed and the LSP along the path is set up to carry 306 traffic from time Ta to time Tb. 308 4.2.2. Periodical LSP Scheduling 310 In addition to LSP Scheduling at an arbitrary time period, there are 311 also periodical LSP Scheduling. 313 A periodical LSP Scheduling represents Scheduling LSP every time 314 interval. It has a scheduling duration such as [Ta, Tb], a number of 315 repeats such as 10 (repeats 10 times), and a repeat cycle/time 316 interval such as a week (repeats every week). The scheduling 317 interval: "[Ta, Tb] repeats n times with repeat cycle C" represents 318 n+1 scheduling intervals as follows: 320 [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC] 322 When an LSP is configured with a scheduling interval such as "[Ta, 323 Tb] repeats 10 times with a repeat cycle a week" (representing 11 324 scheduling intervals), a path satisfying the constraints for the LSP 325 in each of the scheduling intervals represented by the periodical 326 scheduling interval is computed and the LSP along the path is set up 327 to carry traffic in each of the scheduling intervals. 329 4.2.2.1. Elastic Time LSP Scheduling 331 In addition to the basic LSP scheduling at an arbitrary time period, 332 another option is elastic time intervals, which is represented as 333 within -P and Q, where P and Q is an amount of time such as 300 334 seconds. P is called elastic range lower bound and Q is called 335 elastic range upper bound. 337 For a simple time interval such as [Ta, Tb] with an elastic range, 338 elastic time interval: "[Ta, Tb] within -P and Q" means a time period 339 from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb 340 is shifted by the same 'X'. 342 When an LSP is configured with elastic time interval "[Ta, Tb] within 343 -P and Q", a path is computed such that the path satisfies the 344 constraints for the LSP in the time period from (Ta+X) to (Tb+X) 345 and |X| is the minimum value from 0 to max(P, Q). That is, [Ta+X, 346 Tb+X] is the time interval closest to time interval [Ta, Tb] within 347 the elastic range. The LSP along the path is set up to carry traffic 348 in the time period from (Ta+X) to (Tb+X). 350 Similarly, for a recurrent time interval with an elastic range, 351 elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C 352 within -P and Q" represents n+1 simple elastic time intervals as 353 follows: 355 [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn] 356 where -P <= Xi <= Q, i = 0, 1, 2, ..., n. 358 If a user wants to keep the same repeat cycle between any two 359 adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n 360 times with repeat cycle C within -P and Q SYNC" may be used, which 361 represents n+1 simple elastic time intervals as follows: 363 [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X] 364 where -P <= X <= Q. 366 4.2.2.2. Graceful Periods 368 Besides the stated time scheduling, a user may want to have some 369 graceful periods for each or some of the time intervals for the LSP. 370 Two graceful periods may be configured for a time interval. One is 371 the graceful period before the time interval, called grace-before, 372 which extends the lifetime of the LSP for grace-before (such as 30 373 seconds) before the time interval. The other is the one after the 374 time interval, called grace-after, which extends the lifetime of the 375 LSP for grace-after (such as 60 seconds) after the time interval. 377 When an LSP is configured with a simple time interval such as [Ta, 378 Tb] with graceful periods such as grace-before GB and grace-after GA, 379 a path is computed such that the path satisfies the constraints for 380 the LSP in the time period from Ta to Tb. The LSP along the path is 381 set up to carry traffic in the time period from (Ta-GB) to (Tb+GA). 382 During graceful periods from (Ta-GB) to Ta and from Tb to (Tb+GA), 383 the LSP is up to carry traffic (maybe in best effort). 385 4.3. Scheduled LSP creation 387 In order to realize PCC-Initiated scheduled LSP in a centralized 388 network environment, a PCC has to separate the setup of a LSP into 389 two steps. The first step is to request/delegate and get a LSP but 390 not signal it over the network. The second step is to signal the 391 scheduled LSP over the LSRs (Labeled switched Router) at its starting 392 time. 394 For PCC-Initiated scheduled LSPs, a PCC can delegate the scheduled 395 LSP by sending a path computation report (PCRpt) message by including 396 its demanded resources with the scheduling information to a stateful 397 PCE. Note the PCC MAY use the PCReq/PCRep with scheduling 398 information before delegating. 400 Upon receiving the delegation via PCRpt message, the stateful PCE 401 computes the path for the scheduled LSP per its starting time and 402 duration based on the network resource availability stored in 403 scheduled TED (see Section 4.1). 405 The stateful PCE will send a PCUpd message with the scheduled path 406 information as well as the scheduled resource information for the 407 scheduled LSP to the PCC. The PCE SHOULD add the scheduled LSP into 408 its scheduled LSP-DB and update its scheduled TED. The PCE MUST also 409 synchronize to other PCEs within the network if there is any, so as 410 to keep their scheduling information synchronized as per 411 [I-D.litkowski-pce-state-sync]. 413 For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path 414 for the scheduled LSP per requests from network management systems 415 automatically based on the network resource availability in the 416 scheduled TED, send a PCInitiate message with the path information 417 back to the PCC. Based on the local policy, the PCInitiate message 418 could be sent immediately to ask PCC to create a scheduled LSP (as 419 per this document) or the PCInitiate message could be sent at the 420 start time to the PCC to create a normal LSP (as per [RFC8281]). 422 In both modes: 424 o The stateful PCE is required to update its local scheduled LSP DB 425 and scheduled TED with the scheduled LSP. Besides, it shall send 426 a PCRpt message with the scheduled LSP to other PCEs within the 427 network, so as to achieve the scheduling traffic engineering 428 information synchronization as per [I-D.litkowski-pce-state-sync]. 430 o Upon receiving the PCUpd message or PCInitiate message for the 431 scheduled LSP from PCEs with a found path, the PCC knows that it 432 is a scheduled path for the LSP and does not trigger signaling for 433 the LSP setup on LSRs immediately. 435 o The stateful PCE can update the Scheduled LSP parameters on any 436 network events using the PCUpd message to PCC. These changes are 437 also synchronized to other PCEs as per 438 [I-D.litkowski-pce-state-sync]. 440 o Based on the configuration (and the C flag in scheduled TLVs), 441 when it is time (i.e., at the start time) for the LSP to be set 442 up, either the PCC triggers the LSP to be signaled or the 443 delegated PCE sends a PCUpd message to the head end LSR providing 444 the updated path to be signaled (with A flag set to indicate LSP 445 activation). 447 4.4. Scheduled LSP Modifications 449 After a scheduled LSP is configured, a user may change its parameters 450 including the requested time as well as the bandwidth. 452 In PCC-Initiated case, the PCC can send a PCRpt message for the 453 scheduled LSP with updated parameters as well as scheduled 454 information included in the SCHED-LSP-ATTRIBUTE TLV (see 455 Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) 456 carried in the LSP Object. The PCE would take the updated resources 457 and schedule into considerations and update the new path for the 458 scheduled LSP to the PCC as well as synchronize to other PCEs in the 459 network. In case path cannot be set based on new requirements the 460 same should be conveyed by the use of empty ERO in the PCEP messages. 462 In PCE-Initiated case, the Stateful PCE would recompute the path 463 based on updated parameters as well as scheduled information. In 464 case it has already conveyed to the PCC this information by sending a 465 PCInitiate message, it should update the path and other scheduling 466 and resource information by sending a PCUpd message. 468 In any case, the scheduled databases SHALL be updated and the PCE 469 MUST synchronize this information to other PCEs as per 470 [I-D.litkowski-pce-state-sync]. 472 4.5. Scheduled LSP activation and deletion 474 In PCC-Initiated case, based on the configuration (and the C flag in 475 scheduled TLVs), when it is time (i.e., at the start time) for the 476 LSP to be set up, either the PCC triggers the LSP to be signaled or 477 the delegated PCE sends a PCUpd message to the head end LSR providing 478 the updated path to be signaled (with A flag set to indicate LSP 479 activation). The PCC would report the status of the active LSP as 480 per the procedures in [RFC8231] and at this time the LSP MUST be 481 considered as part of the LSP-DB. The A flag MUST be set in the 482 scheduled TLVs to indicate that the LSP is active now. After the 483 scheduled duration expires, based on the C flag, the PCC triggers the 484 LSP deletion on it self or the delegated PCE sends a PCUpd message to 485 the PCC to delete the LSP as per the procedures in [RFC8231]. 487 In PCE-Initiated case, based on the local policy, if the scheduled 488 LSP is already conveyed to the PCC at the time of creation, the 489 handling of LSP activation and deletion is handled in the same way as 490 PCC-Initiated case as per the setting of C flag. In other case, the 491 PCE would send the PCInitiate message at the start time to the PCC to 492 create a normal LSP without the scheduled TLVs and remove the LSP 493 after the duration expires as per [RFC8281]. 495 Additionally, the scheduled databases SHALL be updated and 496 synchronization to other PCEs MUST be done as per 497 [I-D.litkowski-pce-state-sync]. 499 5. PCEP Objects and TLVs 501 5.1. Stateful PCE Capability TLV 503 After a TCP connection for a PCEP session has been established, a PCC 504 and a PCE indicates its ability to support LSP scheduling during the 505 PCEP session establishment phase. For a multiple-PCE environment, 506 the PCEs should also establish PCEP session and indicate its ability 507 to support LSP scheduling among PCEP peers. The Open Object in the 508 Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in 509 [RFC8231]. Note that the STATEFUL- PCE-CAPABILITY TLV is defined in 510 [RFC8231] and updated in [RFC8281] and [RFC8232]". In this document, 511 we define a new flag bit B (SCHED-LSP-CAPABLITY) flag for the 512 STATEFUL- PCE-CAPABILITY TLV to indicate the support of LSP 513 scheduling and another flag bit PD (PD-LSP-CAPABLITY) to indicate the 514 support of LSP periodical scheduling. 516 B (LSP-SCHEDULING-CAPABILITY - 1 bit) [Bit Position - TBD3]: If set 517 to 1 by a PCC, the B Flag indicates that the PCC allows LSP 518 scheduling; if set to 1 by a PCE, the B Flag indicates that the 519 PCE is capable of LSP scheduling. The B bit MUST be set by both 520 PCEP peers in order to support LSP scheduling for path 521 computation. 523 PD (PD-LSP-CAPABLITY - 1 bit): [Bit Position - TBD4] If set to 1 by 524 a PCC, the PD Flag indicates that the PCC allows LSP scheduling 525 periodically; if set to 1 by a PCE, the PD Flag indicates that the 526 PCE is capable of periodical LSP scheduling. The PD bit MUST be 527 set by both PCEP peers in order to support periodical LSP 528 scheduling for path computation. 530 5.2. LSP Object 532 The LSP object is defined in [RFC8231]. This document add an 533 optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an 534 optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP scheduling. 536 The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates 537 that this LSP is requesting scheduled parameters while the SCHED-PD- 538 LSP-ATTRIBUTE TLV indicates that this scheduled LSP is periodical. 539 The scheduled LSP attribute TLV MUST be present in LSP Object for 540 each scheduled LSP carried in the PCEP messages. For periodical 541 LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in LSP Object for 542 each periodic scheduled LSP carried in the PCEP messages. 544 Only one of these TLV SHOULD be present in the LSP object. In case 545 more than one scheduling TLV is found, the first instance is 546 processed and others ignored. 548 5.2.1. SCHED-LSP-ATTRIBUTE TLV 550 The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV within 551 the LSP object for LSP scheduling for the requesting traffic service. 553 This TLV SHOULD be included only if both PCEP peers have set the B 554 (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV 555 carried in open message. 557 The format of the SCHED-LSP-ATTRIBUTE TLV is shown in the following 558 figure: 560 0 1 2 3 561 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type (TBD1) | Length | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 |R|C|A| Flags | Reserved (0) | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Start-Time | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Duration | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | GrB | GrA | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Elastic-Lower-Bound | Elastic-Upper-Bound | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 The type of the TLV is [TBD1] and the TLV has a fixed length of 20 576 octets. 578 The fields in the format are: 580 Flags (8 bits): Following flags are defined in this document 582 R (1 bit): Set to 1 to indicate the Start-Time is a relative 583 time, which is relative to the current time; set to 0 to 584 indicate the the Start-Time is an absolute time. 586 C (1 bit): Set to 1 to indicate the PCC is responsible to setup 587 and remove the scheduled LSP based on the Start-Time and 588 duration. 590 A (1 bit): Set to 1 to indicate the scheduled LSP has been 591 activated and should be considered as part of LSP-DB (instead 592 of Scheduled LSP-DB). 594 Reserved (24 bits): This field MUST be set to zero on transmission 595 and MUST be ignored on receipt. 597 Start-Time (32 bits): This value in seconds, indicates when the 598 scheduled LSP is used to carry traffic and the corresponding LSP 599 must be setup and activated. 601 Duration (32 bits): The value in seconds, indicates the duration 602 that the LSP is undertaken by a traffic flow and the corresponding 603 LSP must be up to carry traffic. At the expiry of this duration, 604 the LSP is tear down and deleted. 606 The Start-Time indicates a calendar time (e.g.,2018/12/13 8:29:58), 607 at or before which the scheduled LSP must be set up. The value of 608 the Start-Time represents the number of seconds since 00:00 hours,Jan 609 1, 1970 UTC when R bit is set to 0. When R bit is set to 1, it 610 represents the number of seconds from the current time. 612 In addition, it contains an non zero grace-before and grace-after if 613 graceful periods are configured. It includes an non zero elastic 614 range lower bound and upper bound if there is an elastic range 615 configured. 617 o GrB (Grace-Before -16 bits): The graceful period time length in 618 seconds before the starting time. 620 o GrA (Grace-After -16 bits): The graceful period time length in 621 seconds after time interval [starting time, starting time + 622 duration]. 624 o Elastic-Lower-Bound (16 bits): The maximum amount of time in 625 seconds that time interval can shift to lower/left. 627 o Elastic-Upper-Bound (16 bits): The maximum amount of time in 628 seconds that time interval can shift to upper/right. 630 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV 632 The periodical LSP is a special case of LSP scheduling. The traffic 633 service happens in a series of repeated time intervals. The SCHED- 634 PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the 635 LSP object for this periodical LSP scheduling. 637 This TLV SHOULD be included only if both PCEP peers have set the B 638 (LSP-SCHEDULING-CAPABILITY bit) and PD (PD-LSP-CAPABLITY bit) in 639 STATEFUL-PCE-CAPABILITY TLV carried in open message. 641 The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in the 642 following figure: 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Type (TBD2) | Length | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 |R|C|A| Flags | Opt | NR | Reserved (0) | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Start-Time | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Duration | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Repeat-time-length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | GrB | GrA | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Elastic-Lower-Bound | Elastic-Upper-Bound | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 The type of the TLV is [TBD2] and the TLV has a fixed length of 24 663 octets. The description, format and meaning of the Flags (R, C and A 664 bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and 665 Elastic-Upper-Bound fields remains same as SCHED-LSP-ATTRIBUTE TLV. 667 The following fields are new : 669 Opt: (4 bits) Indicates options to repeat. 671 Options = 1: repeat every day; 673 Options = 2: repeat every week; 675 Options = 3: repeat every month; 677 Options = 4: repeat every year; 679 Options = 5: repeat every Repeat-time-length. 681 NR:(4 bits) The number of repeats. In each of repeats, LSP carries 682 traffic. If value is set to 0xFFFF, it indicates forever. 684 Reserved (16 bits): This field MUST be set to zero on transmission 685 and MUST be ignored on receipt. 687 Repeat-time-length:(32 bits) The time length in seconds after which 688 LSP starts to carry traffic again for the Duration. 690 6. The PCEP Messages 692 6.1. The PCRpt Message 694 Path Computation State Report (PCRpt) is a PCEP message sent by a PCC 695 to a PCE to report the status of one or more LSPs as per [RFC8231]. 696 Each LSP State Report in a PCRpt message contains the actual LSP's 697 path, bandwidth, operational and administrative status, etc. An LSP 698 Status Report carried on a PCRpt message is also used in delegation 699 or revocation of control of an LSP to/from a PCE. In case of 700 scheduled LSP, the scheduled TLVs MUST be carried in the LSP object 701 and the ERO conveys the intended path for the scheduled LSP. The 702 scheduled LSP MUST be delegated to a PCE. This message is also used 703 to synchronize the scheduled LSPs to other PCE as described in 704 [RFC8231] and [I-D.litkowski-pce-state-sync]. 706 6.2. The PCUpd Message 708 Path Computation Update Request (PCUpd) is a PCEP message sent by a 709 PCE to a PCC to update LSP parameters, on one or more LSPs as per 710 [RFC8231]. Each LSP Update Request on a PCUpd message contains all 711 LSP parameters that a PCE wishes to be set for a given LSP. In case 712 of scheduled LSP, the scheduled TLVs MUST be carried in the LSP 713 object and the ERO conveys the intended path for the scheduled LSP. 714 In case no path can be found, an empty ERO is used. The A bit is 715 used in PCUpd message to indicate the activation of the scheduled LSP 716 in case the PCE is responsible for the activation (as per the C bit). 717 This message is also used to synchronize the scheduled LSPs to other 718 PCE as described in [I-D.litkowski-pce-state-sync]. 720 6.3. The PCInitiate Message 722 An LSP Initiate Request (PCInitiate) message is a PCEP message sent 723 by a PCE to a PCC to trigger LSP instantiation or deletion as per 724 [RFC8281]. In case of scheduled LSP, based on the local policy, PCE 725 MAY convey the scheduled LSP to the PCC by including the scheduled 726 TLVs in the LSP object. Or the PCE would initiate the LSP only at 727 the start time of the scheduled LSP as per the [RFC8281] without the 728 use of scheduled TLVs. 730 6.4. The PCReq message 732 The Path Computation Request (PCReq) message is a PCEP message sent 733 by a PCC to a PCE to request a path computation [RFC5440] and it may 734 contain the LSP object [RFC8231] to identify the LSP for which the 735 path computation is requested. In case of scheduled LSP, the 736 scheduled TLVs MUST be carried in the LSP object in PCReq message to 737 request the path computation based on scheduled TED and LSP-DB. A 738 PCC MAY use PCReq message to obtain the scheduled path before 739 delegating the LSP. 741 6.5. The PCRep Message 743 The Path Computation Reply (PCRep) message is a PCEP message sent by 744 a PCE to a PCC in reply to a path computation request [RFC5440] and 745 it may contain the LSP object [RFC8231] to identify the LSP for which 746 the path is computed. A PCRep message can contain either a set of 747 computed paths if the request can be satisfied, or a negative reply 748 if not. The negative reply may indicate the reason why no path could 749 be found. In case of scheduled LSP, the scheduled TLVs MUST be 750 carried in the LSP object in PCRep message to indicate the path 751 computation based on scheduled TED and LSP-DB. A PCC and PCE MAY use 752 PCReq and PCRep message to obtain the scheduled path before 753 delegating the LSP. 755 6.6. The PCErr Message 757 The Path Computation Error (PCErr) message is a PCEP message as 758 described in [RFC5440] for error reporting. The current document 759 defines new error values for several error types to cover failures 760 specific to scheduling and reuse the applicable error types and error 761 values of [RFC5440] and [RFC8231] wherever appropriate. 763 The PCEP extensions for scheduling MUST NOT be used if one or both 764 PCEP speakers have not set the corresponding bits in the STATEFUL- 765 PCE-CAPABILITY TLV in their respective OPEN message. If the PCEP 766 speaker supports the extensions of this specification but did not 767 advertise this capability, then upon receipt of LSP object with the 768 scheduled TLV, it MUST generate a PCEP Error (PCErr) with Error- 769 type=19 (Invalid Operation) and error-value TBD6 (Attempted LSP 770 Scheduling if the scheduling capability was not advertised), and it 771 SHOULD terminate the PCEP session. As per Section 7.1 of [RFC5440], 772 a legacy PCEP implementation that does not understand this 773 specification, would consider the scheduled TLVs as unknown and 774 ignore them. 776 If the PCC decides that the scheduling parameters proposed in the 777 PCUpd/PCInitiate message are unacceptable, it MUST report this error 778 by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error- 779 value="Unacceptable parameters" in the LSP object (with scheduled 780 TLVs) in the PCRpt message to the PCE. 782 The scheduled TLVs MUST be included in the LSP object for the 783 scheduled LSPs, if the TLV is missing, the receiving PCEP speaker 784 MUST send a PCErr message with Error-type=6 (Mandatory Object 785 missing) and Error-value TBD5 (Scheduled TLV missing). 787 7. Security Considerations 789 This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED- LSP- 790 ATTRIBUTE TLV, the security considerations discussed in [RFC5440], 791 [RFC8231], and [RFC8281] continue to apply. In some deployments the 792 scheduling information could provide details about the network 793 operations that could be deemed as extra sensitive. Additionally, 794 snooping of PCEP messages with such data or using PCEP messages for 795 network reconnaissance may give an attacker sensitive information 796 about the operations of the network. Thus, such deployment should 797 employ suitable PCEP security mechanisms like TCP Authentication 798 Option (TCP-AO) [RFC5925] or [RFC8253]. The procedure based on 799 Transport Layer Security (TLS) in [RFC8253] is considered a security 800 enhancement and thus is much better suited for the sensitive 801 information. 803 8. Manageability Consideration 805 8.1. Control of Function and Policy 807 The LSP-Scheduling feature MUST BE controlled per tunnel by the 808 active stateful PCE, the values for parameters like starting time, 809 duration SHOULD BE configurable by customer applications and based on 810 the local policy at PCE. 812 8.2. Information and Data Models 814 An implementation SHOULD allow the operator to view the capability 815 defined in this document. To serve this purpose, the PCEP YANG 816 module [I-D.ietf-pce-pcep-yang] could be extended. 818 8.3. Liveness Detection and Monitoring 820 Mechanisms defined in this document do not imply any new liveness 821 detection and monitoring requirements in addition to those already 822 listed in [RFC5440]. 824 8.4. Verify Correct Operations 826 Mechanisms defined in this document do not imply any new operation 827 verification requirements in addition to those already listed in 828 [RFC5440]. 830 8.5. Requirements On Other Protocols 832 Mechanisms defined in this document do not imply any new requirements 833 on other protocols. 835 8.6. Impact On Network Operations 837 Mechanisms defined in this document do not have any impact on network 838 operations in addition to those already listed in [RFC5440]. 840 9. IANA Considerations 842 9.1. PCEP TLV Type Indicators 844 This document defines the following new PCEP TLV. IANA maintains a 845 sub-registry "PCEP TLV Type Indicators" in the "Path Computation 846 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 847 the following allocations from this sub-registry. 849 Value Meaning Reference 850 TBD1 SCHED-LSP-ATTRIBUTE This document 851 TBD2 SCHED-PD-LSP-ATTRIBUTE This document 853 9.2. STATEFUL-PCE-CAPABILITY TLV Flag field 855 This document defines new bits in the Flags field in the STATEFUL- 856 PCE-CAPABILITY TLV in the OPEN object. IANA maintains a sub-registry 857 "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "Path Computation 858 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 859 the following allocations from this sub-registry. 861 The following values are defined in this document: 863 Bit Description Reference 864 TBD3 LSP-SCHEDULING-CAPABILITY (B-bit) This document 865 TBD4 PD-LSP-CAPABLITY (PD-bit) This document 867 9.3. Schedule TLVs Flag Field 869 IANA is requested to create a new sub-registry, named "Schedule TLVs 870 Flag Field", within the "Path Computation Element Protocol (PCEP) 871 Numbers" registry to manage the Flag field in the SCHED-LSP-ATTRIBUTE 872 and SCHED-PD-LSP-ATTRIBUTE TLVs. New values are assigned by 873 Standards Action [RFC8126]. Each bit should be tracked with the 874 following qualities: 876 o Bit number (counting from bit 0 as the most significant bit) 878 o Capability description 880 o Defining RFC 882 The following values are defined in this document: 884 Bit Description Reference 885 0 R-bit This document 886 1 C-bit This document 887 2 A-bit This document 889 9.4. PCEP-Error Object 891 IANA is requested to allocate the following new error types to the 892 existing error values within the "PCEP-ERROR Object Error Types and 893 Values" subregistry of the "Path Computation Element Protocol (PCEP) 894 Numbers" registry: 896 Error-Type Meaning 897 6 Mandatory Object missing 899 Error-value 900 TBD5: Scheduled TLV missing 902 19 Invalid Operation 904 Error-value 905 TBD6: Attempted LSP Scheduling if the scheduling 906 capability was not advertised 908 10. Acknowledgments 910 The authors of this document would also like to thank Rafal Szarecki, 911 Adrian Farrel, Cyril Margaria for the review and comments. 913 11. References 915 11.1. Normative References 917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 918 Requirement Levels", BCP 14, RFC 2119, 919 DOI 10.17487/RFC2119, March 1997, 920 . 922 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 923 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 924 DOI 10.17487/RFC5440, March 2009, 925 . 927 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 928 Writing an IANA Considerations Section in RFCs", BCP 26, 929 RFC 8126, DOI 10.17487/RFC8126, June 2017, 930 . 932 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 933 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 934 May 2017, . 936 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 937 Computation Element Communication Protocol (PCEP) 938 Extensions for Stateful PCE", RFC 8231, 939 DOI 10.17487/RFC8231, September 2017, 940 . 942 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 943 and D. Dhody, "Optimizations of Label Switched Path State 944 Synchronization Procedures for a Stateful PCE", RFC 8232, 945 DOI 10.17487/RFC8232, September 2017, 946 . 948 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 949 Computation Element Communication Protocol (PCEP) 950 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 951 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 952 . 954 11.2. Informative References 956 [I-D.ietf-pce-pcep-yang] 957 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 958 YANG Data Model for Path Computation Element 959 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 960 yang-09 (work in progress), October 2018. 962 [I-D.litkowski-pce-state-sync] 963 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 964 Stateful Path Computation Element communication 965 procedures", draft-litkowski-pce-state-sync-04 (work in 966 progress), October 2018. 968 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 969 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 970 June 2010, . 972 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 973 Computation Element Architecture", RFC 7399, 974 DOI 10.17487/RFC7399, October 2014, 975 . 977 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 978 "PCEPS: Usage of TLS to Provide a Secure Transport for the 979 Path Computation Element Communication Protocol (PCEP)", 980 RFC 8253, DOI 10.17487/RFC8253, October 2017, 981 . 983 [RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework 984 for Scheduled Use of Resources", RFC 8413, 985 DOI 10.17487/RFC8413, July 2018, 986 . 988 Appendix A. Scheduled LSP information synchronization 990 As for a stateful PCE, it maintains a database of LSPs (LSP-DB) that 991 are active in the network, so as to reveal the available network 992 resources and place new LSPs more cleverly. 994 With the scheduled LSPs, they are not activated while creation, but 995 should be considered when operating future path computation. Hence, 996 a scheduled LSP Database (SLSP-DB) is suggested to maintain all 997 scheduled LSP information. 999 The information of SLSP-DB MUST be shared and synchronized among all 1000 PCEs within the centralized network by using PCRpt and PCUpd message 1001 with scheduled LSP information as per the mechanism described in 1002 [I-D.litkowski-pce-state-sync]. 1004 The PCE should generate and maintain a scheduled TED based on LSP DB, 1005 scheduled LSP DB and TED, which is used to indicate the network 1006 resource availability on network nodes for LSP path computation. 1008 Appendix B. Contributor Addresses 1009 Xufeng Liu 1010 Ericsson 1011 USA 1012 Email: xliu@kuatrotech.com 1014 Mehmet Toy 1015 Verizon 1016 USA 1017 Email: mehmet.toy@verizon.com 1019 Vic Liu 1020 China Mobile 1021 No.32 Xuanwumen West Street, Xicheng District 1022 Beijing, 100053 1023 China 1024 Email: liu.cmri@gmail.com 1026 Lei Liu 1027 Fujitsu 1028 USA 1029 Email: lliu@us.fujitsu.com 1031 Khuzema Pithewan 1032 Infinera 1033 Email: kpithewan@infinera.com 1035 Zitao Wang 1036 Huawei 1037 101 Software Avenue, Yuhua District 1038 Nanjing, Jiangsu 210012 1039 China 1041 Email: wangzitao@huawei.com 1043 Xian Zhang 1044 Huawei Technologies 1045 Research Area F3-1B, 1046 Huawei Industrial Base, 1047 Shenzhen, 518129, China 1049 Email: zhang.xian@huawei.com 1051 Authors' Addresses 1052 Huaimo Chen (editor) 1053 Huawei 1054 Boston, MA 1055 USA 1057 Email: huaimo.chen@huawei.com 1059 Yan Zhuang (editor) 1060 Huawei 1061 101 Software Avenue, Yuhua District 1062 Nanjing, Jiangsu 210012 1063 China 1065 Email: zhuangyan.zhuang@huawei.com 1067 Qin Wu 1068 Huawei 1069 101 Software Avenue, Yuhua District 1070 Nanjing, Jiangsu 210012 1071 China 1073 Email: bill.wu@huawei.com 1075 Dhruv Dhody (editor) 1076 Huawei 1077 Divyashree Techno Park, Whitefield 1078 Bangalore, Karnataka 560066 1079 India 1081 Email: dhruv.ietf@gmail.com 1083 Daniele Ceccarelli 1084 Ericsson 1085 Via A. Negrone 1/A 1086 Genova - Sestri Ponente 1087 Italy 1089 Email: daniele.ceccarelli@ericsson.com