idnits 2.17.1 draft-chen-pce-tts-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 29, 2016) is 2675 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 216, but not defined == Missing Reference: 'Tb' is mentioned on line 216, but not defined == Missing Reference: 'Start-time' is mentioned on line 597, but not defined == Missing Reference: 'End-time' is mentioned on line 597, but not defined == Missing Reference: 'T0' is mentioned on line 974, but not defined == Missing Reference: 'B0' is mentioned on line 1009, but not defined == Missing Reference: 'T1' is mentioned on line 974, but not defined == Missing Reference: 'B1' is mentioned on line 1009, but not defined == Missing Reference: 'T2' is mentioned on line 974, but not defined == Missing Reference: 'B2' is mentioned on line 1009, but not defined == Missing Reference: 'T3' is mentioned on line 974, but not defined == Missing Reference: 'B3' is mentioned on line 1009, but not defined == Missing Reference: 'P0' is mentioned on line 1009, but not defined == Missing Reference: 'P1' is mentioned on line 1009, but not defined == Missing Reference: 'P2' is mentioned on line 1009, but not defined == Missing Reference: 'P3' is mentioned on line 1009, but not defined == Unused Reference: 'RFC2119' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 1053, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-stateful-pce' is defined on line 1065, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-pce-initiated-lsp' is defined on line 1071, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1090, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 Summary: 1 error (**), 0 flaws (~~), 27 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track X. Liu 5 Expires: July 2, 2017 Ericsson 6 M. Toy 7 Verizon 8 V. Liu 9 China Mobile 10 L. Liu 11 Fujitsu 12 K. Pithewan 13 Infinera 14 December 29, 2016 16 Extensions to PCEP for Temporal LSP 17 draft-chen-pce-tts-05.txt 19 Abstract 21 For existing MPLS LSP tunnel services, it is hard for LSP tunnels to 22 be booked in advance. In addition, once an LSP tunnel is set up, it 23 is assumed to consume a certain amount of resources such as link 24 bandwidth forever. 26 Temporal LSP tunnel services (TTS) provides an easy way for us to 27 book temporal LSP tunnels in advance. More importantly, a temporal 28 LSP is an LSP with one or more time intervals and it is assumed to 29 consume the resources and carry traffic only in these time intervals. 31 This document specifies extensions to PCEP for computing a path for a 32 temporal LSP, initiating and maintaining a temporal LSP with a 33 sequence of time intervals, during each of which the LSP carries 34 traffic. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on July 2, 2017. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Conventions Used in This Document . . . . . . . . . . . . . . 5 73 4. Operations Overview . . . . . . . . . . . . . . . . . . . . . 5 74 4.1. Simple Time Interval . . . . . . . . . . . . . . . . . . . 5 75 4.2. Recurrent Time Interval . . . . . . . . . . . . . . . . . 5 76 4.3. Elastic Time Interval . . . . . . . . . . . . . . . . . . 6 77 4.4. Changes to Time Interval . . . . . . . . . . . . . . . . . 6 78 4.5. Graceful Periods . . . . . . . . . . . . . . . . . . . . . 7 79 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 8 80 5.1. Capability TLV in Existing PCE Discovery Protocol . . . . 8 81 5.2. Open Message Extension . . . . . . . . . . . . . . . . . . 10 82 5.3. RP Object Extension . . . . . . . . . . . . . . . . . . . 10 83 5.4. TIME INTERVAL Object . . . . . . . . . . . . . . . . . . . 11 84 5.4.1. Absolute Time Interval TLV . . . . . . . . . . . . . . 11 85 5.4.2. Relative Time Interval TLV . . . . . . . . . . . . . . 13 86 5.4.3. Recurrent Absolute Time Interval TLV . . . . . . . . . 14 87 5.4.4. Recurrent Relative Time Interval TLV . . . . . . . . . 16 88 5.5. Messages for Temporal LSP . . . . . . . . . . . . . . . . 17 89 5.5.1. Messages between PCE and PCC on Ingress . . . . . . . 18 90 5.5.2. Messages between two PCEs . . . . . . . . . . . . . . 19 91 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 6.1. Creating a Temporal LSP . . . . . . . . . . . . . . . . . 21 93 6.2. Deleting a Temporal LSP . . . . . . . . . . . . . . . . . 21 94 7. Considerations on TED . . . . . . . . . . . . . . . . . . . . 22 95 7.1. TE Representation in Absolute Time . . . . . . . . . . . . 23 96 7.2. TE Representation in Relative Time . . . . . . . . . . . . 23 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 99 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 105 1. Introduction 107 Once an existing multiprotocol label switching (MPLS) traffic 108 engineering (TE) label switched path (LSP) is set up, it is assumed 109 to carry traffic forever until it is down. When an MPLS TE LSP 110 tunnel is up, it is assumed that the LSP consumes its reserved 111 network resources forever even though the LSP may only use network 112 resources during some period of time. As a result, the network 113 resources are not used efficiently. Moreover, a tunnel service can 114 not be reserved or booked in advance for a period of time or a 115 sequence of time periods. 117 Temporal LSP tunnel services (TTS) provides an easy way for us to 118 book temporal LSP tunnels in advance. More importantly, a temporal 119 LSP is an LSP with one or more time intervals and it is assumed to 120 consume the resources and carry traffic only in each of these time 121 intervals. 123 This document specifies extensions to PCEP for computing a path for a 124 temporal LSP, initiating and maintaining a temporal LSP with a period 125 of time called a time interval or a sequence of time intervals. It 126 is assumed that the LSP carries traffic during this time interval or 127 each of these time intervals. Thus the network resources are 128 efficiently used. More importantly, some new services can be 129 provided. For example, a consumer can book a tunnel service in 130 advance for a given time interval or a sequence of time intervals. 131 Tunnel services may be scheduled. 133 2. Terminology 135 A Time Interval: a time period from time Ta to time Tb. 137 LSP: Label Switched Path. An LSP is a P2P (point-to-point) LSP or a 138 P2MP (point-to-multipoiint) LSP. 140 LSP with a time interval: LSP that carries traffic in the time 141 interval. 143 LSP with a sequence of time intervals: LSP that carries traffic in 144 each of the time intervals. 146 Temporal LSP: LSP with a time interval or LSP with a sequence of time 147 intervals. 149 TED: Traffic Engineering Database. 151 CSPF: Constrained Shortest Path First. 153 LER: Label Edge Router. 155 This document uses terminologies defined in RFC5440. 157 3. Conventions Used in This Document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC2119. 163 4. Operations Overview 165 This section briefly describes some operations on a temporal LSP. 167 4.1. Simple Time Interval 169 For a temporal LSP, a user configures it with a time interval or a 170 sequence of time intervals. A simple time interval is a time period 171 from time Ta to time Tb, which may be represented as [Ta, Tb]. 173 When an LSP is configured with time interval [Ta, Tb], a path 174 satisfying the constraints for the LSP in the time interval is 175 computed and the LSP along the path is set up to carry traffic from 176 time Ta to time Tb. 178 In addition to simple time intervals, there are recurrent time 179 intervals and elastic time intervals. Sometimes a simple time 180 interval is called a time interval. 182 4.2. Recurrent Time Interval 184 A recurrent time interval represents a series of repeated simple time 185 intervals. It has a simple time interval such as [Ta, Tb], a number 186 of repeats such as 10 (repeats 10 times), and a repeat cycle/time 187 such as a week (repeats every week). The recurrent time interval: 188 "[Ta, Tb] repeats n times with repeat cycle C" represents n+1 simple 189 time intervals as follows: 191 [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC] 193 When an LSP is configured with a recurrent time interval such as 194 "[Ta, Tb] repeats 10 times with a repeat cycle a week" (representing 195 11 simple time intervals), a path satisfying the constraints for the 196 LSP in each of the simple time intervals represented by the recurrent 197 time interval is computed and the LSP along the path is set up to 198 carry traffic in each of the simple time intervals. 200 4.3. Elastic Time Interval 202 An elastic time interval is a time interval with an elastic range, 203 which is represented as within -P and Q, where P and Q is an amount 204 of time such as 300 seconds. P is called elastic range lower bound 205 and Q is called elastic range upper bound. 207 For a simple time interval such as [Ta, Tb] with an elastic range, 208 elastic time interval: "[Ta, Tb] within -P and Q" means a time period 209 from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb 210 may be shifted the same X. 212 When an LSP is configured with elastic time interval "[Ta, Tb] within 213 -P and Q", a path is computed such that the path satisfies the 214 constraints for the LSP in the time period from (Ta+X) to (Tb+X) and 215 |X| is the minimum value from 0 to max(P, Q). That is that [Ta+X, 216 Tb+X] is the time interval closest to time interval [Ta, Tb] within 217 the elastic range. The LSP along the path is set up to carry traffic 218 in the time period from (Ta+X) to (Tb+X). 220 Similarly, for a recurrent time interval with an elastic range, 221 elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C 222 within -P and Q" represents n+1 simple elastic time intervals as 223 follows: 225 [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn] 227 where -P <= Xi <= Q, i = 0, 1, 2, ..., n. 229 If a user wants to keep the same repeat cycle between any two 230 adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n 231 times with repeat cycle C within -P and Q SYNC" may be used, which 232 represents n+1 simple elastic time intervals as follows: 234 [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X] 236 where -P <= X <= Q. 238 4.4. Changes to Time Interval 240 After a temporal LSP is configured, a user may change its parameters 241 including some of the time intervals configured. A new time interval 242 may be added, an existing time interval may be removed or changed. 244 When a new time interval is added to an existing LSP, a path 245 satisfying the constraints for the LSP in the time interval is 246 computed and the LSP along the path is set up to carry traffic in the 247 time interval. 249 When an existing time interval is removed from an existing LSP, the 250 time interval is deleted from the lifetime of the LSP. If the 251 lifetime is over, the LSP is deleted. 253 A change to an existing time interval may generate some of four 254 possible results: 256 1. The existing time interval is extended for a time period EA after 257 the existing time period; 259 2. The existing time interval is extended for a time period EB 260 before the existing time period; 262 3. The existing time interval is shrunk for a time period SA from 263 the end of the existing time period; and 265 4. The existing time interval is shrunk for a time period SB from 266 the beginning of the existing time period. 268 When an existing time interval for an LSP is extended, a path 269 satisfying the constraints for the LSP in the extended time interval 270 is computed and the LSP along the path is set up to carry traffic in 271 the extended time interval. If the LSP is already up to carry 272 traffic in the existing time interval, the lifetime of the LSP is 273 extended for time period EA following the existing time interval. 275 When an existing time interval for an LSP is shrunk, the shrunk time 276 periods are removed from the lifetime of the LSP. 278 4.5. Graceful Periods 280 For a temporal LSP, a user may want to have some graceful periods for 281 each or some of the time intervals for the LSP. Two graceful periods 282 may be configured for a time interval. One is the graceful period 283 before the time interval, called grace-before, which extends the 284 lifetime of the LSP for grace-before (such as 30 seconds) before the 285 time interval. The other is the one after the time interval, called 286 grace-after, which extends the lifetime of the LSP for grace-after 287 (such as 60 seconds) after the time interval. 289 When an LSP is configured with a simple time interval such as [Ta, 290 Tb] with graceful periods such as grace-before GB and grace-after GA, 291 a path is computed such that the path satisfies the constraints for 292 the LSP in the time period from Ta to Tb. The LSP along the path is 293 set up to carry traffic in the time period from (Ta-GB) to (Tb+GA). 294 During graceful periods from (Ta-GB) to Ta and from Tb to (Tb+GA), 295 the LSP is up to carry traffic (maybe in best effort). 297 5. Extensions to PCEP 299 This section describes the extensions to PCEP for computing paths for 300 temporal LSP, initiating and maintaining temporal LSPs. 302 5.1. Capability TLV in Existing PCE Discovery Protocol 304 There are a couple of options for advertising a PCE capability for 305 computing paths for temporal LSP, initiating and maintaining temporal 306 LSPs. 308 The first option is to define a new flag in the OSPF and ISIS PCE 309 Capability Flags to indicate the capability that a PCE is capable to 310 compute paths for temporal LSPs, initiate and maintain temporal LSPs. 311 This includes the capability of computing both a path for a temporal 312 P2MP LSP and a path for a temporal P2P LSP. 314 The second option is to define three new flags. The first new flag 315 in the OSPF and ISIS PCE Capability Flags indicates the capability 316 that a PCE is capable to compute a path for a temporal P2MP LSP; the 317 second new flag indicates the capability that a PCE is capable to 318 compute a path for a temporal P2P LSP; and the third new flag 319 indicates the capability that a PCE is capable to initiate and 320 maintain a temporal LSP. 322 The format of the PCE-CAP-FLAGS sub-TLV is as follows: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type = 5 | Length | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 ~ PCE Capability Flags ~ 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Type: 5 334 Length: Multiple of 4 octets 335 Value: This contains an array of units of 32-bit flags 336 numbered from the most significant as bit zero, where 337 each bit represents one PCE capability. 339 The following capability bits have been assigned by IANA: 341 Bit Capabilities 342 0 Path computation with GMPLS link constraints 343 1 Bidirectional path computation 344 2 Diverse path computation 345 3 Load-balanced path computation 346 4 Synchronized path computation 347 5 Support for multiple objective functions 348 6 Support for additive path constraints 349 (max hop count, etc.) 350 7 Support for request prioritization 351 8 Support for multiple requests per message 352 9 Global Concurrent Optimization (GCO) 353 10 P2MP path computation 354 ... 356 Reserved bits SHOULD be set to zero on transmission and MUST be 357 ignored on receipt. 359 For the first option, one bit such as bit 16 may be assigned to 360 indicate that a PCE is capable to compute paths for temporal LSPs, 361 initiate and maintain temporal LSPs. 363 Bit Capabilities 364 16 Path computation for temporal LSPs, initiation 365 and maintenance of temporal LSPs 366 17-31 Reserved for future assignments by IANA. 368 For the second option, one bit such as bit 16 may be assigned to 369 indicate that a PCE is capable to compute a path for a temporal P2MP 370 LSP; another bit such as bit 17 may be assigned to indicate that a 371 PCE is capable to compute a path for a temporal P2P LSP; and yet 372 another bit such as bit 18 may be assigned to indicate that a PCE is 373 capable to initiate and maintain temporal LSPs. 375 Bit Capabilities 376 16 Path computation for temporal P2MP LSP 377 17 Path computation for temporal P2P LSP 378 18 Initiation and maintenance of temporal LSP 379 19-31 Reserved for future assignments by IANA. 381 5.2. Open Message Extension 383 If a PCE does not advertise its capability related to computation of 384 paths for a temporal LSP, initiation and maintenance of a temporal 385 LSP during discovery, PCEP should be used to allow a PCC to discover, 386 during the Open Message Exchange, which PCEs are capable of 387 supporting computation of a path for a temporal LSP, initiation and 388 maintenance of a temporal LSP. 390 To achieve this, one option is to extend the PCEP OPEN object by 391 defining new flag bits in the value field of an existing capability 392 TLV such as stateful PCE capability TLV in the same way as the PCE 393 Capability Flags described in the previous section. Another option 394 is to extend the PCEP OPEN object by defining a new optional TLV to 395 indicate the PCE's capability to compute paths for a temporal LSP, 396 initiate and maintain a temporal LSP. 398 For the second option, we need to request IANA to allocate a value 399 such as 10 from the "PCEP TLV Type Indicators" subregistry, as 400 documented in Section below ("Temporal LSP Capability TLV"). The 401 description is "temporal LSP capable", and the length value is 2 402 bytes. The value field is set to indicate the capability of a PCE 403 for computation of paths for a temporal LSP, initiation and 404 maintenance of a temporal LSP in details. We can use flag bits in 405 the value field in the same way as the PCE Capability Flags described 406 in the previous section. 408 The inclusion of this TLV in an OPEN object indicates that the sender 409 can compute paths for a temporal LSP, initiate and maintain a 410 temporal LSP. 412 The capability TLV is meaningful only for a PCE, so it will typically 413 appear only in one of the two Open messages during PCE session 414 establishment. However, in case of PCE cooperation (e.g., inter- 415 domain), when a PCE behaving as a PCC initiates a PCE session it 416 SHOULD also indicate its capabilities. 418 5.3. RP Object Extension 420 The following flags are added into the RP Object: 422 A T bit is added in the flag bits field of the RP object to tell a 423 receiver of a message that the message is for (computing paths for a 424 temporal LSP) a temporal LSP. 426 o T (Temporal LSP bit - 1 bit): 428 0: This indicates that this is not a message 429 for a temporal LSP. 431 1: This indicates that this is a message 432 for a temporal LSP. 434 The IANA request is referenced in Section below (Request Parameter 435 Bit Flags) of this document. 437 This T bit with the N bit defined in RFC6006 can indicate whether the 438 message is for a temporal P2P LSP or P2MP LSP. 440 o T = 1 and N = 0: This indicates that this is a message 441 for a temporal P2P LSP 442 o T = 1 and N = 1: This indicates that this is a message 443 for a temporal P2MP LSP 445 5.4. TIME INTERVAL Object 447 For a TIME-INTERVAL object, its Class is to be assigned by IANA, here 448 we use 18, which may be changed late. Its OT is 1, exact number to 449 be assigned by IANA. The format of a TIME-INTERVAL object body is 450 illustrated below, which comprises a number of time interval TLVs. 452 Object-Class: TBD (18), OT = 1 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | (Object Body containing Time Interval TLVs) | 457 ~ ~ 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 A time interval TLV may be a relative time interval TLV or an 461 absolute time interval TLV, which are two different representations 462 of a time interval. Their advantages and disadvantages are discussed 463 below. 465 5.4.1. Absolute Time Interval TLV 467 The format of an absolute time interval TLV (Type = 1) for an LSP is 468 illustrated below. It mainly contains a Start-time and an End-time, 469 representing time interval [Start-time, End-time]. Both of these two 470 times are the times that are synchronized among all the elements 471 involved. Thus the clocks on all the elements MUST be synchronized 472 if an absolute time interval TLV is used. The time period 473 represented in an absolute time interval TLV is more accurate. 475 In addition, it contains an non zero grace-before and grace-after if 476 graceful periods are configured. It includes an non zero elastic 477 range lower bound and upper bound if there is an elastic range 478 configured. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type (1) | Length | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Start-time | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | End-time | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | GrB | GrA | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Elastic-Lower-Bound | Elastic-Upper-Bound | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 o Start-time: The time LSP starts to carry traffic. 496 o End-time: The time LSP stops carrying traffic. 498 o GrB (Grace-Before): The graceful period time length in seconds 499 before time interval [Start-time, End-time]. 501 o GrA (Grace-After): The graceful period time length in seconds 502 after time interval [Start-time, End-time]. 504 o Elastic-Lower-Bound: The maximum amount of time in seconds that 505 time interval [Start-time, End-time] can shift to lower/left. 507 o Elastic-Upper-Bound: The maximum amount of time in seconds that 508 time interval [Start-time, End-time] can shift to upper/right. 510 Discussions: Optionally, we may define three TLVs below: 512 1. an absolute time interval TLV containing only a Start-time and an 513 End-time; 515 2. an elastic range TLV containing just an elastic range lower bound 516 and upper bound; and 518 3. a graceful period TLV containing only a grace-before and a grace- 519 after. 521 If a time interval is with an elastic range, an absolute time 522 interval TLV followed by an elastic range TLV is used. If a time 523 interval is with graceful periods, an absolute time interval TLV 524 followed by a graceful period TLV is used. 526 5.4.2. Relative Time Interval TLV 528 The format of a relative time interval TLV (Type = 2) for an LSP is 529 shown below. It mainly contains a Start-time-length and an End-time- 530 length, representing the time interval below for the LSP: 532 [current-time + Start-time-length, current-time + End-time-length] 534 where current-time is a current local time. When a time interval 535 from time Ta to time Tb is configured on a node/element, these two 536 time lengths are the time lengths that are computed on the node using 537 a current local time as follows. 539 Start-time-length = Ta - current-time; 540 End-time-length = Tb - current-time; 542 For a relative time interval TLV, the clocks/times on all the 543 elements involved can be different. But the time period represented 544 in a relative time interval TLV on one element/node may be shifted a 545 little bit from another element's point of view since transmitting 546 the TLV from one element to another takes a little time, which is 547 hard to be considered accurately. 549 The TLV also includes an non zero grace-before and grace-after if 550 graceful periods are configured. It contains an non zero elastic 551 range lower bound and upper bound if there is an elastic range 552 configured. 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type (2) | Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Start-time-length | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | End-time-length | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | GrB | GrA | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Elastic-Lower-Bound | Elastic-Upper-Bound | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 o Start-time-length: The time length in seconds from a current 569 local time to the time LSP starts to carry traffic. 571 o End-time-length: The time length in seconds from a current local 572 time to the time LSP ends carrying traffic. 574 o GrB (Grace-Before): The graceful period time length in seconds 575 before the time interval above for the LSP. 577 o GrA (Grace-After): The graceful period time length in seconds 578 after the time interval above for the LSP. 580 o Elastic-Lower-Bound: The maximum amount of time in seconds that 581 the time interval above for the LSP can shift to lower/left. 583 o Elastic-Upper-Bound: The maximum amount of time in seconds that 584 the time interval above can shift to upper/right. 586 5.4.3. Recurrent Absolute Time Interval TLV 588 The format of a recurrent absolute time interval TLV (Type = 3) for 589 an LSP is illustrated below. It mainly contains a Start-time, an 590 End-time, a Repeat-time-length, a Options field and a Number-repeats. 592 The Start-time and End-time represents time interval [Start-time, 593 End-time]. The Repeat-time-length represents a repeat cycle/time, 594 which is valid if the Options field is set to indicate the way to 595 repeat is "repeat every Repeat-time-length". The Options field 596 indicates a way to repeat. The Number-repeats indicates the number 597 of repeats of time interval [Start-time, End-time]. 599 In addition, the TLV includes an non zero grace-before and grace- 600 after if graceful periods are configured. It contains an non zero 601 elastic range lower bound and upper bound if there is an elastic 602 range configured. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Type (3) | Length | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Start-time | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | End-time | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Repeat-time-length | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Options | Number-repeats | Reserved (0) | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | GrB | GrA | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Elastic-Lower-Bound | Elastic-Upper-Bound | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 o Start-time: The time LSP starts to carry traffic. 624 o End-time: The time LSP stops carrying traffic. 626 o Repeat-time-length: The time length in seconds after which LSP 627 starts to carry traffic again for (End-time - Start-time). 629 o 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 o Number-repeats: The number of repeats. In each of repeats, LSP 642 carries traffic. 644 o GrB (Grace-Before): The graceful period time length in seconds 645 before each of the time intervals represented by the recurrent 646 time interval. 648 o GrA (Grace-After): The graceful period time length in seconds 649 after each of the time intervals. 651 o Elastic-Lower-Bound: The maximum amount of time in seconds that 652 each of the time intervals can shift to lower/left. 654 o Elastic-Upper-Bound: The maximum amount of time in seconds that 655 each of the time intervals can shift to upper/right. 657 5.4.4. Recurrent Relative Time Interval TLV 659 The format of a recurrent relative time interval TLV (Type = 4) is 660 shown below. It mainly contains a Start-time-length, an End-time- 661 length, a Repeat-time-length, a Options field and a Number-repeats. 663 The Start-time-length and End-time-length represents time interval 665 [current-time + Start-time-length, current-time + End-time-length] 667 where current-time is a current local time. The Repeat-time-length 668 represents a repeat cycle/time, which is valid if the Options field 669 is set to indicate the way to repeat is "repeat every Repeat-time- 670 length". The Options field indicates a way to repeat. The Number- 671 repeats indicates the number of repeats of the time interval above. 673 In addition, the TLV includes an non zero grace-before and grace- 674 after if graceful periods are configured. It contains an non zero 675 elastic range lower bound and upper bound if there is an elastic 676 range configured. 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Type (4) | Length | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Start-time-length | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | End-time-length | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Repeat-time-length | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Options | Number-repeats | Reserved (0) | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | GrB | GrA | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Elastic-Lower-Bound | Elastic-Upper-Bound | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 o Start-time-length: The time length in seconds from a current 697 local time to the time LSP starts to carry traffic. 699 o End-time-length: The time length in seconds from a current local 700 time to the time LSP stops carrying traffic. 702 o Repeat-time-length: The time length in seconds after which LSP 703 starts to carry traffic again for (End-time-length - Start-time- 704 length). 706 o Options: Indicates a way to repeat. 708 Options = 1: repeat every day; 710 Options = 2: repeat every week; 712 Options = 3: repeat every month; 714 Options = 4: repeat every year; 716 Options = 5: repeat every Repeat-time-length. 718 o Number-repeats: The number of repeats. In each of repeats, LSP 719 carries traffic. 721 o GrB (Grace-Before): The graceful period time length in seconds 722 before each of the time intervals represented by the recurrent 723 time interval. 725 o GrA (Grace-After): The graceful period time length in seconds 726 after each of the time intervals. 728 o Elastic-Lower-Bound: The maximum amount of time in seconds that 729 each of the time intervals can shift to lower/left. 731 o Elastic-Upper-Bound: The maximum amount of time in seconds that 732 each of the time intervals can shift to upper/right. 734 5.5. Messages for Temporal LSP 736 This section presents and discusses two classes of messages. One 737 class is the messages between a PCE and a PCC on the ingress of a 738 temporal LSP for initiating and maintaining the LSP. The other is 739 the messages between two PCEs, one of which acts as a PCC. 741 5.5.1. Messages between PCE and PCC on Ingress 743 From function's point of view, there are four groups of messages: 745 1. LSP creation request messages, 747 2. LSP deletion request messages, 749 3. LSP creation response messages, and 751 4. LSP deletion response messages. 753 A message for an LSP in the first two groups is sent from a PCE to 754 the PCC on the ingress of the LSP. A message for an LSP in the last 755 two groups is sent from the PCC on the ingress of the LSP to a PCE. 757 A Path Computation LSP Initiate Request (PCInitiate) message without 758 any extensions can be used for a message in the first two groups. A 759 Path Computation LSP State Report (PCRpt) message without any 760 extensions can be used for a message in the last two groups. 762 Alternatively, a PCInitiate message with some optional extensions 763 such as TIME-INTERVAL can be used for a message in the first two 764 groups. A PCRpt message with some optional extensions such as TIME- 765 INTERVAL can be used for a message in the last two groups. 767 For an LSP creation request, a PCInitiate message includes objects: 768 SRP, LSP, END-POINTS, ERO and optional TIME-INTERVAL. SRP (Stateful 769 PCE Request Parameters) object comprises an SRP-ID-number. LSP 770 object comprises PLSP-ID of 0, and SYMBOLIC-PATH-NAME TLV with path 771 name. END-POINTS object comprises the source and destination 772 addresses of the LSP. ERO object comprise the path (i.e., ERO) for 773 the LSP. TIME-INTERVAL object comprises the time intervals for the 774 LSP (the path satisfies constraints for the LSP in each of the time 775 intervals). 777 For an LSP creation response, a PCRpt message includes objects: SRP, 778 LSP, ERO and optional TIME-INTERVAL. SRP object comprises the SRP- 779 ID-number in the corresponding LSP creation request message. LSP 780 object comprises a PLSP-ID assigned to the LSP by the PCC, SYMBOLIC- 781 PATH-NAME TLV with path name, C Flag set to 1 indicates that this LSP 782 is created by the LSP creation request. ERO object comprise the path 783 (i.e., ERO) for the LSP. TIME-INTERVAL object comprises the time 784 intervals for the LSP. 786 For an LSP deletion request, a PCInitiate message includes objects: 787 SRP, LSP, and optional TIME-INTERVAL. SRP object comprises an SRP- 788 ID-number and R (remove) flag set to 1. LSP object comprises the 789 PLSP-ID for the LSP created. TIME-INTERVAL object comprises the time 790 intervals for the LSP. 792 For an LSP deletion response, a PCRpt message includes objects: SRP, 793 LSP, and optional TIME-INTERVAL. SRP object comprises the SRP-ID- 794 number in the corresponding LSP deletion request message. LSP object 795 comprises R(Remove) flag set to 1 indicating that the LSP has been 796 removed from the PCC, and LSP Identifiers TLV. 798 Note: The PCC on the ingress of an LSP does not use any time 799 intervals in the TIME-INTERVAL object received for signaling the LSP. 800 For just creating and deleting LSPs, we do not need to include any 801 TIME-INTERVAL object in a message if the PCE creates the LSP with a 802 sequence of time intervals at the beginning of each of the time 803 intervals and deletes the LSP at the end of each of the time 804 intervals. 806 Discussions: For an LSP having a time interval TLV with graceful 807 periods, we may create the LSP in the time period including the 808 graceful periods and the LSP has the reserved bandwidth during that 809 period (including the graceful periods). 811 Another option is that we create the LSP in the time period including 812 the graceful periods, but do not reserve any bandwidth for the LSP in 813 the beginning. The desired bandwidth for the LSP is reserved in the 814 time period without graceful periods. 816 After the graceful period before the time interval, the bandwidth for 817 the LSP is reserved through a update message from the PCE to the PCC 818 on the ingress of the LSP. After the time interval (i.e., just 819 before the graceful period after the time interval), the bandwidth 820 for the LSP is released through another update message from the PCE 821 to the PCC on the ingress of the LSP. 823 5.5.2. Messages between two PCEs 825 Figure below illustrates the format of a request message with a 826 optional TIME-INTERVAL object for computing paths for a temporal LSP 827 with a sequence of time intervals: 829 ::= 830 [] 831 832 ::=[] 833 ::= [] [] [] 834 [] [[]] [] 835 [] 836 [] 838 Figure 1: Format for Request Message 840 Below is the format of a reply message with a optional TIME-INTERVAL 841 object: 843 ::= 844 845 ::=[] 846 ::= 847 [] 848 [] 849 [] 850 ::=[] 851 ::= [] 853 Figure 2: Format for Reply Message 855 6. Procedures 857 This section focuses on the procedures for creating and deleting a 858 temporal LSP. When a PCE receives a request for an LSP with a 859 sequence of time intervals from a user or application, it computes a 860 path satisfying the constraints for the LSP in each of the time 861 intervals and reserved the bandwidth for the LSP along the path in 862 each of the time intervals. And then it initiates the creation of 863 the LSP in the network to carry traffic in each of the time 864 intervals. 866 There are a couple of ways for a PCE to create an LSP with a sequence 867 of time intervals. One way is that the PCE initiates the creation of 868 the LSP at the beginning of each of the time intervals. At the end 869 of each of the time intervals or when a deletion request for the LSP 870 received, the PCE initiates the deletion of the LSP. 872 Another way is that the PCE initiates the creation of the LSP at or 873 before the beginning of the first time interval and the deletion of 874 the LSP at the end of the last time interval. At the start of each 875 time interval, the PCE initiates the update of the LSP with the 876 reserved resource such as link bandwidth. At the end of the each 877 time interval, the PCE initiates the update of the LSP with zero 878 resource. 880 We will focus on the first way below. 882 6.1. Creating a Temporal LSP 884 A procedure for creating a temporal LSP is as follows: 886 Step 1: A PCE receives a request for creating a temporal LSP from 887 a user or application and stores the parameters of the LSP into an 888 LSP database (LSPDB) such as LSP State Database. The parameters 889 include a number of time intervals for the LSP. 891 Step 2: The PCE computes a shortest path satisfying constraints 892 for the LSP in each of the time intervals given. It reserves the 893 resources such as the bandwidth in TED on each of the links the 894 LSP traverses for each of the time intervals and stores the 895 information about the LSP into the LSPDB. The information 896 includes the paths computed for the LSP and the resources such as 897 link bandwidth reserved for the LSP. 899 Step 3: At the beginning of each of the time intervals, the PCE 900 initiates the setup of the LSP in a network through sending an LSP 901 creation request (e.g., a PCInitiate with LSP object with PLSP- 902 ID=0) with the path for the LSP to the PCC on the ingress of the 903 LSP, which triggers RSVP-TE to signal the LSP along the path in 904 the network (Note that the RSVP-TE is not aware of any time 905 interval for the LSP and just sets up the LSP in a normal way). 906 The PCC sends an LSP creation response (e.g., a PCRpt) to the PCE 907 after the LSP is up. 909 Step 4: The PCE receives the LSP creation response (e.g., the 910 PCRpt) from the PCC corresponding to the request and updates the 911 status of the LSP in the LSPDB accordingly. 913 6.2. Deleting a Temporal LSP 915 Suppose that a temporal LSP has been created to carry traffic in a 916 sequence of time intervals. A procedure for deleting this temporal 917 LSP is as follows: 919 Step 1: A PCE receives a request for deleting the temporal LSP 920 from an client, or the lifetime for the LSP in a time interval is 921 over and the LSP needs to be deleted. 923 Step 2: The PCE finds the LSP in the LSPDB and gets the 924 information about the LSP. 926 Step 3: The PCE initiates the deletion of the LSP in the network 927 through sending an LSP deletion request (e.g., a PCInitiate with R 928 flag set and PLSP ID for the LSP) to the PCC on the ingress of the 929 LSP, which triggers the RSVP-TE to tear down the LSP in the 930 network (Note that the RSVP-TE is not aware of any time interval 931 for the LSP and just tears down the LSP in a normal way). The PCC 932 generates an LSP deletion response (e.g., a PCRpt with R flag set) 933 and sends it to the PCE after the LSP is torn down. 935 Step 4: The PCE receives the LSP deletion response (e.g., the 936 PCRpt) from the PCC corresponding to the request and updates the 937 status of the LSP in the LSPDB accordingly. For deleting the LSP 938 completely as requested, it releases the resources such as the 939 link bandwidth reserved for the LSP in TED for each of the time 940 intervals and removes the information about the LSP from the LSPDB 941 after the LSP is deleted. 943 7. Considerations on TED 945 The existing Traffic Engineering (TE) information in a TED represents 946 an unreserved bandwidth Bi at each of eight priority levels for a 947 link at one point of time, for example, at the current time. 949 Bandwidth 950 ^ 951 | 952 Bi|______________________________________________________ 953 | 954 | 955 -+------------------------------------------------------> Time 956 | 958 This means that the link has bandwidth Bi at a priority level from 959 now to forever until there is a change to it. Thus, a TE Label 960 Switching Path (LSP) tunnel for a given time interval cannot be set 961 up in advance using the information in the TED and the bandwidth 962 cannot be reserved in advance for the LSP in the time interval given. 964 TED needs to be enhanced for supporting temporal LSPs. Two options 965 for enhancing TED are presented below. 967 7.1. TE Representation in Absolute Time 969 Suppose that the amount of the unreserved bandwidth at a priority 970 level for a link is Bj in a time interval from time Tj to Tk (k = 971 j+1), where j = 0, 1, 2, .... The unreserved bandwidth for the link 972 can be represented as 974 [T0, B0], [T1, B1], [T2, B2], [T3, B3], .... 976 This is an absolute time representation of bandwidths for a link. 977 Time Tj (j = 0, 1, 2, ...) MUST be a synchronized time among all the 978 elements involved. 980 Bandwidth 981 ^ 982 | B3 983 | B1 ___________ 984 | __________ 985 |B0 B4 986 |__________ B2 _________ 987 | ________________ 988 | 989 -+-------------------------------------------------------> Time 990 |T0 T1 T2 T3 T4 992 If an LSP is completely deleted at time T and uses bandwidth B, then 993 for every time interval/period (after time T) during which bandwidth 994 B is reserved for the LSP on a link, B is added to the link for that 995 interval/period. 997 If an LSP is to be up at time T and uses bandwidth B, then for every 998 time interval/period (after time T) during which bandwidth B is 999 reserved for the LSP on a link, B is subtracted from the link for 1000 that interval/period. 1002 7.2. TE Representation in Relative Time 1004 Alternatively, a relative time representation of bandwidths for a 1005 link can be used. For example, the amount of the unreserved 1006 bandwidth at a priority level for a link is Bj during a series of 1007 time intervals/periods can be expressed as 1009 [P0, B0], [P1, B1], [P2, B2], [P3, B3], ..., where 1010 Pj = Tk - Tj, k = (j+1) and j = 0, 1, 2, 3, .... 1012 In this representation, every time Tj (j = 0, 1, 2, ...) can be a 1013 local time. A timer may expire for every unit of time (e.g., every 1014 second) and may trigger --P0, which decrements P0. When P0 = 0, P1 1015 becomes P0, P2 becomes P1, and so on. 1017 If an LSP is completely deleted at time T and uses bandwidth B, then 1018 for every time interval/period (after time T) during which bandwidth 1019 B is reserved for the LSP on a link, B is added to the link for that 1020 interval/period. 1022 If an LSP is to be up at time T and uses bandwidth B, then for every 1023 time interval/period (after time T) during which bandwidth B is 1024 reserved for the LSP on a link, B is subtracted from the link for 1025 that interval/period. 1027 An advantage of using relative time representation is that the times 1028 or clocks on all the elements involved can be different. 1030 8. Security Considerations 1032 The mechanism described in this document does not raise any new 1033 security issues for the PCEP protocols. 1035 9. IANA Considerations 1037 This section specifies requests for IANA allocation. 1039 10. Acknowledgement 1041 The authors would like to thank everyone who give his/her valuable 1042 comments on this draft. 1044 11. References 1046 11.1. Normative References 1048 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1049 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1050 RFC2119, March 1997, 1051 . 1053 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1054 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1055 DOI 10.17487/RFC5440, March 2009, 1056 . 1058 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 1059 Ali, Z., and J. Meuric, "Extensions to the Path 1060 Computation Element Communication Protocol (PCEP) for 1061 Point-to-Multipoint Traffic Engineering Label Switched 1062 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 1063 . 1065 [I-D.ietf-pce-stateful-pce] 1066 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1067 Extensions for Stateful PCE", 1068 draft-ietf-pce-stateful-pce-18 (work in progress), 1069 December 2016. 1071 [I-D.ietf-pce-pce-initiated-lsp] 1072 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1073 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1074 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 1075 progress), July 2016. 1077 11.2. Informative References 1079 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1080 Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/ 1081 RFC4655, August 2006, 1082 . 1084 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 1085 (PCC) - Path Computation Element (PCE) Requirements for 1086 Point-to-Multipoint MPLS-TE", RFC 5862, DOI 10.17487/ 1087 RFC5862, June 2010, 1088 . 1090 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1091 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1092 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1093 . 1095 Authors' Addresses 1097 Huaimo Chen 1098 Huawei Technologies 1099 Boston, MA 1100 US 1102 Email: huaimo.chen@huawei.com 1104 Xufeng Liu 1105 Ericsson 1106 USA 1108 Email: xliu@kuatrotech.com 1110 Mehmet Toy 1111 Verizon 1112 USA 1114 Email: mehmet.toy@verizon.com 1116 Vic Liu 1117 China Mobile 1118 No.32 Xuanwumen West Street, Xicheng District 1119 Beijing, 100053 1120 China 1122 Email: liu.cmri@gmail.com 1124 Lei Liu 1125 Fujitsu 1126 USA 1128 Email: lliu@us.fujitsu.com 1130 Khuzema Pithewan 1131 Infinera 1133 Email: kpithewan@infinera.com