idnits 2.17.1 draft-ietf-pce-stateful-pce-lsp-scheduling-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 15, 2017) is 2385 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 340, but not defined == Missing Reference: 'Tb' is mentioned on line 340, but not defined == Missing Reference: 'TBD' is mentioned on line 652, but not defined == Missing Reference: 'RFC5925' is mentioned on line 759, but not defined == Unused Reference: 'I-D.ietf-pce-stateful-pce-auto-bandwidth' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 918, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-pce-stateful-pce-auto-bandwidth-05 == Outdated reference: A later version (-07) exists of draft-ietf-teas-scheduled-resources-03 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-scheduled-resources (ref. 'I-D.ietf-teas-scheduled-resources') == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-02 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group H. Chen, Ed. 3 Internet-Draft Y. Zhuang, Ed. 4 Intended status: Standards Track Q. Wu 5 Expires: April 18, 2018 D. Dhody 6 Huawei 7 D. Ceccarelli 8 Ericsson 9 October 15, 2017 11 PCEP Extensions for LSP scheduling with stateful PCE 12 draft-ietf-pce-stateful-pce-lsp-scheduling-01 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 https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 18, 2018. 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 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions used in this document . . . . . . . . . . . . . . 4 59 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Motivation and Objectives . . . . . . . . . . . . . . . . . . 5 61 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 62 4.1. LSP scheduling Overview . . . . . . . . . . . . . . . . . 5 63 4.2. Support of LSP Scheduling . . . . . . . . . . . . . . . . 7 64 4.2.1. LSP Scheduling . . . . . . . . . . . . . . . . . . . 7 65 4.2.2. Periodical LSP Scheduling . . . . . . . . . . . . . . 7 66 4.3. Scheduled LSP creation . . . . . . . . . . . . . . . . . 8 67 4.4. Scheduled LSP Modifications . . . . . . . . . . . . . . . 10 68 4.5. Scheduled LSP activation and deletion . . . . . . . . . . 10 69 5. PCEP Objects and TLVs . . . . . . . . . . . . . . . . . . . . 11 70 5.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 11 71 5.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.2.1. SCHED-LSP-ATTRIBUTE TLV . . . . . . . . . . . . . . . 12 73 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV . . . . . . . . . . . . . 14 74 6. The PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 15 75 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 15 76 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 15 77 6.3. The PCInitiate Message . . . . . . . . . . . . . . . . . 16 78 6.4. The PCReq message . . . . . . . . . . . . . . . . . . . . 16 79 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 16 80 6.6. The PCErr Message . . . . . . . . . . . . . . . . . . . . 16 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 8. Manageability Consideration . . . . . . . . . . . . . . . . . 17 83 8.1. Control of Function and Policy . . . . . . . . . . . . . 17 84 8.2. Information and Data Models . . . . . . . . . . . . . . . 17 85 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17 86 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 17 87 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 17 88 8.6. Impact On Network Operations . . . . . . . . . . . . . . 17 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 90 9.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 18 91 9.2. STATEFUL-PCE-CAPABILITY TLV Flag field . . . . . . . . . 18 92 9.3. Schedule TLVs Flag Field . . . . . . . . . . . . . . . . 18 93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 96 11.2. Informative References . . . . . . . . . . . . . . . . . 20 98 Appendix A. Scheduled LSP information synchronization . . . . . 20 99 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 21 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 102 1. Introduction 104 The Path Computation Element Protocol (PCEP) defined in [RFC5440] is 105 used between a Path Computation Element (PCE) and a Path Computation 106 Client (PCC) (or other PCE) to enable path computation of Multi- 107 protocol Label Switching (MPLS) Traffic Engineering Label Switched 108 Path (TE LSP). 110 Further, in order to support use cases described in [RFC8231] 111 specifies a set of extensions to PCEP to enable stateful control of 112 MPLS-TE and GMPLS LSPs via PCEP. 114 Traditionally, the usage and allocation of network resources, 115 especially bandwidth, can be supported by a Network Management System 116 operation such as path pre-establishment. However, this does not 117 provide efficient network usage since the established paths exclude 118 the possibility of being used by other services even when they are 119 not used for undertaking any service. [I-D.ietf-teas-scheduled- 120 resources] then provides a framework that describes and discusses the 121 problem and proposes an appropriate architecture for the scheduled 122 reservation of TE resources. 124 With the scheduled reservation of TE resources, it allows network 125 operators to reserve resources in advance according to the agreements 126 with their customers, and allow them to transmit data with scheduling 127 such as specified starting time and duration, for example for a 128 scheduled bulk data replication between data centers. It enables the 129 activation of bandwidth usage at the time the service really being 130 used while letting other services obtain it in spare time. The 131 requirement of scheduled LSP provision is mentioned in [RFC8231] and 132 [RFC7399], so as to provide more efficient network resource usage for 133 traffic engineering, which hasn't been solved yet. Also, for 134 deterministic networks, the scheduled LSP can provide a better 135 network resource usage for guaranteed links. This idea can also be 136 applied in segment routing to schedule the network resources over the 137 whole network in a centralized manner as well. 139 With this in mind, this document proposes a set of extensions needed 140 to the stateful PCE, so as to enable LSP scheduling for path 141 computation and LSP setup/deletion based on the actual network 142 resource usage duration of a traffic service. A scheduled LSP is 143 characterized by a starting time and a duration. When the end of the 144 LSP life is reached, it is deleted to free up the resources for other 145 LSP (scheduled or not). 147 2. Conventions used in this document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 RFC2119 [RFC2119] RFC8174 [RFC8174] when, and only when, they 153 appear in all capitals, as shown here. 155 2.1. Terminology 157 The following terminologies are re-used from existing PCE documents. 159 o Active Stateful PCE [RFC8231]; 161 o Passive Stateful PCE [RFC8231]; 163 o Delegation [RFC8231]; 165 o PCE-Initiated LSP [I-D.ietf-pce-pce-initiated-lsp]; 167 o PCC [RFC5440], [RFC8231]; 169 o PCE [RFC5440], [RFC8231]; 171 o TE LSP [RFC5440], [RFC8231]; 173 o TED [RFC5440], [RFC8231]; 175 o LSP DB [RFC8231]; 177 In addition, this document defines the following terminologies. 179 Scheduled TE LSP: a LSP with the scheduling attributes,that carries 180 traffic flow demand at a starting time and last for a certain 181 duration. The PCE operates path computation per LSP availability 182 for the required time and duration. 184 Scheduled LSP DB: a database of scheduled LSPs 186 Scheduled TED: Traffic engineering database with the awareness of 187 scheduled resources for TE. This database is generated by the PCE 188 from the information in TED and scheduled LSP DB and allows 189 knowing, at any time, the amount of available resources (does not 190 include failures in the future). 192 Starting time(start-time): This value indicates when the scheduled 193 LSP is used and the corresponding LSP must be setup and active. 194 In other time(i.e., before the starting time or after the starting 195 time plus Duration), the LSP can be inactive to include the 196 possibility of the resources being used by other services. 198 Duration: The value indicates the time duration that the LSP is 199 undertaken by a traffic flow and the corresponding LSP must be 200 setup and active. At the end of which, the LSP is teardown and 201 removed from the data base. 203 3. Motivation and Objectives 205 A stateful PCE can support better efficiency by using LSP scheduling 206 described in the use case of [RFC8231]. This requires the PCE to 207 maintain the scheduled LSPs and their associated resource usage, e.g. 208 bandwidth for Packet-switched network, as well as have the ability to 209 trigger signaling for the LSP setup/tear-down at the correct time. 211 Note that existing configuration tools can be used for LSP 212 scheduling, but as highlighted in section 3.1.3 of [RFC8231] as well 213 as discussions in [I-D.ietf-teas-scheduled-resources], doing this as 214 a part of PCEP in a centralized manner, has obvious advantages. 216 The objective of this document is to provide a set of extensions to 217 PCEP to enable LSP scheduling for LSPs creation/deletion under the 218 stateful PCE control, according to traffic services from customers, 219 so as to improve the usage of network resources. 221 4. Architecture Overview 223 4.1. LSP scheduling Overview 225 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for 226 customers' traffic services at its actual usage time, so as to 227 improve the network resource efficient utilization. 229 For stateful PCE supporting LSP scheduling, there are two types of 230 LSP databases used in this document. One is the LSP-DB defined in 231 PCEP [RFC8231], while the other is the scheduled LSP database (SLSP- 232 DB, see section 6). The SLSP-DB records scheduled LSPs and is used 233 as a complementary to the TED and LSP-DB. Note that the two types of 234 LSP databases can be implemented in one physical database or two 235 different databases. This document does not state any preference 236 here. 238 Furthermore, a scheduled TED can be generated from the scheduled LSP 239 DB, LSP DB and TED to indicate the network links and nodes with 240 resource availability information for now and future. The scheduled 241 TED should be maintained by all PCEs within the network environment. 243 In case of implementing PCC-initiated scheduled LSPs, before a PCC 244 delegates a scheduled LSP, it MAY use the PCReq/PCRep messages to 245 learn the path for the scheduled LSP. A PCC MUST delegate a 246 scheduled LSP with information of its scheduling parameters, 247 including the starting time and the duration using PCRpt message. 248 Since the LSP is not yet signaled, at the time of delegation the LSP 249 would be in down state. Upon receiving the delegation of the 250 scheduled LSP, a stateful PCE SHALL check the scheduled TED for the 251 network resource availability on network nodes and computes a path 252 for the LSP with the scheduling information and update to the PCC as 253 per the active stateful PCE techniques [RFC8231]. 255 Note that the active stateful PCE can update to the PCC with the path 256 for the scheduled LSP at any time. However, the PCC should not 257 signal the LSP over the path once receiving these messages since the 258 path is not activated yet until its starting time. 260 For a multiple PCE environment, in order to synchronize the scheduled 261 LSP DB, the mechanism as described in [I-D.litkowski-pce-state-sync] 262 are used to synchronize between PCEs. The scheduled TED is 263 determined from the synchronized SLSP-DB. The PCE with delegation 264 for the scheduled LSP would report the scheduled LSP to other PCEs, 265 any future update to the scheduled LSP is also updated to other PCEs. 266 This way the state of all scheduled LSPs are synchronized among the 267 PCEs. [RFC7399] discusses some synchronization issues and 268 considerations, that are also applicable to the scheduled databases. 270 The scheduled LSP can also be initiated by PCE itself. In case of 271 implementing PCE-initiated scheduled LSP, the stateful PCE shall 272 check the network resource availability for the traffic and computes 273 a path for the scheduled LSP and initiate a scheduled LSP at the PCC 274 and synchronize the scheduled LSP to other PCEs. Note that, the PCC 275 could be notified immediately or at the starting time of the 276 scheduled LSP based on the local policy. In case of former SCHED- 277 LSP-ATTRIBUTE MUST be included in the message where as for the latter 278 SCHED-LSP-ATTRIBUTE SHOULD NOT be included. 280 In both modes, for activation of scheduled LSPs, the PCC could 281 initiate the setup of scheduled LSP at the start time by itself or 282 wait for the PCE to update the PCC to initiate the setup of LSP. 283 Similarly on the scheduling usage expires, the PCC could initiate the 284 removal by itself or wait for the PCE to request the removal of the 285 LSP. This is based on the Flag set in SCHED-LSP-ATTRIBUTE TLV. The 286 state of the scheduled LSP is synchronized to other PCEs using the 287 existing mechanism in [RFC8231] and [I-D.litkowski-pce-state-sync]. 289 4.2. Support of LSP Scheduling 291 4.2.1. LSP Scheduling 293 For a scheduled LSP, a user configures it with an arbitrary 294 scheduling duration time from Ta to time Tb, which may be represented 295 as [Ta, Tb]. 297 When an LSP is configured with arbitrary scheduling duration [Ta, 298 Tb], a path satisfying the constraints for the LSP in the scheduling 299 duration is computed and the LSP along the path is set up to carry 300 traffic from time Ta to time Tb. 302 4.2.2. Periodical LSP Scheduling 304 In addition to LSP Scheduling at an arbitrary time period, there are 305 also periodical LSP Scheduling. 307 A periodical LSP Scheduling represents Scheduling LSP every time 308 interval. It has a scheduling duration such as [Ta, Tb], a number of 309 repeats such as 10 (repeats 10 times), and a repeat cycle/time 310 interval such as a week (repeats every week). The scheduling 311 interval: "[Ta, Tb] repeats n times with repeat cycle C" represents 312 n+1 scheduling intervals as follows: 314 [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC] 316 When an LSP is configured with a scheduling interval such as "[Ta, 317 Tb] repeats 10 times with a repeat cycle a week" (representing 11 318 scheduling intervals), a path satisfying the constraints for the LSP 319 in each of the scheduling intervals represented by the periodical 320 scheduling interval is computed and the LSP along the path is set up 321 to carry traffic in each of the scheduling intervals. 323 4.2.2.1. Elastic Time LSP Scheduling 325 In addition to the basic LSP scheduling at an arbitrary time period, 326 another option is elastic time intervals, which is represented as 327 within -P and Q, where P and Q is an amount of time such as 300 328 seconds. P is called elastic range lower bound and Q is called 329 elastic range upper bound. 331 For a simple time interval such as [Ta, Tb] with an elastic range, 332 elastic time interval: "[Ta, Tb] within -P and Q" means a time period 333 from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb 334 may be shifted the same X. 336 When an LSP is configured with elastic time interval "[Ta, Tb] within 337 -P and Q", a path is computed such that the path satisfies the 338 constraints for the LSP in the time period from (Ta+X) to (Tb+X) 339 and |X| is the minimum value from 0 to max(P, Q). That is that 340 [Ta+X, Tb+X] is the time interval closest to time interval [Ta, Tb] 341 within the elastic range. The LSP along the path is set up to carry 342 traffic in the time period from (Ta+X) to (Tb+X). 344 Similarly, for a recurrent time interval with an elastic range, 345 elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C 346 within -P and Q" represents n+1 simple elastic time intervals as 347 follows: 349 [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn] 350 where -P <= Xi <= Q, i = 0, 1, 2, ..., n. 352 If a user wants to keep the same repeat cycle between any two 353 adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n 354 times with repeat cycle C within -P and Q SYNC" may be used, which 355 represents n+1 simple elastic time intervals as follows: 357 [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X] 358 where -P <= X <= Q. 360 4.2.2.2. Graceful Periods 362 Besides the stated time scheduling, a user may want to have some 363 graceful periods for each or some of the time intervals for the LSP. 364 Two graceful periods may be configured for a time interval. One is 365 the graceful period before the time interval, called grace-before, 366 which extends the lifetime of the LSP for grace-before (such as 30 367 seconds) before the time interval. The other is the one after the 368 time interval, called grace-after, which extends the lifetime of the 369 LSP for grace-after (such as 60 seconds) after the time interval. 371 When an LSP is configured with a simple time interval such as [Ta, 372 Tb] with graceful periods such as grace-before GB and grace-after GA, 373 a path is computed such that the path satisfies the constraints for 374 the LSP in the time period from Ta to Tb. The LSP along the path is 375 set up to carry traffic in the time period from (Ta-GB) to (Tb+GA). 376 During graceful periods from (Ta-GB) to Ta and from Tb to (Tb+GA), 377 the LSP is up to carry traffic (maybe in best effort). 379 4.3. Scheduled LSP creation 381 In order to realize PCC-Initiated scheduled LSP in a centralized 382 network environment, a PCC has to separate the setup of a LSP into 383 two steps. The first step is to request/delegate and get a LSP but 384 not signal it over the network. The second step is to signal the 385 scheduled LSP over the LSRs (Labeled switched Router) at its starting 386 time. 388 For PCC-Initiated scheduled LSPs, a PCC can delegate the scheduled 389 LSP by sending a path computation report (PCRpt) message by including 390 its demanded resources with the scheduling information to a stateful 391 PCE. Note the PCC MAY use the PCReq/PCRep with scheduling 392 information before delegating. 394 Upon receiving the delegation via PCRpt message, the stateful PCE 395 computes the path for the scheduled LSP per its starting time and 396 duration based on the network resource availability stored in 397 scheduled TED (see section 4.1). 399 The stateful PCE will send a PCUpd message with the scheduled path 400 information as well as the scheduled resource information for the 401 scheduled LSP to the PCC. The PCE SHOULD add the scheduled LSP into 402 its scheduled LSP DB and update its scheduled TED. The PCE SHOULD 403 also synchronize to other PCEs within the network if there is any, so 404 as to keep their scheduling information synchronized as per 405 [I-D.litkowski-pce-state-sync]. 407 For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path 408 for the scheduled LSP per requests from network management systems 409 automatically based on the network resource availability in the 410 scheduled TED, send a PCInitiate message with the path information 411 back to the PCC. Based on the local policy, the PCInitiate message 412 could be sent immediately to ask PCC to create a scheduled LSP (as 413 per this document) or the PCInitiate message could be sent at the 414 start time to the PCC to create a normal LSP (as per [I-D.ietf-pce- 415 pce-initiated-lsp]). 417 In both modes: 419 o The stateful PCE is required to update its local scheduled LSP DB 420 and scheduled TED with the scheduled LSP. Besides, it shall send 421 a PCRpt message with the scheduled LSP to other PCEs within the 422 network, so as to achieve the scheduling traffic engineering 423 information synchronization as per [I-D.litkowski-pce-state-sync]. 425 o Upon receiving the PCUpd message or PCInitiate message for the 426 scheduled LSP from PCEs with a found path, the PCC knows that it 427 is a scheduled path for the LSP and does not trigger signaling for 428 the LSP setup on LSRs. 430 o The stateful PCE can update the Scheduled LSP parameters on any 431 network events using the PCUpd message to PCC. These changes are 432 also synchronized to other PCEs as per 433 [I-D.litkowski-pce-state-sync]. 435 o Based on the configuration (and the C flag in scheduled TLVs), 436 when it is time (i.e., at the start time) for the LSP to be set 437 up, either the PCC triggers the LSP to be signaled or the 438 delegated PCE sends a PCUpd message to the head end LSR providing 439 the updated path to be signaled (with A flag set to indicate LSP 440 activation). 442 4.4. Scheduled LSP Modifications 444 After a scheduled LSP is configured, a user may change its parameters 445 including the requested time as well as the bandwidth. 447 In PCC-Initiated case, the PCC can send a PCRpt message for the 448 scheduled LSP with updated parameters as well as scheduled 449 information included in the SCHED-LSP-ATTRIBUTE TLV (see 450 Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) 451 carried in the LSP Object. The PCE would take the updated resources 452 and schedule into considerations and update the new path for the 453 scheduled LSP to the PCC as well as synchronize to other PCEs in the 454 network. In case path cannot be set based on new requirements the 455 same should be conveyed by the use of empty ERO in the PCEP messages. 457 In PCE-Initiated case, the Stateful PCE would recompute the path 458 based on updated parameters as well as scheduled information. In 459 case it has already conveyed to the PCC this information by sending a 460 PCInitiate message, it should update the path and other scheduling 461 and resource information by sending a PCUpd message. 463 In any case, the scheduled databases SHALL be updated and the PCE 464 MUST synchronize this information to other PCEs as per 465 [I-D.litkowski-pce-state-sync]. 467 4.5. Scheduled LSP activation and deletion 469 In PCC-Initiated case, based on the configuration (and the C flag in 470 scheduled TLVs), when it is time (i.e., at the start time) for the 471 LSP to be set up, either the PCC triggers the LSP to be signaled or 472 the delegated PCE sends a PCUpd message to the head end LSR providing 473 the updated path to be signaled (with A flag set to indicate LSP 474 activation). The PCC would report the status of the active LSP as 475 per the procedures in [RFC8231] and at this time the LSP MUST be 476 considered as part of the LSP-DB. The A flag MUST be set in the 477 scheduled TLVs to indicate that the LSP is active now. After the 478 scheduled duration expires, based on the C flag, the PCC triggers the 479 LSP deletion on it self or the delegated PCE sends a PCUpd message to 480 the PCC to delete the LSP as per the procedures in [RFC8231]. 482 In PCE-Initiated case, based on the local policy, if the scheduled 483 LSP is already conveyed to the PCC at the time of creation, the 484 handling of LSP activation and deletion is handled in the same way as 485 PCC-Initiated case as per the setting of C flag. In other case, the 486 PCE would send the PCInitiate message at the start time to the PCC to 487 create a normal LSP without the scheduled TLVs and remove the LSP 488 after the duration expires as per [I-D.ietf-pce-pce-initiated-lsp]. 490 Additionally, the scheduled databases SHALL be updated and 491 synchronization to other PCEs MUST be done as per 492 [I-D.litkowski-pce-state-sync]. 494 5. PCEP Objects and TLVs 496 5.1. Stateful PCE Capability TLV 498 After a TCP connection for a PCEP session has been established, a PCC 499 and a PCE indicates its ability to support LSP scheduling during the 500 PCEP session establishment phase. For a multiple-PCE environment, 501 the PCEs should also establish PCEP session and indicate its ability 502 to support LSP scheduling among PCEP peers. The Open Object in the 503 Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in 504 [RFC8231]. Note that the STATEFUL- PCE-CAPABILITY TLV is defined in 505 [RFC8231] and updated in [I-D.ietf-pce-pce-initiated-lsp] and 506 [RFC8232]. In this document, we define a new flag bit B (SCHED-LSP- 507 CAPABLITY) flag for the STATEFUL- PCE-CAPABILITY TLV to indicate the 508 support of LSP scheduling and another flag bit PD (PD-LSP-CAPABLITY) 509 to indicate the support of LSP periodical scheduling. 511 B (LSP-SCHEDULING-CAPABILITY - 1 bit): If set to 1 by a PCC, the B 512 Flag indicates that the PCC allows LSP scheduling; if set to 1 by 513 a PCE, the B Flag indicates that the PCE is capable of LSP 514 scheduling. The B bit MUST be set by both PCEP peers in order to 515 support LSP scheduling for path computation. 517 PD (PD-LSP-CAPABLITY - 1 bit): If set to 1 by a PCC, the PD Flag 518 indicates that the PCC allows LSP scheduling periodically; if set 519 to 1 by a PCE, the PD Flag indicates that the PCE is capable of 520 periodical LSP scheduling. The PD bit MUST be set by both PCEP 521 peers in order to support periodical LSP scheduling for path 522 computation. 524 5.2. LSP Object 526 The LSP object is defined in [RFC8231]. This document add an 527 optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling and an 528 optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP scheduling. 530 The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates 531 that this LSP is requesting scheduled parameters while the SCHED-PD- 532 LSP-ATTRIBUTE TLV indicates that this scheduled LSP is periodical. 533 The scheduled LSP attribute TLV MUST be present in LSP Object for 534 each scheduled LSP carried in the PCEP messages. For periodical 535 LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in LSP Object for 536 each periodic scheduled LSP carried in the PCEP messages. 538 5.2.1. SCHED-LSP-ATTRIBUTE TLV 540 The SCHED-LSP-ATTRIBUTE TLV can be included as an optional TLV within 541 the LSP object for LSP scheduling for the requesting traffic service. 543 This TLV SHOULD be included only if both PCEP peers have set the B 544 (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV 545 carried in open message. 547 The format of the SCHED-LSP-ATTRIBUTE TLV is shown in the following 548 figure: 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type (TBD) | Length | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 |R|C|A| Flags | Reserved (0) | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Start-Time | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Duration | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | GrB | GrA | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Elastic-Lower-Bound | Elastic-Upper-Bound | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 The type of the TLV is [TBD] and the TLV has a fixed length of 20 567 octets. 569 The fields in the format are: 571 Flags (8 bits): Flowing flags are defined in this document 572 R (1 bit): Set to 1 to indicate the Start-Time is a relative 573 time, which is relative to the current time; set to 0 to 574 indicate the the Start-Time is an absolute time. 576 C (1 bit): Set to 1 to indicate the PCC is responsible to setup 577 and remove the scheduled LSP based on the Start-Time and 578 duration. 580 A (1 bit): Set to 1 to indicate the scheduled LSP has been 581 activated and should be considered as part of LSP-DB (instead 582 of Scheduled LSP-DB). 584 Reserved (24 bits): This field MUST be set to zero on transmission 585 and MUST be ignored on receipt. 587 Start-Time (32 bits): This value in seconds, indicates when the 588 scheduled LSP is used to carry traffic and the corresponding LSP 589 must be setup and activated. 591 Duration (32 bits): The value in seconds, indicates the duration 592 that the LSP is undertaken by a traffic flow and the corresponding 593 LSP must be up to carry traffic. At the expiry of this duration, 594 the LSP is tear down and deleted. 596 The Start-Time indicates a calendar time (e.g.,2018/12/13 8:29:58), 597 at or before which the scheduled LSP must be set up. The value of 598 the Start-Time represents the number of seconds since 00:00 hours,Jan 599 1, 1970 UTC when R bit is set to 0. When R bit is set to 1, it 600 represents the number of seconds from the current time. 602 In addition, it contains an non zero grace-before and grace-after if 603 graceful periods are configured. It includes an non zero elastic 604 range lower bound and upper bound if there is an elastic range 605 configured. 607 o GrB (Grace-Before -16 bits): The graceful period time length in 608 seconds before the starting time. 610 o GrA (Grace-After -16 bits): The graceful period time length in 611 seconds after time interval [starting time, starting time + 612 duration]. 614 o Elastic-Lower-Bound (16 bits): The maximum amount of time in 615 seconds that time interval can shift to lower/left. 617 o Elastic-Upper-Bound (16 bits): The maximum amount of time in 618 seconds that time interval can shift to upper/right. 620 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV 622 The periodical LSP is a special case of LSP scheduling. The traffic 623 service happens in a series of repeated time intervals. The SCHED- 624 PD-LSP-ATTRIBUTE TLV can be included as an optional TLV within the 625 LSP object for this periodical LSP scheduling. 627 This TLV SHOULD be included only if both PCEP peers have set the B 628 (LSP-SCHEDULING-CAPABILITY bit) and PD (PD-LSP-CAPABLITY bit) in 629 STATEFUL-PCE-CAPABILITY TLV carried in open message. 631 The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in the 632 following figure: 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type (TBD) | Length | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |R|C|A| Flags | Opt | NR | Reserved (0) | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Start-Time | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Duration | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Repeat-time-length | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | GrB | GrA | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Elastic-Lower-Bound | Elastic-Upper-Bound | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 The type of the TLV is [TBD] and the TLV has a fixed length of 24 653 octets. The description, format and meaning of the Flags (R, C and A 654 bit), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound and 655 Elastic-Upper-Bound fields remains same as SCHED-LSP-ATTRIBUTE TLV. 657 The following fields are new : 659 Opt: (4 bits) Indicates options to repeat. 661 Options = 1: repeat every day; 662 Options = 2: repeat every week; 664 Options = 3: repeat every month; 666 Options = 4: repeat every year; 668 Options = 5: repeat every Repeat-time-length. 670 NR:(4 bits) The number of repeats. In each of repeats, LSP carries 671 traffic. If value is set to 0xFFFF, it indicates forever. 673 Reserved (16 bits): This field MUST be set to zero on transmission 674 and MUST be ignored on receipt. 676 Repeat-time-length:(32 bits) The time length in seconds after which 677 LSP starts to carry traffic again for the Duration. 679 6. The PCEP Messages 681 6.1. The PCRpt Message 683 Path Computation State Report (PCRpt) is a PCEP message sent by a PCC 684 to a PCE to report the status of one or more LSPs as per [RFC8231]. 685 Each LSP State Report in a PCRpt message MAY contain the actual LSP's 686 path, bandwidth, operational and administrative status, etc. An LSP 687 Status Report carried on a PCRpt message is also used in delegation 688 or revocation of control of an LSP to/from a PCE. In case of 689 scheduled LSP, the scheduled TLVs MUST be carried in the LSP object 690 and the ERO conveys the intended path for the scheduled LSP. The 691 scheduled LSP MUST be delegated to a PCE. This message is also used 692 to synchronize the scheduled LSPs to other PCE as described in 693 [I-D.litkowski-pce-state-sync]. 695 6.2. The PCUpd Message 697 Path Computation Update Request (PCUpd) is a PCEP message sent by a 698 PCE to a PCC to update LSP parameters, on one or more LSPs as per 699 [RFC8231]. Each LSP Update Request on a PCUpd message MUST contain 700 all LSP parameters that a PCE wishes to be set for a given LSP. In 701 case of scheduled LSP, the scheduled TLVs MUST be carried in the LSP 702 object and the ERO conveys the intended path for the scheduled LSP. 703 In case no path can be found, an empty ERO is used. The A bit is 704 used in PCUpd message to indicate the activation of the scheduled LSP 705 in case the PCE is responsible for the activation (as per the C bit). 706 This message is also used to synchronize the scheduled LSPs to other 707 PCE as described in [I-D.litkowski-pce-state-sync]. 709 6.3. The PCInitiate Message 711 An LSP Initiate Request (PCInitiate) message is a PCEP message sent 712 by a PCE to a PCC to trigger LSP instantiation or deletion as per [I- 713 D.ietf-pce-pce-initiated-lsp]. In case of scheduled LSP, based on 714 the local policy, PCE MAY convey the scheduled LSP to the PCC by 715 including the scheduled TLVs in the LSP object. Or the PCE would 716 initiate the LSP only at the start time of the scheduled LSP as per 717 the [I-D.ietf-pce-pce-initiated-lsp] without the use of scheduled 718 TLVs. 720 6.4. The PCReq message 722 The Path Computation Request (PCReq) message is a PCEP message sent 723 by a PCC to a PCE to request a path computation [RFC5440] and it MAY 724 contain the LSP object to identify the LSP for which the path 725 computation is requested. In case of scheduled LSP, the scheduled 726 TLVs MUST be carried in the LSP object in PCReq message to request 727 the path computation based on scheduled TED and LSP-DB. A PCC MAY 728 use PCReq message to obtain the scheduled path before delegating the 729 LSP. 731 6.5. The PCRep Message 733 The Path Computation Reply (PCRep) message is a PCEP message sent by 734 a PCE to a PCC in reply to a path computation request [RFC5440]. A 735 PCRep message can contain either a set of computed paths if the 736 request can be satisfied, or a negative reply if not. The negative 737 reply may indicate the reason why no path could be found. In case of 738 scheduled LSP, the scheduled TLVs MUST be carried in the LSP object 739 in PCRep message to indicate the path computation based on scheduled 740 TED and LSP-DB. A PCC and PCE MAY use PCReq and PCRep message to 741 obtain the scheduled path before delegating the LSP. 743 6.6. The PCErr Message 745 [Editor's Note - Error Handling will be taken up in the next revision 746 of the draft] 748 7. Security Considerations 750 This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED- LSP- 751 ATTRIBUTE TLV which does not add any new security concerns beyond 752 those discussed in [RFC5440] and [RFC8231]. But in some deployments 753 the scheduling information could provide details about the network 754 operations that could be deemed as extra sensitive. Additionally, 755 snooping of PCEP messages with such data or using PCEP messages for 756 network reconnaissance may give an attacker sensitive information 757 about the operations of the network. Thus, such deployment should 758 employ suitable PCEP security mechanisms like TCP Authentication 759 Option (TCP-AO) [RFC5925] or [I-D.ietf-pce-pceps]. The procedure 760 based on Transport Layer Security (TLS) in [I-D.ietf-pce-pceps] is 761 considered a security enhancement and thus is much better suited for 762 the sensitive service-aware information. 764 8. Manageability Consideration 766 8.1. Control of Function and Policy 768 The LSP-Scheduling feature MUST BE controlled per tunnel by the 769 active stateful PCE, the values for parameters like starting time, 770 duration SHOULD BE configurable by customer applications and based on 771 the local policy at PCE. 773 8.2. Information and Data Models 775 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 776 this document. 778 8.3. Liveness Detection and Monitoring 780 Mechanisms defined in this document do not imply any new liveness 781 detection and monitoring requirements in addition to those already 782 listed in [RFC5440]. 784 8.4. Verify Correct Operations 786 Mechanisms defined in this document do not imply any new operation 787 verification requirements in addition to those already listed in 788 [RFC5440]. 790 8.5. Requirements On Other Protocols 792 Mechanisms defined in this document do not imply any new requirements 793 on other protocols. 795 8.6. Impact On Network Operations 797 Mechanisms defined in this document do not have any impact on network 798 operations in addition to those already listed in [RFC5440]. 800 9. IANA Considerations 801 9.1. PCEP TLV Type Indicators 803 This document defines the following new PCEP TLV. IANA maintains a 804 sub-registry "PCEP TLV Type Indicators" in the "Path Computation 805 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 806 the following allocations from this sub-registry. 808 Value Meaning Reference 809 TBD SCHED-LSP-ATTRIBUTE This document 810 TBD SCHED-PD-LSP-ATTRIBUTE This document 812 9.2. STATEFUL-PCE-CAPABILITY TLV Flag field 814 This document defines new bits in the Flags field in the STATEFUL- 815 PCE-CAPABILITY TLV in the OPEN object. IANA maintains a sub-registry 816 "STATEFUL-PCE-CAPABILITY TLV Flag Field" in the "Path Computation 817 Element Protocol (PCEP) Numbers" registry. IANA is requested to make 818 the following allocations from this sub-registry. 820 The following values are defined in this document: 822 Bit Description Reference 823 TBD LSP-SCHEDULING-CAPABILITY (B-bit) This document 824 TBD PD-LSP-CAPABLITY (PD-bit) This document 826 9.3. Schedule TLVs Flag Field 828 IANA is requested to create a new subregistry, named "Schedule TLVs 829 Flag Field", within the "Path Computation Element Protocol (PCEP) 830 Numbers" registry to manage the Flag field in the SCHED-LSP-ATTRIBUTE 831 and SCHED-PD-LSP-ATTRIBUTE TLVs. New values are assigned by 832 Standards Action [RFC8126]. Each bit should be tracked with the 833 following qualities: 835 o Bit number (counting from bit 0 as the most significant bit) 837 o Capability description 839 o Defining RFC 841 The following values are defined in this document: 843 Bit Description Reference 844 0 R-bit This document 845 1 C-bit This document 846 1 A-bit This document 848 10. Acknowledgments 850 The authors of this document would also like to thank Rafal Szarecki, 851 Adrian Farrel, Cyril Margaria for the review and comments. 853 11. References 855 11.1. Normative References 857 [I-D.ietf-pce-pce-initiated-lsp] 858 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 859 Extensions for PCE-initiated LSP Setup in a Stateful PCE 860 Model", draft-ietf-pce-pce-initiated-lsp-11 (work in 861 progress), October 2017. 863 [I-D.ietf-pce-stateful-pce-auto-bandwidth] 864 Dhody, D., Palle, U., Singh, R., Gandhi, R., and L. Fang, 865 "PCEP Extensions for MPLS-TE LSP Automatic Bandwidth 866 Adjustment with Stateful PCE", draft-ietf-pce-stateful- 867 pce-auto-bandwidth-05 (work in progress), April 2017. 869 [I-D.ietf-teas-scheduled-resources] 870 Zhuangyan, Z., Wu, Q., Chen, H., and A. Farrel, 871 "Architecture for Scheduled Use of Resources", draft-ietf- 872 teas-scheduled-resources-03 (work in progress), June 2017. 874 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 875 Requirement Levels", BCP 14, RFC 2119, 876 DOI 10.17487/RFC2119, March 1997, 877 . 879 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 880 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 881 DOI 10.17487/RFC5440, March 2009, 882 . 884 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 885 Writing an IANA Considerations Section in RFCs", BCP 26, 886 RFC 8126, DOI 10.17487/RFC8126, June 2017, 887 . 889 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 890 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 891 May 2017, . 893 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 894 Computation Element Communication Protocol (PCEP) 895 Extensions for Stateful PCE", RFC 8231, 896 DOI 10.17487/RFC8231, September 2017, 897 . 899 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 900 and D. Dhody, "Optimizations of Label Switched Path State 901 Synchronization Procedures for a Stateful PCE", RFC 8232, 902 DOI 10.17487/RFC8232, September 2017, 903 . 905 11.2. Informative References 907 [I-D.ietf-pce-pceps] 908 Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure 909 Transport for PCEP", draft-ietf-pce-pceps-18 (work in 910 progress), September 2017. 912 [I-D.litkowski-pce-state-sync] 913 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 914 Stateful Path Computation Element communication 915 procedures", draft-litkowski-pce-state-sync-02 (work in 916 progress), August 2017. 918 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 919 IANA Considerations Section in RFCs", RFC 5226, 920 DOI 10.17487/RFC5226, May 2008, 921 . 923 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 924 Computation Element Architecture", RFC 7399, 925 DOI 10.17487/RFC7399, October 2014, 926 . 928 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 929 Hardwick, "Path Computation Element Communication Protocol 930 (PCEP) Management Information Base (MIB) Module", 931 RFC 7420, DOI 10.17487/RFC7420, December 2014, 932 . 934 Appendix A. Scheduled LSP information synchronization 936 As for a stateful PCE, it maintains a database of LSPs (LSP-DB) that 937 are active in the network, so as to reveal the available network 938 resources and place new LSPs more cleverly. 940 With the scheduled LSPs, they are not activated while creation, but 941 should be considered when operating future path computation. Hence, 942 a scheduled LSP Database (SLSP-DB) is suggested to maintain all 943 scheduled LSP information. 945 The information of SLSP-DB MUST be shared and synchronized among all 946 PCEs within the centralized network by using PCRpt and PCUpd message 947 with scheduled LSP information as per the mechanism described in [I- 948 D.litkowski-pce-state-sync]. 950 The PCE should generate and maintain a scheduled TED based on LSP DB, 951 scheduled LSP DB and TED, which is used to indicate the network 952 resource availability on network nodes for LSP path computation. 954 Appendix B. Contributor Addresses 955 Xufeng Liu 956 Ericsson 957 USA 958 Email: xliu@kuatrotech.com 960 Mehmet Toy 961 Verizon 962 USA 963 Email: mehmet.toy@verizon.com 965 Vic Liu 966 China Mobile 967 No.32 Xuanwumen West Street, Xicheng District 968 Beijing, 100053 969 China 970 Email: liu.cmri@gmail.com 972 Lei Liu 973 Fujitsu 974 USA 975 Email: lliu@us.fujitsu.com 977 Khuzema Pithewan 978 Infinera 979 Email: kpithewan@infinera.com 981 Zitao Wang 982 Huawei 983 101 Software Avenue, Yuhua District 984 Nanjing, Jiangsu 210012 985 China 987 Email: wangzitao@huawei.com 989 Xian Zhang 990 Huawei Technologies 991 Research Area F3-1B, 992 Huawei Industrial Base, 993 Shenzhen, 518129, China 995 Email: zhang.xian@huawei.com 997 Authors' Addresses 998 Huaimo Chen (editor) 999 Huawei 1000 Boston, MA 1001 USA 1003 Email: huaimo.chen@huawei.com 1005 Yan Zhuang (editor) 1006 Huawei 1007 101 Software Avenue, Yuhua District 1008 Nanjing, Jiangsu 210012 1009 China 1011 Email: zhuangyan.zhuang@huawei.com 1013 Qin Wu 1014 Huawei 1015 101 Software Avenue, Yuhua District 1016 Nanjing, Jiangsu 210012 1017 China 1019 Email: bill.wu@huawei.com 1021 Dhruv Dhody 1022 Huawei 1023 Divyashree Techno Park, Whitefield 1024 Bangalore, Karnataka 560066 1025 India 1027 Email: dhruv.ietf@gmail.com 1029 Daniele Ceccarelli 1030 Ericsson 1031 Via A. Negrone 1/A 1032 Genova - Sestri Ponente 1033 Italy 1035 Email: daniele.ceccarelli@ericsson.com