idnits 2.17.1 draft-zhuang-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 22, 2016) is 2681 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: 'RFC7399' is mentioned on line 120, but not defined == Missing Reference: 'TBD' is mentioned on line 440, but not defined == Unused Reference: 'I-D.dhody-pce-stateful-pce-auto-bandwidth' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-stateful-sync-optimizations' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-scheduled-resources' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-stateful-pce-app' is defined on line 608, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-07 == Outdated reference: A later version (-07) exists of draft-ietf-teas-scheduled-resources-01 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-scheduled-resources (ref. 'I-D.ietf-teas-scheduled-resources') -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Y. Zhuang 3 Internet-Draft Q. Wu 4 Intended status: Standards Track D. Dhody 5 Expires: June 25, 2017 Huawei 6 D. Ceccarelli 7 Ericsson 8 December 22, 2016 10 PCEP Extensions for LSP scheduling with stateful PCE 11 draft-zhuang-pce-stateful-pce-lsp-scheduling-04 13 Abstract 15 This document proposes a set of extensions needed to the stateful 16 Path Computation Element (PCE) communication Protocol (PCEP), so as 17 to enable Labeled Switched Path (LSP) scheduling for path computation 18 and LSP setup/deletion based on the actual network resource usage 19 duration of a traffic service in a centralized network environment as 20 stated in [I.D.ietf-teas-scheduled-resources]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 25, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Motivation and Objectives . . . . . . . . . . . . . . . . . . 5 60 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 61 4.1. LSP scheduling Overview . . . . . . . . . . . . . . . . . 5 62 4.2. Support of LSP Scheduling . . . . . . . . . . . . . . . . 6 63 4.2.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 6 64 4.3. Scheduled LSP creation . . . . . . . . . . . . . . . . . 7 65 4.3.1. The PCReq message and PCRpt Message . . . . . . . . . 8 66 4.3.2. The PCRep Message . . . . . . . . . . . . . . . . . . 9 67 4.3.3. The PCUpd Message . . . . . . . . . . . . . . . . . . 9 68 4.3.4. LSP Object . . . . . . . . . . . . . . . . . . . . . 9 69 4.4. Scheduled LSP activation and deletion . . . . . . . . . . 11 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. Manageability Consideration . . . . . . . . . . . . . . . . . 11 72 6.1. Control of Function and Policy . . . . . . . . . . . . . 11 73 6.2. Information and Data Models . . . . . . . . . . . . . . . 11 74 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 75 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 76 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 77 6.6. Impact On Network Operations . . . . . . . . . . . . . . 12 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 12 80 7.2. LSP-SCHEDULING-CAPABLITY . . . . . . . . . . . . . . . . 12 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 9.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Appendix A. Scheduled LSP information synchronization . . . . . 14 86 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 The Path Computation Element Protocol (PCEP) defined in [RFC5440] is 92 used between a Path Computation Element (PCE) and a Path Computation 93 Client (PCC) (or other PCE) to enable computation of Multi-protocol 94 Label Switching (MPLS) for Traffic Engineering Label Switched Path 95 (TE LSP). 97 Further, in order to support use cases described in [I-D.ietf-pce- 98 stateful-pce-app], [I-D.ietf-pce-stateful-pce] specifies a set of 99 extensions to PCEP to enable stateful control of MPLS-TE and GMPLS 100 LSPs via PCEP. 102 Traditionally, the usage and allocation of network resources, 103 especially bandwidth, can be supported by a Network Management System 104 operation such as path pre-establishment. However, this does not 105 provide efficient network usage since the established paths exclude 106 the possibility of being used by other services even when they are 107 not used for undertaking any service. [I-D.ietf-teas-scheduled- 108 resources] then provides a framework that describes and discusses the 109 problem and propose an appropriate architecture for the scheduled 110 reservation of TE resources. 112 With the scheduled reservation of TE resources, it allows network 113 operators to reserve resources in advance according to the agreements 114 with their customers, and allow them to transmit data with scheduling 115 such as specified starting time and duration, for example for a 116 scheduled bulk data replication between data centers. It enables the 117 activation of bandwidth usage at the time the service really being 118 used while letting other services obtain it in spare time. The 119 requirement of scheduled LSP provision is mentioned in [I-D.ietf-pce- 120 stateful-pce-app] and [RFC7399], so as to provide more efficient 121 network resource usage for traffic engineering, which hasn't been 122 solved yet. Also, for deterministic networks, the scheduled LSP can 123 provide a better network resource usage for guaranteed links. This 124 idea can also be applied in segment routing to schedule the network 125 resources over the whole network in a centralized manner as well. 127 With this in mind, this document proposes a set of extensions needed 128 to the stateful PCE, so as to enable LSP scheduling for path 129 computation and LSP setup/deletion based on the actual network 130 resource usage duration of a traffic service. A scheduled LSP is 131 characterized by a starting time and a duration. When the end of the 132 LSP life is reached, it is deleted to free up the resources for other 133 LSP (scheduled or not). 135 2. Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC2119 [RFC2119]. 141 2.1. Terminology 143 The following terminologies are re-used from existing PCE documents. 145 o Active Stateful PCE [I-D.ietf-pce-stateful-pce]; 147 o Delegation [I-D.ietf-pce-pce-initiated-lsp]; 149 o PCC [RFC5440], [I-D.ietf-pce-stateful-pce]; 151 o PCE [RFC5440], [I-D.ietf-pce-stateful-pce]; 153 o TE LSP [RFC5440], [I-D.ietf-pce-stateful-pce]; 155 o TED [RFC5440], [I-D.ietf-pce-stateful-pce]; 157 o LSP DB [RFC5440], [I-D.ietf-pce-stateful-pce]; 159 In addition, this document defines the following terminologies. 161 Scheduled TE LSP: a LSP with the scheduling attributes,that carries 162 traffic flow demand at an starting time and last for a certain 163 duration. The PCE operates path computation per LSP availability 164 at the required time and duration. 166 Scheduled LSP DB: a database of scheduled LSPs 168 Scheduled TED: Traffic engineering database with the awareness of 169 scheduled resources for TE. This database is generated by the PCE 170 from the information in TED and scheduled LSP DB and allows 171 knowing, at any time, the amount of available resources (does not 172 include failures in the future). 174 Starting time: This value indicates when the scheduled LSP is used 175 and the corresponding LSP must be setup and active. In other 176 time(i.e., before the starting time or after the starting time 177 plus Duration), the LSP can be inactive to include the possibility 178 of the resources being used by other services. 180 Duration: The value indicates the time duration that the LSP is 181 undertaken by a traffic flow and the corresponding LSP must be 182 setup and active. At the end of which, the LSP is teardown and 183 removed from the data base. 185 3. Motivation and Objectives 187 A stateful PCE can support better efficiency by using LSP scheduling 188 described in the use case of [I-D.ietf-pce-stateful-pce]. This 189 requires the PCE to maintain the scheduled LSPs and their associated 190 resource usage, e.g. bandwidth for Packet-switched network, as well 191 as the ability to trigger signaling for the LSP setup/tear-down at 192 the correct time. 194 Note that existing configuration tools can be used for LSP 195 scheduling, but as highlighted in section 3.1.3 of [I-D.ietf-pce- 196 stateful-pce] as well as discussions in [I-D.ietf-teas-scheduled- 197 resources], doing this as a part of PCEP in a centralized manner, has 198 obvious advantages. 200 The objective of this document is to provide a set of extensions to 201 PCEP to enable LSP scheduling for LSPs creation/deletion under the 202 stateful PCE control, according to traffic services from customers, 203 so as to improve the usage of network resources. 205 4. Architecture Overview 207 4.1. LSP scheduling Overview 209 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for 210 customers' traffic services at its actual usage time, so as to 211 improve the network resource efficient utilization. 213 For stateful PCE supporting LSP scheduling, there are two types of 214 LSP databases used in this document. One is the LSP-DB defined in 215 PCEP [I-D.ietf-pce-stateful-pce], while the other is the scheduled 216 LSP database (SLSP- DB, see section 6). The SLSP-DB records 217 scheduled LSPs and is used as a complementary to the TED and LSP-DB. 218 Note that the two types of LSP databases can be implemented in one 219 physical database or two different databases. This document does not 220 state any preference here. 222 Furthermore, a scheduled TED can be generated from the scheduled LSP 223 DB, LSP DB and TED to indicate the network links and nodes with 224 resource availability information for now and future. The scheduled 225 TED should be maintained by all PCEs within the network environment. 227 In case of implementing PCC-initiated scheduled LSPs, a PCC can 228 request a path computation with LSP information of its scheduling 229 parameters, including the starting time and the duration. Upon 230 receiving the request with the scheduled LSP delegation, a stateful 231 PCE SHALL check the scheduled TED for the network resource 232 availability on network nodes and computes a path for the LSP with 233 the scheduling information. 235 For a multiple PCE environment, in order to coordinate the scheduling 236 request of the LSP path over the network, the PCE needs to send a 237 requestmessage with the path information as well as the scheduled 238 resource for the scheduled LSP to other PCEs within the network, so 239 as to coordinate with their scheduled LSP DBs and scheduled TEDs. 240 Once other PCEs receive the request message with the scheduled LSPs 241 information, if not conflicting with their scheduled LSP DBs, they 242 reply to the requesting PCE with a response message carrying the 243 scheduled LSP and update their scheduled LSP DBs and scheduled TEDs. 244 After the requesting PCE confirms with all PCEs, the PCE SHALL add 245 the scheduled LSP into its scheduled LSP Database and update its 246 scheduled TED. 248 Then the stateful PCE can response to the PCC with the path for the 249 scheduled LSP to notify the result of the computation. However, the 250 PCC should not signal the LSP over the path once receiving these 251 messages since the path is not activated yet until its starting time. 253 Alternatively, the service can also be initiated by PCE itself. In 254 case of implementing PCE-initiated scheduled LSP, the stateful PCE 255 shall check the network resource availability for the traffic and 256 computes a path for the scheduled LSP per request in the same way as 257 in PCC- Initiated mode and then for a multiple PCE network 258 environment, coordinate the scheduled LSP with other PCEs in the 259 network in the same way as in the PCC-Initiated mode. 261 In both modes, for activation of scheduled LSPs, the stateful PCE can 262 send a path computation LSP Initiate (PCInitiate message) with LSP 263 information at its starting time to the PCC for signaling the LSP 264 over the network nodes as defined in [I-D.ietf-pce-pce- initiated- 265 lsp]. Also, in the PCC-initiated mode, with scheduling information 266 ,the PCC can activate the LSP itself by triggering over the path at 267 its starting time as well. When the scheduling usage expires, active 268 stateful PCE SHALL remove the LSP from the network , as well as 269 notify other PCEs to delete the scheduled LSP from the scheduled LSP 270 database. 272 4.2. Support of LSP Scheduling 274 4.2.1. Stateful PCE Capability TLV 276 After a TCP connection for a PCEP session has been established, a PCC 277 and a PCE indicates its ability to support LSP scheduling during the 278 PCEP session establishment phase. For a multiple-PCE environment, 279 the PCEs should also establish PCEP session and indicate its ability 280 to support LSP scheduling among PCEP peers. The Open Object in the 281 Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in [I- 282 D.ietf-pce-stateful-pce]. Note that the STATEFUL- PCE-CAPABILITY TLV 283 is defined in [I-D.ietf-pce-stateful- pce] and updated in [I-D.ietf- 284 pce-pce-initiated-lsp] and [I-D.ietf- pce-stateful-sync- 285 optimizations]. In this document, we define a new flag bit B (SCHED- 286 LSP-CAPABLITY) flag for the STATEFUL- PCE-CAPABILITY TLV to indicate 287 the support of LSP scheduling. 289 B (LSP-SCHEDULING-CAPABILITY - 1 bit): If set to 1 by a PCC, the B 290 Flag indicates that the PCC allows LSP scheduling; if set to 1 by 291 a PCE, the B Flag indicates that the PCE is capable of LSP 292 scheduling. The B bit MUST be set by both PECP peers in order to 293 support LSP scheduling for path computation. 295 4.3. Scheduled LSP creation 297 In order to realize PCC-Initiated scheduled LSP in a centralized 298 network environment, a PCC has to separate the setup of a LSP into 299 two steps. The first step is to request and get a LSP but not signal 300 it over the network. The second step is to signal the scheduled LSP 301 over the LSRs (Labeled switched Router) at its starting time. 303 For PCC-Initiated scheduled LSPs, a PCC can send a path computation 304 request (PCReq) message (see section 4.3.1) or a path computation LSP 305 report (PCRpt) message (see section 4.3.1) including its demanded 306 resources with the scheduling information and delegation to a 307 stateful PCE. 309 Upon receiving the delegation via PCRpt message, the stateful PCE 310 computes the path for the scheduled LSP per its starting time and 311 duration based on the network resource availability stored in 312 scheduled TED (see section 4.1). 314 If a resultant path is found, the stateful PCE will send a PCReq 315 message with the path information as well as the scheduled resource 316 information for the scheduled LSP to other PCEs within the network if 317 there is any, so as to keep their scheduling information 318 synchronized. 320 Once other PCEs receive the PCReq message with the scheduled LSP, if 321 not conflicts with their scheduled LSP DBs, they will reply to the 322 requesting PCE with a PCRep message carrying the scheduled LSP and 323 update their scheduled LSP DBs and scheduled TEDs. After the 324 requesting PCE confirms with all PCEs, the PCE SHALL add the 325 scheduled LSP into its scheduled LSP DB and update its scheduled TED. 326 If conflicts happen or no path available is found, the requesting PCE 327 SHALL return a PCRep message with NO PATH back to the PCC. 329 Otherwise, the stateful PCE will send a PCRep message or PCUpd 330 message (see section 4.3.3) with the path information back to the PCC 331 as confirmation. 333 For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path 334 for the scheduled LSP per requests from network management systems 335 automatically based on the network resource availability in the 336 scheduled TED and coordinate with other PCEs on the scheduled LSP in 337 the same way as in the PCC- Initiated mode. 339 In both modes: 341 o the stateful PCE is required to update its local scheduled LSP DB 342 and scheduled TED with the scheduled LSP. Besides, it shall send 343 a PCReq message with the scheduled LSP to other PCEs within the 344 network, so as to achieve the scheduling traffic engineering 345 information synchronization. 347 o Upon receiving the PCRep message or PCUpd message for scheduled 348 LSP from PCEs with a found path, the PCC knows that it gets a 349 scheduled path for the LSP but not trigger signaling for the LSP 350 setup on LSRs. 352 o In any case, stateful PCE can update the Scheduled LSP parameters 353 on any network events using the PCUpd message to PCC as well as 354 other PCEs. 356 4.3.1. The PCReq message and PCRpt Message 358 After scheduled LSP capability negotiation, for PCC-Initiated mode, a 359 PCC can send a PCReq message or a PCRpt message including the SCHED- 360 LSP- ATTRIBUTE TLV (see section 4.3.4.1) carried in the LSP Object 361 (see section 4.3.4) body to indicate the requested LSP scheduling 362 parameters for a customer's traffic service with the delegation bit 363 set to 1 in LSP Object. The value of requested bandwidth is taken 364 via the existing 'Requested Bandwidth with BANDWIDTH Object- Type as 365 1' defined in [RFC5440]. 367 Meanwhile, for both modes (PCC-Initiated and PCE-Initiated), the 368 delegated PCE shall distribute the scheduling information to other 369 PCEs in the environment by sending a PCReq message with the SCHED- 370 LSP-ATTRIBUTE TLV, as well as the Bandwith Object and RRO for the 371 found path. 373 The definition of the PCReq message and PCRpt message to carry LSP 374 objects (see [I- D.ietf-pce-stateful-pce]) remains unchanged. 376 4.3.2. The PCRep Message 378 To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL compute 379 the path for the scheduled LSP carried on PCReq message based on 380 network resource availability recorded in scheduled TED which is 381 generated from the scheduled LSP-DB and TED and also synchronize the 382 scheduling with other PCEs in the environment by using PCReq message 383 with path and resource information for the scheduled LSP. 385 If no conflict exists, other PCEs SHALL send a PCRep message with the 386 SCHED-LSP-ATTRIBUTE TLV, as well as the Bandwith Object and RRO back 387 to the requesting PCE. 389 If the LSP request can be satisfied and an available path is found, 390 the stateful PCE SHALL send a PCRep Message including the SCHED- LSP- 391 ATTRIBUTE TLV in the LSP Object body, as well as the Bandwith Object 392 and RRO for the found path back to the PCC as a successful 393 acknowledge. 395 4.3.3. The PCUpd Message 397 To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL compute 398 the path for the scheduled LSP carried on PCRpt message based on 399 network resource availability recorded in scheduled TED which is 400 generated from the scheduled LSP-DB, LSP DB and TED. 402 If the request can be satisfied and an available path is found, the 403 stateful PCE SHALL send a PCUpd Message including the SCHED- LSP- 404 ATTRIBUTE TLV in the LSP Object body to the PCC Note that, the 405 stateful PCE can update the Scheduled LSP parameters later as well 406 based on any network events using the same PCUpd message. 408 4.3.4. LSP Object 410 The LSP object is defined in [I-D.ietf-pce-stateful-pce]. This 411 document add an optional SCHED-LSP-ATTRIBUTE TLV. 413 The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates 414 that this LSP is requesting scheduled parameters. The TLV MUST be 415 present in LSP Object for each scheduled LSP carried in the PCReq 416 message, the PCRpt message and the PCUpd message. 418 4.3.4.1. SCHED-LSP-ATTRIBUTE TLV 420 The SCHED-LSP-ATTRIBUTE TLV can be included as an optional TLV within 421 the LSP object for LSP scheduling for the requesting traffic service. 423 This TLV SHOULD be included only if both PCEP peers have set the B 424 (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV 425 carried in open message. 427 The format of the SCHED-LSP-ATTRIBUTE TLV is shown in the following 428 figure: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type | Length | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Starting Time (minutes) | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Duration (minutes) | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 442 The fields in the format are: 444 Starting Time (32 bits): This value in minutes, indicates when the 445 scheduled LSP is used and the corresponding LSP must be setup and 446 activated. At the expiry of this time, the LSP is setup. 447 Otherwise, the LSP is inactive to include the possibility of the 448 resources to be used by other services. The 450 Duration (32 bits): The value in minutes, indicates the duration 451 that the LSP is undertaken by a traffic flow and the corresponding 452 LSP must be up to carry traffic. At the expiry of this time after 453 setup, the LSP is tear down and deleted. 455 Note, that the values of starting time and duration is from the 456 perspective of the PCEP peer that is sending the message, also note 457 the unit of time is minutes, and thus the time spent on transmission 458 on wire can be easily ignored. 460 Editor Note: As described in [I-D.zhuang-teas-scheduled- 461 resources],the encoding of the resource state information could also 462 be expressed as a start time and and end time. Multiple periods, 463 possibly of different lengths, may be associated with one reservation 464 request, and a reservation might repeat on a regular cycle. 466 4.4. Scheduled LSP activation and deletion 468 In PCC-Initiated LSP scheduling, the PCC itself MAY activate the 469 scheduled LSP at the starting time. Alternatively, the stateful PCE 470 MAY activate the scheduled LSP at its scheduled time by send a 471 PCInitiated message. 473 After the scheduled duration expires, the PCE shall send a PCUpd 474 message with R flag set to the PCC to delete the LSP over the path, 475 as well as to other PCEs to remove the scheduled LSP in the 476 databases. Additionally, it shall update its scheduled LSP DB and 477 scheduled TED. 479 Note that, the stateful PCE can update the Scheduled LSP parameters 480 at any time based on any network events using the PCUpd message 481 including SCHED-LSP-ATTRIBUTE TLV in the LSP Object body. 483 5. Security Considerations 485 This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED- LSP- 486 ATTRIBUTE TLV which does not add any new security concerns beyond 487 those discussed in [RFC5440] and [I-D.ietf-pce-stateful-pce]. 489 6. Manageability Consideration 491 6.1. Control of Function and Policy 493 The LSP-Scheduling feature MUST BE controlled per tunnel by the 494 active stateful PCE, the values for parameters like starting time, 495 duration SHOULD BE configurable by customer applications and based on 496 the local policy at PCE. 498 6.2. Information and Data Models 500 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 501 this document. 503 6.3. Liveness Detection and Monitoring 505 Mechanisms defined in this document do not imply any new liveness 506 detection and monitoring requirements in addition to those already 507 listed in [RFC5440]. 509 6.4. Verify Correct Operations 511 Mechanisms defined in this document do not imply any new operation 512 verification requirements in addition to those already listed in 513 [RFC5440]. 515 6.5. Requirements On Other Protocols 517 Mechanisms defined in this document do not imply any new requirements 518 on other protocols. 520 6.6. Impact On Network Operations 522 Mechanisms defined in this document do not have any impact on network 523 operations in addition to those already listed in [RFC5440]. 525 7. IANA Considerations 527 7.1. PCEP TLV Type Indicators 529 This document defines the following new PCEP TLV; IANA is requested 530 to make the following allocations from this registry. 532 Value Meaning Reference 533 TBD SCHED-LSP-ATTRIBUTE This document 535 7.2. LSP-SCHEDULING-CAPABLITY 537 This document requests that a registry is created to manage the Flags 538 field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New 539 values are to be assigned by Standards Action [RFC5226]. Each bit 540 should be tracked with the following qualities: 542 o Bit number (counting from bit 0 as the most significant bit) 544 o Capability description 546 o Defining RFC 548 The following values are defined in this document: 550 Bit Description Reference 551 28 LSP-SCHEDULING-CAPABILITY (B-bit) This document 553 8. Acknowledgments 555 This work has benefited from the discussions of resource scheduling 556 on the mailing list and with Huaimo chen, author of [I-D.chen-pce- 557 tts] since Prague meeting. We gratefully acknowledge the 558 contributions of Huaimo Chen. The authors of this document would 559 also like to thank Rafal Szarecki,Adrian Farrel, Cyril Margaria, Xian 560 Zhang for the review and comments. 562 9. References 564 9.1. Normative References 566 [I-D.dhody-pce-stateful-pce-auto-bandwidth] 567 Dhody, D., Palle, U., Singh, R., Gandhi, R., and L. Fang, 568 "PCEP Extensions for MPLS-TE LSP Automatic Bandwidth 569 Adjustment with Stateful PCE", draft-dhody-pce-stateful- 570 pce-auto-bandwidth-09 (work in progress), November 2016. 572 [I-D.ietf-pce-pce-initiated-lsp] 573 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 574 Extensions for PCE-initiated LSP Setup in a Stateful PCE 575 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 576 progress), July 2016. 578 [I-D.ietf-pce-stateful-pce] 579 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 580 Extensions for Stateful PCE", draft-ietf-pce-stateful- 581 pce-18 (work in progress), December 2016. 583 [I-D.ietf-pce-stateful-sync-optimizations] 584 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 585 and D. Dhody, "Optimizations of Label Switched Path State 586 Synchronization Procedures for a Stateful PCE", draft- 587 ietf-pce-stateful-sync-optimizations-07 (work in 588 progress), December 2016. 590 [I-D.ietf-teas-scheduled-resources] 591 Zhuangyan, Z., Wu, Q., Chen, H., and A. Farrel, 592 "Architecture for Scheduled Use of Resources", draft-ietf- 593 teas-scheduled-resources-01 (work in progress), November 594 2016. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 602 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 603 DOI 10.17487/RFC5440, March 2009, 604 . 606 9.2. Informative References 608 [I-D.ietf-pce-stateful-pce-app] 609 Zhang, X. and I. Minei, "Applicability of a Stateful Path 610 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 611 app-08 (work in progress), October 2016. 613 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 614 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 615 DOI 10.17487/RFC5226, May 2008, 616 . 618 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 619 Hardwick, "Path Computation Element Communication Protocol 620 (PCEP) Management Information Base (MIB) Module", 621 RFC 7420, DOI 10.17487/RFC7420, December 2014, 622 . 624 Appendix A. Scheduled LSP information synchronization 626 As for a stateful PCE, it maintains a database of LSPs (LSP-DB) that 627 are active in the network, so as to reveal the available network 628 resources and place new LSPs more cleverly. 630 With the scheduled LSPs, they are not activated while creation, but 631 should be considered when operating future path computation. Hence, 632 a scheduled LSP Database (SLSP-DB) is suggested to maintain all 633 scheduled LSP information. 635 The information of SLSP-DB MUST be shared and synchronized among all 636 PCEs within the centralized network by using PCReq message, PCRep 637 message with scheduled LSP information. In order to synchronize the 638 scheduled LSP information in SLSP-DB among PCEs, the PCReq message 639 and PCRep Message is used as described in section 4.3.1 and section 640 4.3.2. 642 To achieve the synchronization, the PCE should generate and maintain 643 a scheduled TED based on LSP DB, scheduled LSP DB and TED, which is 644 used to indicate the network resource availability on network nodes 645 for LSP path computation. 647 Appendix B. Contributor Addresses 648 Zitao Wang 649 Huawei 650 101 Software Avenue, Yuhua District 651 Nanjing, Jiangsu 210012 652 China 654 Email: wangzitao@huawei.com 656 Xian Zhang 657 Huawei Technologies 658 Research Area F3-1B, 659 Huawei Industrial Base, 660 Shenzhen, 518129, China 662 Email: zhang.xian@huawei.com 664 Authors' Addresses 666 Yan Zhuang 667 Huawei 668 101 Software Avenue, Yuhua District 669 Nanjing, Jiangsu 210012 670 China 672 Email: zhuangyan.zhuang@huawei.com 674 Qin Wu 675 Huawei 676 101 Software Avenue, Yuhua District 677 Nanjing, Jiangsu 210012 678 China 680 Email: bill.wu@huawei.com 682 Dhruv Dhody 683 Huawei 684 Divyashree Techno Park, Whitefield 685 Bangalore, Karnataka 560066 686 India 688 Email: dhruv.ietf@gmail.com 689 Daniele Ceccarelli 690 Ericsson 691 Via A. Negrone 1/A 692 Genova - Sestri Ponente 693 Italy 695 Email: daniele.ceccarelli@ericsson.com