idnits 2.17.1 draft-zhuang-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2017) is 2586 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 124, but not defined == Missing Reference: 'Ta' is mentioned on line 326, but not defined == Missing Reference: 'Tb' is mentioned on line 326, but not defined == Missing Reference: 'TBD' is mentioned on line 555, but not defined == Unused Reference: 'I-D.dhody-pce-stateful-pce-auto-bandwidth' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-stateful-sync-optimizations' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-scheduled-resources' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-stateful-pce-app' is defined on line 824, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-07) exists of draft-ietf-teas-scheduled-resources-02 ** 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: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). 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: September 28, 2017 D. Dhody 6 Huawei 7 D. Ceccarelli 8 Ericsson 9 March 27, 2017 11 PCEP Extensions for LSP scheduling with stateful PCE 12 draft-zhuang-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 [I.D.ietf-teas-scheduled-resources]. 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 http://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 September 28, 2017. 40 Copyright Notice 42 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . 6 64 4.2.1. LSP Scheduling . . . . . . . . . . . . . . . . . . . 7 65 4.2.2. Periodical LSP Scheduling . . . . . . . . . . . . . . 7 66 4.2.3. Stateful PCE Capability TLV . . . . . . . . . . . . . 8 67 4.3. Scheduled LSP creation . . . . . . . . . . . . . . . . . 9 68 4.3.1. The PCReq message and PCRpt Message . . . . . . . . . 10 69 4.3.2. The PCRep Message . . . . . . . . . . . . . . . . . . 11 70 4.3.3. The PCUpd Message . . . . . . . . . . . . . . . . . . 11 71 4.3.4. LSP Object . . . . . . . . . . . . . . . . . . . . . 12 72 4.4. Scheduled LSP Updates . . . . . . . . . . . . . . . . . . 15 73 4.5. Scheduled LSP activation and deletion . . . . . . . . . . 15 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 6. Manageability Consideration . . . . . . . . . . . . . . . . . 16 76 6.1. Control of Function and Policy . . . . . . . . . . . . . 16 77 6.2. Information and Data Models . . . . . . . . . . . . . . . 16 78 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 16 79 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 16 80 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 16 81 6.6. Impact On Network Operations . . . . . . . . . . . . . . 16 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 17 84 7.2. LSP-SCHEDULING-CAPABLITY . . . . . . . . . . . . . . . . 17 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 9.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Appendix A. Scheduled LSP information synchronization . . . . . 19 90 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 The Path Computation Element Protocol (PCEP) defined in [RFC5440] is 96 used between a Path Computation Element (PCE) and a Path Computation 97 Client (PCC) (or other PCE) to enable computation of Multi-protocol 98 Label Switching (MPLS) for Traffic Engineering Label Switched Path 99 (TE LSP). 101 Further, in order to support use cases described in [I-D.ietf-pce- 102 stateful-pce-app], [I-D.ietf-pce-stateful-pce] specifies a set of 103 extensions to PCEP to enable stateful control of MPLS-TE and GMPLS 104 LSPs via PCEP. 106 Traditionally, the usage and allocation of network resources, 107 especially bandwidth, can be supported by a Network Management System 108 operation such as path pre-establishment. However, this does not 109 provide efficient network usage since the established paths exclude 110 the possibility of being used by other services even when they are 111 not used for undertaking any service. [I-D.ietf-teas-scheduled- 112 resources] then provides a framework that describes and discusses the 113 problem and propose an appropriate architecture for the scheduled 114 reservation of TE resources. 116 With the scheduled reservation of TE resources, it allows network 117 operators to reserve resources in advance according to the agreements 118 with their customers, and allow them to transmit data with scheduling 119 such as specified starting time and duration, for example for a 120 scheduled bulk data replication between data centers. It enables the 121 activation of bandwidth usage at the time the service really being 122 used while letting other services obtain it in spare time. The 123 requirement of scheduled LSP provision is mentioned in [I-D.ietf-pce- 124 stateful-pce-app] and [RFC7399], so as to provide more efficient 125 network resource usage for traffic engineering, which hasn't been 126 solved yet. Also, for deterministic networks, the scheduled LSP can 127 provide a better network resource usage for guaranteed links. This 128 idea can also be applied in segment routing to schedule the network 129 resources over the whole network in a centralized manner as well. 131 With this in mind, this document proposes a set of extensions needed 132 to the stateful PCE, so as to enable LSP scheduling for path 133 computation and LSP setup/deletion based on the actual network 134 resource usage duration of a traffic service. A scheduled LSP is 135 characterized by a starting time and a duration. When the end of the 136 LSP life is reached, it is deleted to free up the resources for other 137 LSP (scheduled or not). 139 2. Conventions used in this document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC2119 [RFC2119]. 145 2.1. Terminology 147 The following terminologies are re-used from existing PCE documents. 149 o Active Stateful PCE [I-D.ietf-pce-stateful-pce]; 151 o Delegation [I-D.ietf-pce-pce-initiated-lsp]; 153 o PCC [RFC5440], [I-D.ietf-pce-stateful-pce]; 155 o PCE [RFC5440], [I-D.ietf-pce-stateful-pce]; 157 o TE LSP [RFC5440], [I-D.ietf-pce-stateful-pce]; 159 o TED [RFC5440], [I-D.ietf-pce-stateful-pce]; 161 o LSP DB [RFC5440], [I-D.ietf-pce-stateful-pce]; 163 In addition, this document defines the following terminologies. 165 Scheduled TE LSP: a LSP with the scheduling attributes,that carries 166 traffic flow demand at an starting time and last for a certain 167 duration. The PCE operates path computation per LSP availability 168 at the required time and duration. 170 Scheduled LSP DB: a database of scheduled LSPs 172 Scheduled TED: Traffic engineering database with the awareness of 173 scheduled resources for TE. This database is generated by the PCE 174 from the information in TED and scheduled LSP DB and allows 175 knowing, at any time, the amount of available resources (does not 176 include failures in the future). 178 Starting time(start-time): This value indicates when the scheduled 179 LSP is used and the corresponding LSP must be setup and active. 180 In other time(i.e., before the starting time or after the starting 181 time plus Duration), the LSP can be inactive to include the 182 possibility of the resources being used by other services. 184 Duration: The value indicates the time duration that the LSP is 185 undertaken by a traffic flow and the corresponding LSP must be 186 setup and active. At the end of which, the LSP is teardown and 187 removed from the data base. 189 3. Motivation and Objectives 191 A stateful PCE can support better efficiency by using LSP scheduling 192 described in the use case of [I-D.ietf-pce-stateful-pce]. This 193 requires the PCE to maintain the scheduled LSPs and their associated 194 resource usage, e.g. bandwidth for Packet-switched network, as well 195 as the ability to trigger signaling for the LSP setup/tear-down at 196 the correct time. 198 Note that existing configuration tools can be used for LSP 199 scheduling, but as highlighted in section 3.1.3 of [I-D.ietf-pce- 200 stateful-pce] as well as discussions in [I-D.ietf-teas-scheduled- 201 resources], doing this as a part of PCEP in a centralized manner, has 202 obvious advantages. 204 The objective of this document is to provide a set of extensions to 205 PCEP to enable LSP scheduling for LSPs creation/deletion under the 206 stateful PCE control, according to traffic services from customers, 207 so as to improve the usage of network resources. 209 4. Architecture Overview 211 4.1. LSP scheduling Overview 213 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for 214 customers' traffic services at its actual usage time, so as to 215 improve the network resource efficient utilization. 217 For stateful PCE supporting LSP scheduling, there are two types of 218 LSP databases used in this document. One is the LSP-DB defined in 219 PCEP [I-D.ietf-pce-stateful-pce], while the other is the scheduled 220 LSP database (SLSP- DB, see section 6). The SLSP-DB records 221 scheduled LSPs and is used as a complementary to the TED and LSP-DB. 222 Note that the two types of LSP databases can be implemented in one 223 physical database or two different databases. This document does not 224 state any preference here. 226 Furthermore, a scheduled TED can be generated from the scheduled LSP 227 DB, LSP DB and TED to indicate the network links and nodes with 228 resource availability information for now and future. The scheduled 229 TED should be maintained by all PCEs within the network environment. 231 In case of implementing PCC-initiated scheduled LSPs, a PCC can 232 request a path computation with LSP information of its scheduling 233 parameters, including the starting time and the duration. Upon 234 receiving the request with the scheduled LSP delegation, a stateful 235 PCE SHALL check the scheduled TED for the network resource 236 availability on network nodes and computes a path for the LSP with 237 the scheduling information. 239 For a multiple PCE environment, in order to coordinate the scheduling 240 request of the LSP path over the network, the PCE needs to send a 241 requestmessage with the path information as well as the scheduled 242 resource for the scheduled LSP to other PCEs within the network, so 243 as to coordinate with their scheduled LSP DBs and scheduled TEDs. 244 Once other PCEs receive the request message with the scheduled LSPs 245 information, if not conflicting with their scheduled LSP DBs, they 246 reply to the requesting PCE with a response message carrying the 247 scheduled LSP and update their scheduled LSP DBs and scheduled TEDs. 248 After the requesting PCE confirms with all PCEs, the PCE SHALL add 249 the scheduled LSP into its scheduled LSP Database and update its 250 scheduled TED. 252 Then the stateful PCE can response to the PCC with the path for the 253 scheduled LSP to notify the result of the computation. However, the 254 PCC should not signal the LSP over the path once receiving these 255 messages since the path is not activated yet until its starting time. 257 Alternatively, the service can also be initiated by PCE itself. In 258 case of implementing PCE-initiated scheduled LSP, the stateful PCE 259 shall check the network resource availability for the traffic and 260 computes a path for the scheduled LSP per request in the same way as 261 in PCC- Initiated mode and then for a multiple PCE network 262 environment, coordinate the scheduled LSP with other PCEs in the 263 network in the same way as in the PCC-Initiated mode. 265 In both modes, for activation of scheduled LSPs, the stateful PCE can 266 send a path computation LSP Initiate (PCInitiate message) with LSP 267 information at its starting time to the PCC for signaling the LSP 268 over the network nodes as defined in [I-D.ietf-pce-pce- initiated- 269 lsp]. Also, in the PCC-initiated mode, with scheduling information 270 ,the PCC can activate the LSP itself by triggering over the path at 271 its starting time as well. When the scheduling usage expires, active 272 stateful PCE SHALL remove the LSP from the network , as well as 273 notify other PCEs to delete the scheduled LSP from the scheduled LSP 274 database. 276 4.2. Support of LSP Scheduling 277 4.2.1. LSP Scheduling 279 For a scheduled LSP, a user configures it with an arbitrary 280 scheduling duration time Ta to time Tb, which may be represented as 281 [Ta, Tb]. 283 When an LSP is configured with arbitrary scheduling duration [Ta, 284 Tb], a path satisfying the constraints for the LSP in the scheduling 285 duration is computed and the LSP along the path is set up to carry 286 traffic from time Ta to time Tb. 288 4.2.2. Periodical LSP Scheduling 290 In addition to LSP Scheduling at an arbitrary time period, there are 291 also periodical LSP Scheduling. 293 A periodical LSP Scheduling represents Scheduling LSP every time 294 interval. It has a scheduling duration such as [Ta, Tb], a number of 295 repeats such as 10 (repeats 10 times), and a repeat cycle/time 296 interval such as a week (repeats every week). The scheduling 297 interval: "[Ta, Tb] repeats n times with repeat cycle C" represents 298 n+1 scheduling intervals as follows: 300 [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC] 302 When an LSP is configured with a scheduling interval such as "[Ta, 303 Tb] repeats 10 times with a repeat cycle a week" (representing 11 304 scheduling intervals), a path satisfying the constraints for the LSP 305 in each of the scheduling intervals represented by the periodical 306 scheduling interval is computed and the LSP along the path is set up 307 to carry traffic in each of the scheduling intervals. 309 4.2.2.1. Elastic Time LSP Scheduling 311 In addition to the basic LSP scheduling at an arbitrary time period, 312 another option is elastic time intervals, which is represented as 313 within -P and Q, where P and Q is an amount of time such as 300 314 seconds. P is called elastic range lower bound and Q is called 315 elastic range upper bound. 317 For a simple time interval such as [Ta, Tb] with an elastic range, 318 elastic time interval: "[Ta, Tb] within -P and Q" means a time period 319 from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb 320 may be shifted the same X. 322 When an LSP is configured with elastic time interval "[Ta, Tb] within 323 -P and Q", a path is computed such that the path satisfies the 324 constraints for the LSP in the time period from (Ta+X) to (Tb+X) 325 and |X| is the minimum value from 0 to max(P, Q). That is that 326 [Ta+X, Tb+X] is the time interval closest to time interval [Ta, Tb] 327 within the elastic range. The LSP along the path is set up to carry 328 traffic in the time period from (Ta+X) to (Tb+X). 330 Similarly, for a recurrent time interval with an elastic range, 331 elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C 332 within -P and Q" represents n+1 simple elastic time intervals as 333 follows: 335 [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn] 336 where -P <= Xi <= Q, i = 0, 1, 2, ..., n. 338 If a user wants to keep the same repeat cycle between any two 339 adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n 340 times with repeat cycle C within -P and Q SYNC" may be used, which 341 represents n+1 simple elastic time intervals as follows: 343 [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X] 344 where -P <= X <= Q. 346 4.2.2.2. Graceful Periods 348 Besides the stated time scheduling, a user may want to have some 349 graceful periods for each or some of the time intervals for the LSP. 350 Two graceful periods may be configured for a time interval. One is 351 the graceful period before the time interval, called grace-before, 352 which extends the lifetime of the LSP for grace-before (such as 30 353 seconds) before the time interval. The other is the one after the 354 time interval, called grace-after, which extends the lifetime of the 355 LSP for grace-after (such as 60 seconds) after the time interval. 357 When an LSP is configured with a simple time interval such as [Ta, 358 Tb] with graceful periods such as grace-before GB and grace-after GA, 359 a path is computed such that the path satisfies the constraints for 360 the LSP in the time period from Ta to Tb. The LSP along the path is 361 set up to carry traffic in the time period from (Ta-GB) to (Tb+GA). 362 During graceful periods from (Ta-GB) to Ta and from Tb to (Tb+GA), 363 the LSP is up to carry traffic (maybe in best effort). 365 4.2.3. Stateful PCE Capability TLV 367 After a TCP connection for a PCEP session has been established, a PCC 368 and a PCE indicates its ability to support LSP scheduling during the 369 PCEP session establishment phase. For a multiple-PCE environment, 370 the PCEs should also establish PCEP session and indicate its ability 371 to support LSP scheduling among PCEP peers. The Open Object in the 372 Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in [I- 373 D.ietf-pce-stateful-pce]. Note that the STATEFUL- PCE-CAPABILITY TLV 374 is defined in [I-D.ietf-pce-stateful- pce] and updated in [I-D.ietf- 375 pce-pce-initiated-lsp] and [I-D.ietf- pce-stateful-sync- 376 optimizations]. In this document, we define a new flag bit B (SCHED- 377 LSP-CAPABLITY) flag for the STATEFUL- PCE-CAPABILITY TLV to indicate 378 the support of LSP scheduling and another flag bit PD (PD-LSP- 379 CAPABLITY) to indicate the support of LSP periodical scheduling. 381 B (LSP-SCHEDULING-CAPABILITY - 1 bit): If set to 1 by a PCC, the B 382 Flag indicates that the PCC allows LSP scheduling; if set to 1 by 383 a PCE, the B Flag indicates that the PCE is capable of LSP 384 scheduling. The B bit MUST be set by both PCEP peers in order to 385 support LSP scheduling for path computation. 387 PD (PD-LSP-CAPABLITY - 1 bit): If set to 1 by a PCC, the PD Flag 388 indicates that the PCC allows LSP scheduling periodically; if set 389 to 1 by a PCE, the PD Flag indicates that the PCE is capable of 390 periodical LSP scheduling. The PD bit MUST be set by both PCEP 391 peers in order to support periodical LSP scheduling for path 392 computation. 394 4.3. Scheduled LSP creation 396 In order to realize PCC-Initiated scheduled LSP in a centralized 397 network environment, a PCC has to separate the setup of a LSP into 398 two steps. The first step is to request and get a LSP but not signal 399 it over the network. The second step is to signal the scheduled LSP 400 over the LSRs (Labeled switched Router) at its starting time. 402 For PCC-Initiated scheduled LSPs, a PCC can send a path computation 403 request (PCReq) message (see section 4.3.1) or a path computation LSP 404 report (PCRpt) message (see section 4.3.1) including its demanded 405 resources with the scheduling information and delegation to a 406 stateful PCE. 408 Upon receiving the delegation via PCRpt message, the stateful PCE 409 computes the path for the scheduled LSP per its starting time and 410 duration based on the network resource availability stored in 411 scheduled TED (see section 4.1). 413 If a resultant path is found, the stateful PCE will send a PCReq 414 message with the path information as well as the scheduled resource 415 information for the scheduled LSP to other PCEs within the network if 416 there is any, so as to keep their scheduling information 417 synchronized. 419 Once other PCEs receive the PCReq message with the scheduled LSP, if 420 not conflicts with their scheduled LSP DBs, they will reply to the 421 requesting PCE with a PCRep message carrying the scheduled LSP and 422 update their scheduled LSP DBs and scheduled TEDs. After the 423 requesting PCE confirms with all PCEs, the PCE SHALL add the 424 scheduled LSP into its scheduled LSP DB and update its scheduled TED. 425 If conflicts happen or no path available is found, the requesting PCE 426 SHALL return a PCRep message with NO PATH back to the PCC. 427 Otherwise, the stateful PCE will send a PCRep message or PCUpd 428 message (see section 4.3.3) with the path information back to the PCC 429 as confirmation. 431 For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path 432 for the scheduled LSP per requests from network management systems 433 automatically based on the network resource availability in the 434 scheduled TED and coordinate with other PCEs on the scheduled LSP in 435 the same way as in the PCC- Initiated mode. 437 In both modes: 439 o the stateful PCE is required to update its local scheduled LSP DB 440 and scheduled TED with the scheduled LSP. Besides, it shall send 441 a PCReq message with the scheduled LSP to other PCEs within the 442 network, so as to achieve the scheduling traffic engineering 443 information synchronization. 445 o Upon receiving the PCRep message or PCUpd message for scheduled 446 LSP from PCEs with a found path, the PCC knows that it gets a 447 scheduled path for the LSP but not trigger signaling for the LSP 448 setup on LSRs. 450 o In any case, stateful PCE can update the Scheduled LSP parameters 451 on any network events using the PCUpd message to PCC as well as 452 other PCEs. 454 o When it is time (i.e., at the start time) for the LSP to be set 455 up, the delegated PCE sends a PCEP Initiate request to the head 456 end LSR providing the path to be signaled. 458 4.3.1. The PCReq message and PCRpt Message 460 After scheduled LSP capability negotiation, for PCC-Initiated mode, a 461 PCC can send a PCReq message or a PCRpt message including the SCHED- 462 LSP- ATTRIBUTE TLV (see section 4.3.4.1) or SCHED-PD-LSP-ATTRIBUTE 463 TLV (see section 4.3.4.2) carried in the LSP Object (see section 464 4.3.4) body to indicate the requested LSP scheduling parameters for a 465 customer's traffic service with the delegation bit set to 1 in LSP 466 Object. The value of requested bandwidth is taken via the existing 467 'Requested Bandwidth with BANDWIDTH Object- Type as 1' defined in 468 [RFC5440]. 470 Meanwhile, for both modes (PCC-Initiated and PCE-Initiated), the 471 delegated PCE shall distribute the scheduling information to other 472 PCEs in the environment by sending a PCReq message with the SCHED- 473 LSP-ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV, as well as the 474 Bandwith Object and RRO for the found path. 476 The definition of the PCReq message and PCRpt message to carry LSP 477 objects (see [I- D.ietf-pce-stateful-pce]) remains unchanged. 479 4.3.2. The PCRep Message 481 To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL compute 482 the path for the scheduled LSP carried on PCReq message based on 483 network resource availability recorded in scheduled TED which is 484 generated from the scheduled LSP-DB and TED and also synchronize the 485 scheduling with other PCEs in the environment by using PCReq message 486 with path and resource information for the scheduled LSP. 488 If no conflict exists, other PCEs SHALL send a PCRep message with the 489 SCHED-LSP-ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV, as well as the 490 Bandwith Object and RRO back to the requesting PCE. 492 If the LSP request can be satisfied and an available path is found, 493 the stateful PCE SHALL send a PCRep Message including the SCHED- LSP- 494 ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV in the LSP Object body, 495 as well as the Bandwith Object and RRO for the found path back to the 496 PCC as a successful acknowledge. 498 If conflicts happen or no path available is found, the requesting PCE 499 SHALL return a PCRep message with NO PATH back to the PCC. 501 4.3.3. The PCUpd Message 503 To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL compute 504 the path for the scheduled LSP carried on PCRpt message based on 505 network resource availability recorded in scheduled TED which is 506 generated from the scheduled LSP-DB, LSP DB and TED. 508 If the request can be satisfied and an available path is found, the 509 stateful PCE SHALL send a PCUpd Message including the SCHED- LSP- 510 ATTRIBUTE TLV or SCHED-PD-LSP-ATTRIBUTE TLV in the LSP Object body to 511 the PCC Note that, the stateful PCE can update the Scheduled LSP 512 parameters later as well based on any network events using the same 513 PCUpd message. 515 If conflicts happen or no path available is found, the requesting PCE 516 SHALL return a PCUpd message with ERO empty. 518 4.3.4. LSP Object 520 The LSP object is defined in [I-D.ietf-pce-stateful-pce]. This 521 document add an optional SCHED-LSP-ATTRIBUTE TLV for normal LSP 522 scheduling and an optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical 523 LSP scheduling. 525 The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates 526 that this LSP is requesting scheduled parameters while the SCHED-PD- 527 LSP-ATTRIBUTE TLV indicates that this scheduled LSP is periodical. 528 The scheduled LSP attribute TLV MUST be present in LSP Object for 529 each scheduled LSP carried in the PCReq message, the PCRpt message 530 and the PCUpd message. For periodical LSPs, the SCHED-PD-LSP- 531 ATTRIBUTE TLV can be used in LSP Object. 533 4.3.4.1. SCHED-LSP-ATTRIBUTE TLV 535 The SCHED-LSP-ATTRIBUTE TLV can be included as an optional TLV within 536 the LSP object for LSP scheduling for the requesting traffic service. 538 This TLV SHOULD be included only if both PCEP peers have set the B 539 (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV 540 carried in open message. 542 The format of the SCHED-LSP-ATTRIBUTE TLV is shown in the following 543 figure: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Type | Length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Start-Time (minutes) | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Duration (minutes) | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 557 The fields in the format are: 559 Start-Time (32 bits): This value in minutes, indicates when the 560 scheduled LSP is used to carry traffic and the corresponding LSP 561 must be setup and activated. 563 Duration (32 bits): The value in minutes, indicates the duration 564 that the LSP is undertaken by a traffic flow and the corresponding 565 LSP must be up to carry traffic. At the expiry of this duration, 566 the LSP is tear down and deleted. 568 Note, that the values of starting time and duration is from the 569 perspective of the PCEP peer that is sending the message, also note 570 the unit of time is minutes, and thus the time spent on transmission 571 on wire can be easily ignored. 573 Editor Note 1: As described in [I-D.zhuang-teas-scheduled- 574 resources],the encoding of the resource state information could also 575 be expressed as a start time and end time. Multiple periods, 576 possibly of different lengths, may be associated with one reservation 577 request, and a reservation might repeat on a regular cycle. 579 Editor Notes2: The time stated in this section and in section 4.3.4.2 580 may be a relative time or an absolute time, which need more 581 discussions. 583 Editor Note3: the elastic interval and graceful interval may also be 584 applied to the random LSP scheduling which need more discussion. 586 4.3.4.2. SCHED-PD-LSP-ATTRIBUTE TLV 588 The periodical LSP is a special case of LSP scheduling. The traffic 589 service happens in a series of repeated time intervals. The SCHED- 590 PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the 591 LSP object for this periodical LSP scheduling. 593 This TLV SHOULD be included only if both PCEP peers have set the B 594 (LSP-SCHEDULING-CAPABILITY bit) and PD (PD-LSP-CAPABLITY bit) in 595 STATEFUL-PCE-CAPABILITY TLV carried in open message. 597 The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in the 598 following figure: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type (3) | Length | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Start-Time | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Duration | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Repeat-time-length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Options | Number-repeats | Reserved (0) | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | GrB | GrA | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Elastic-Lower-Bound | Elastic-Upper-Bound | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Start-Time (32 bits): This value in minutes, indicates the time when 619 the scheduled LSP is used to carry traffic and the corresponding 620 LSP must be setup and activated. 622 Duration (32 bits): The value in minutes, indicates the duration 623 that the LSP is undertaken by a traffic flow and the corresponding 624 LSP must be up to carry traffic. 626 Repeat-time-length: The time length in minutes after which LSP 627 starts to carry traffic again for (Start Time-End Time). 629 Options: Indicates a way to repeat. 631 Options = 1: repeat every day; 633 Options = 2: repeat every week; 635 Options = 3: repeat every month; 637 Options = 4: repeat every year; 639 Options = 5: repeat every Repeat-time-length. 641 Number-repeats: The number of repeats. In each of repeats, LSP 642 carries traffic. 644 In addition, it contains an non zero grace-before and grace-after if 645 graceful periods are configured. It includes an non zero elastic 646 range lower bound and upper bound if there is an elastic range 647 configured. 649 o GrB (Grace-Before): The graceful period time length in seconds 650 before the starting time. 652 o GrA (Grace-After): The graceful period time length in seconds 653 after time interval [starting time, starting time + duration]. 655 o Elastic-Lower-Bound: The maximum amount of time in seconds that 656 time interval can shift to lower/left. 658 o Elastic-Upper-Bound: The maximum amount of time in seconds that 659 time interval can shift to upper/right. 661 4.4. Scheduled LSP Updates 663 After a scheduled LSP is configured, a user may change its parameters 664 including the requested time as well as the bandwidth. 666 In PCC-Initiated case, the PCC can send a PCRpt message for the 667 scheduled LSP with updated bandwidth as well as scheduled information 668 included in the SCHED-LSP-ATTRIBUTE TLV (see section 4.3.4.1) or 669 SCHED-PD-LSP-ATTRIBUTE TLV carried in the LSP Object. The PCE should 670 calculate the updated resources and synchronized with other PCEs. If 671 the updates can be satisfied, PCE shall return a PCUpd message to PCC 672 as described in section 4.3.3. If the requested updates cannot be 673 met, PCE shall return a PCUpd message with the original reserved 674 attributes carried in the LSP Object. 676 The stateful PCE can update the Scheduled LSP parameters to other 677 PCEs and the requested PCC at any time based on any network events 678 using the PCUpd message including SCHED-LSP-ATTRIBUTE TLV or SCHED- 679 PD-LSP-ATTRIBUTE TLV in the LSP Object body. 681 4.5. Scheduled LSP activation and deletion 683 In PCC-Initiated LSP scheduling, the PCC itself MAY activate the 684 scheduled LSP at the starting time. Alternatively, the stateful PCE 685 MAY activate the scheduled LSP at its scheduled time by send a 686 PCInitiated message. 688 After the scheduled duration expires, the PCE shall send a PCUpd 689 message with R flag set to the PCC to delete the LSP over the path, 690 as well as to other PCEs to remove the scheduled LSP in the 691 databases. Additionally, it shall update its scheduled LSP DB and 692 scheduled TED. 694 Note that, the stateful PCE can update the Scheduled LSP parameters 695 at any time based on any network events using the PCUpd message 696 including SCHED-LSP-ATTRIBUTE TLV in the LSP Object body. 698 5. Security Considerations 700 This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED- LSP- 701 ATTRIBUTE TLV which does not add any new security concerns beyond 702 those discussed in [RFC5440] and [I-D.ietf-pce-stateful-pce]. 704 6. Manageability Consideration 706 6.1. Control of Function and Policy 708 The LSP-Scheduling feature MUST BE controlled per tunnel by the 709 active stateful PCE, the values for parameters like starting time, 710 duration SHOULD BE configurable by customer applications and based on 711 the local policy at PCE. 713 6.2. Information and Data Models 715 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 716 this document. 718 6.3. Liveness Detection and Monitoring 720 Mechanisms defined in this document do not imply any new liveness 721 detection and monitoring requirements in addition to those already 722 listed in [RFC5440]. 724 6.4. Verify Correct Operations 726 Mechanisms defined in this document do not imply any new operation 727 verification requirements in addition to those already listed in 728 [RFC5440]. 730 6.5. Requirements On Other Protocols 732 Mechanisms defined in this document do not imply any new requirements 733 on other protocols. 735 6.6. Impact On Network Operations 737 Mechanisms defined in this document do not have any impact on network 738 operations in addition to those already listed in [RFC5440]. 740 7. IANA Considerations 741 7.1. PCEP TLV Type Indicators 743 This document defines the following new PCEP TLV; IANA is requested 744 to make the following allocations from this registry. 746 Value Meaning Reference 747 TBD SCHED-LSP-ATTRIBUTE This document 748 TBD SCHED-PD-LSP-ATTRIBUTE This document 750 7.2. LSP-SCHEDULING-CAPABLITY 752 This document requests that a registry is created to manage the Flags 753 field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New 754 values are to be assigned by Standards Action [RFC5226]. Each bit 755 should be tracked with the following qualities: 757 o Bit number (counting from bit 0 as the most significant bit) 759 o Capability description 761 o Defining RFC 763 The following values are defined in this document: 765 Bit Description Reference 766 28 LSP-SCHEDULING-CAPABILITY (B-bit) This document 767 29 PD-LSP-CAPABLITY (PD-bit) This document 769 8. Acknowledgments 771 This work has benefited from the discussions of resource scheduling 772 on the mailing list and with Huaimo chen, author of [I-D.chen-pce- 773 tts] since Prague meeting. We gratefully acknowledge the 774 contributions of Huaimo Chen. The authors of this document would 775 also like to thank Rafal Szarecki,Adrian Farrel, Cyril Margaria, Xian 776 Zhang for the review and comments. 778 9. References 780 9.1. Normative References 782 [I-D.dhody-pce-stateful-pce-auto-bandwidth] 783 Dhody, D., Palle, U., Singh, R., Gandhi, R., and L. Fang, 784 "PCEP Extensions for MPLS-TE LSP Automatic Bandwidth 785 Adjustment with Stateful PCE", draft-dhody-pce-stateful- 786 pce-auto-bandwidth-09 (work in progress), November 2016. 788 [I-D.ietf-pce-pce-initiated-lsp] 789 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 790 Extensions for PCE-initiated LSP Setup in a Stateful PCE 791 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 792 progress), March 2017. 794 [I-D.ietf-pce-stateful-pce] 795 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 796 Extensions for Stateful PCE", draft-ietf-pce-stateful- 797 pce-18 (work in progress), December 2016. 799 [I-D.ietf-pce-stateful-sync-optimizations] 800 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 801 and D. Dhody, "Optimizations of Label Switched Path State 802 Synchronization Procedures for a Stateful PCE", draft- 803 ietf-pce-stateful-sync-optimizations-10 (work in 804 progress), March 2017. 806 [I-D.ietf-teas-scheduled-resources] 807 Zhuangyan, Z., Wu, Q., Chen, H., and A. Farrel, 808 "Architecture for Scheduled Use of Resources", draft-ietf- 809 teas-scheduled-resources-02 (work in progress), January 810 2017. 812 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, 814 DOI 10.17487/RFC2119, March 1997, 815 . 817 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 818 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 819 DOI 10.17487/RFC5440, March 2009, 820 . 822 9.2. Informative References 824 [I-D.ietf-pce-stateful-pce-app] 825 Zhang, X. and I. Minei, "Applicability of a Stateful Path 826 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 827 app-08 (work in progress), October 2016. 829 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 830 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 831 DOI 10.17487/RFC5226, May 2008, 832 . 834 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 835 Hardwick, "Path Computation Element Communication Protocol 836 (PCEP) Management Information Base (MIB) Module", 837 RFC 7420, DOI 10.17487/RFC7420, December 2014, 838 . 840 Appendix A. Scheduled LSP information synchronization 842 As for a stateful PCE, it maintains a database of LSPs (LSP-DB) that 843 are active in the network, so as to reveal the available network 844 resources and place new LSPs more cleverly. 846 With the scheduled LSPs, they are not activated while creation, but 847 should be considered when operating future path computation. Hence, 848 a scheduled LSP Database (SLSP-DB) is suggested to maintain all 849 scheduled LSP information. 851 The information of SLSP-DB MUST be shared and synchronized among all 852 PCEs within the centralized network by using PCReq message, PCRep 853 message with scheduled LSP information. In order to synchronize the 854 scheduled LSP information in SLSP-DB among PCEs, the PCReq message 855 and PCRep Message is used as described in section 4.3.1 and section 856 4.3.2. 858 To achieve the synchronization, the PCE should generate and maintain 859 a scheduled TED based on LSP DB, scheduled LSP DB and TED, which is 860 used to indicate the network resource availability on network nodes 861 for LSP path computation. 863 Appendix B. Contributor Addresses 864 Xufeng Liu 865 Ericsson 866 USA 867 Email: xliu@kuatrotech.com 869 Mehmet Toy 870 Verizon 871 USA 872 Email: mehmet.toy@verizon.com 874 Vic Liu 875 China Mobile 876 No.32 Xuanwumen West Street, Xicheng District 877 Beijing, 100053 878 China 879 Email: liu.cmri@gmail.com 881 Lei Liu 882 Fujitsu 883 USA 884 Email: lliu@us.fujitsu.com 886 Khuzema Pithewan 887 Infinera 888 Email: kpithewan@infinera.com 890 Zitao Wang 891 Huawei 892 101 Software Avenue, Yuhua District 893 Nanjing, Jiangsu 210012 894 China 896 Email: wangzitao@huawei.com 898 Xian Zhang 899 Huawei Technologies 900 Research Area F3-1B, 901 Huawei Industrial Base, 902 Shenzhen, 518129, China 904 Email: zhang.xian@huawei.com 906 Authors' Addresses 907 Huaimo Chen (editor) 908 Huawei 909 Boston, MA 910 USA 912 Email: huaimo.chen@huawei.com 914 Yan Zhuang (editor) 915 Huawei 916 101 Software Avenue, Yuhua District 917 Nanjing, Jiangsu 210012 918 China 920 Email: zhuangyan.zhuang@huawei.com 922 Qin Wu 923 Huawei 924 101 Software Avenue, Yuhua District 925 Nanjing, Jiangsu 210012 926 China 928 Email: bill.wu@huawei.com 930 Dhruv Dhody 931 Huawei 932 Divyashree Techno Park, Whitefield 933 Bangalore, Karnataka 560066 934 India 936 Email: dhruv.ietf@gmail.com 938 Daniele Ceccarelli 939 Ericsson 940 Via A. Negrone 1/A 941 Genova - Sestri Ponente 942 Italy 944 Email: daniele.ceccarelli@ericsson.com