idnits 2.17.1 draft-peng-pce-te-constraints-03.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 (June 1, 2020) is 1424 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) == Outdated reference: A later version (-06) exists of draft-barth-pce-segment-routing-policy-cp-05 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-15 == Outdated reference: A later version (-19) exists of draft-ietf-isis-te-app-13 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE S. Peng 3 Internet-Draft Q. Xiong 4 Intended status: Standards Track ZTE Corporation 5 Expires: December 3, 2020 F. Qin 6 China Mobile 7 June 1, 2020 9 PCE TE Constraints for Network Slicing 10 draft-peng-pce-te-constraints-03 12 Abstract 14 This document proposes a set of extensions for PCEP to support the TE 15 constraints of network slicing during path computation, e.g, IGP 16 instance, virtual network, specific application, color template and 17 FA-id etc. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 3, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 3 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. PCEP Extensions for TE Constraints in Network Slicing . . . . 3 58 3.1. Source Protocol TLV . . . . . . . . . . . . . . . . . . . 3 59 3.2. Multi-topology TLV . . . . . . . . . . . . . . . . . . . 4 60 3.3. The AII TLV . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Application Specific TLV . . . . . . . . . . . . . . . . 6 62 3.5. The Color TLV . . . . . . . . . . . . . . . . . . . . . . 7 63 3.6. The FA-id TLV . . . . . . . . . . . . . . . . . . . . . . 8 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 [RFC5440] describes the Path Computation Element Protocol (PCEP) 73 which is used between a Path Computation Element (PCE) and a Path 74 Computation Client (PCC) (or other PCE) to enable computation of 75 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 76 Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model 77 [RFC8231] describes a set of extensions to PCEP to enable active 78 control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. As depicted 79 in [RFC4655], a PCE MUST be able to compute the path of a TE LSP by 80 operating on the TED and considering bandwidth and other constraints 81 applicable to the TE LSP service request. The constraint parameters 82 are provided such as metric, bandwidth, delay, affinity, etc. 83 However these parameters can't meet the network slicing requirements. 85 According to 5G context, network slicing is the collection of a set 86 of technologies to support network service differentiation and 87 meeting the diversified requirements from vertical industries. The 88 slices may be seen as virtual networks and partition the network 89 resources into sub-topologies in transport network. Multiple 90 existing identifiers could be used to identify the virtual network 91 resource and viewed as constraints of network slicing when PCE is 92 deployed. 94 A PCE always perform path computation based on the network topology 95 information collected through BGP-LS [RFC7752]. BGP-LS can get 96 multiple link-state data from multiple IGP instance, or multiple 97 virtual topologies from a single IGP instance. It is necessary to 98 restrict the PCE to a small topology scope during path computation 99 for some special purpose. BGP-LS can also get application specific 100 TE attributes for a link, it is also necessary to restrict PCE to use 101 TE attributes of specific application The PCE MUST take the 102 identifier of slicing into consideration during path computation. 104 This document proposes a set of extensions for PCEP to support the TE 105 constraints for network slicing during path computation, e.g, IGP 106 instance, virtual network, specific application, color template and 107 FA-id etc. 109 2. Conventions used in this document 111 2.1. Terminology 113 The terminology is defined as [RFC5440] and [RFC7752]. 115 2.2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. PCEP Extensions for TE Constraints in Network Slicing 125 As defined in [RFC5440] , the LSPA object is used to specify the LSP 126 attributes to be taken into account by the PCE during path 127 computation such as TE constraints. This document proposes several 128 new TLVs for the LSPA object to carry TE constraints in Network 129 Slicing. 131 3.1. Source Protocol TLV 133 The Source Protocol TLV is optional and is defined to carry the 134 source protocol constraint. 136 In a PCReq message, a PCC MAY insert one Source Protocol TLV to 137 indicate the source protocol that MUST be considered by the PCE. The 138 PCE will perform path computation based on the sub-topology 139 identified by the specific source protocol. The absence of the 140 Source Protocol TLV MUST be interpreted by the PCE as a path 141 computation request for which no constraints need be applied to any 142 of the source protocols. 144 In a PCRep/PCInit/PCUpd message, the Source Protocol TLV MAY be 145 carried so as to provide the source protocol information for the 146 computed path. 148 The format of the Source Protocol TLV is shown as Figure 1: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type=TBD1 | Length=12 | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Protocol-ID | Reserved | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Identifier | 158 | (64 bits) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: Source Protocol TLV 163 The code point for the TLV type is TBD1. The TLV length is 12 164 octets. 166 Protocol-ID (8 bits): defined in [RFC7752] section 3.2. 168 Reserved (24 bits): This field MUST be set to zero on transmission 169 and MUST be ignored on receipt. 171 Identifier (64 bits): defined in [RFC7752] section 3.2. 173 3.2. Multi-topology TLV 175 The Multi-topology TLV is optional and is defined to carry the multi- 176 topology protocol constraint. 178 In a PCReq message, a PCC MAY insert one Multi-topology TLV to 179 indicate the sub-topology of an IGP instance that MUST be considered 180 by the PCE. The PCE will perform path computation based on the sub- 181 topology identified by the specific Multi-Topology ID within a source 182 protocol. The absence of the Multi-topology TLV MUST be interpreted 183 by the PCE as a path computation request for which no constraints 184 need be applied to any of the multi-topologies. 186 In a PCRep/PCInit/PCUpd message, the Multi-topology TLV MAY be 187 carried so as to provide the Multi-topology information for the 188 computed path. 190 The Multi-topology TLV MUST be carried after a Source Protocol TLV, 191 if not it MUST be ignored. 193 The format of the Multi-topology TLV is shown as Figure 2: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type=TBD2 | Length=4 | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |R R R R| Multi-Topology ID | Reserved | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 2: Multi-topology TLV 205 The code point for the TLV type is TBD2. The TLV length is 4 octets. 207 Multi-Topology ID (12 bits): Semantics of the IS-IS MT-ID are defined 208 in Section 7.2 of [RFC5120]. Semantics of the OSPF MT-ID are defined 209 in Section 3.7 of [RFC4915]. If the value is derived from OSPF, then 210 the upper 9 bits MUST be set to 0. Bits R are reserved and SHOULD be 211 set to 0 when originated and ignored on receipt. 213 Reserved (16 bits): This field MUST be set to zero on transmission 214 and MUST be ignored on receipt. 216 3.3. The AII TLV 218 Administrative Instance Identifier (AII) is provided to specify the 219 TE purpose within a virtual network as per 220 [I-D.peng-lsr-network-slicing]. The AII TLV is optional and is 221 defined to carry the AII constraint. 223 In a PCReq message, a PCC MAY insert one AII TLV to indicate the 224 global virtual network that MUST be considered by the PCE. The PCE 225 will perform path computation based on the intra-domain or inter- 226 domain sub-topology identified by the specific AII, which is 227 independent of routing protocols such as IGP/BGP. The absence of the 228 AII TLV MUST be interpreted by the PCE as a path computation request 229 for which no constraints need be applied to any of the virtual 230 network, i.e, a default AII (0) will be applied. 232 In a PCRep/PCInit/PCUpd message, the AII TLV MAY be carried so as to 233 provide the network slicing information for the computed path. 235 The format of the AII TLV is shown as Figure 3: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type=TBD3 | Length=4 | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | AII | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 3: AII TLV 247 The code point for the TLV type is TBD3. The TLV length is 4 octets. 249 AII (32 bits): indicate the AII information as defined in 250 [I-D.peng-lsr-network-slicing]. 252 3.4. Application Specific TLV 254 The Application Specific TLV is optional and is defined to carry the 255 application specific constraints. 257 In a PCReq message, a PCC MAY insert one Application Specific TLV to 258 indicate the application that MUST be considered by the PCE. The PCE 259 will perform path computation using the specific application 260 attributes. The absence of the Application Specific TLV MUST be 261 interpreted by the PCE as a path computation request for which no 262 constraints need be applied to any of the Application Specific 263 attributes. 265 In a PCRep/PCInit/PCUpd message, the Application Specific TLV MAY be 266 inserted so as to provide the Application Specific information for 267 the computed path. 269 The format of the Application Specific TLV is shown as Figure 4: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type=TBD4 | Length=8 | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Standard Application ID | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | User Defined Application ID | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 4: Application Specific TLV 283 The code point for the TLV type is TBD4. The TLV length is 8 octets. 285 Standard Application ID: Represents a bit-position value for a single 286 STANDARD application that is defined in the IANA "IGP Parameters" 287 registries under the "Link Attribute Applications" registry 288 [I-D.ietf-isis-te-app]. 290 User Defined Application ID: Represents a single user defined 291 application which is a specific implementation. 293 3.5. The Color TLV 295 The Color TLV is optional and is defined to carry the color 296 constraints. 298 In a PCReq message, a PCC MAY insert one Color TLV to indicate the 299 traffic engineering purpose that is recognized by both PCE and PCC 300 with no conflict meaning. The PCE will perform path computation 301 based on the color template. The same color template may be also 302 defined at PCC and the existing constraints (i.e, metric, bandwidth, 303 delay, etc) carried in the message MUST be ignored. The absence of 304 the Color TLV MUST be interpreted by the PCE as a path computation 305 request for which traditional constraints that are contained in 306 message need be applied. 308 In a PCRep/PCInit/PCUpd message, the Color TLV MAY be inserted so as 309 to provide the TE purpose information for the computed path, the PCC 310 recognize the color value that match a local color-template. 312 The format of the Color TLV is shown as Figure 5: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type=TBD5 | Length=4 | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Color | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 5: Color TLV 324 The code point for the TLV type is TBD5. The TLV length is 4 octets. 326 Color (32 bits): indicate a TE template, 0 is invalid value. It is 327 consistent with the Color Extended Community defined in 329 [I-D.ietf-idr-tunnel-encaps], and color of SR policy defined in 330 [I-D.ietf-spring-segment-routing-policy]. 332 Note that Color TLV defined in this document is used to represent a 333 TE template, it can be suitable for any TE instance such as RSVP-TE, 334 SR-TE, SR-policy. [I-D.barth-pce-segment-routing-policy-cp] has 335 proposed the SR policy KEY (that also includes a color information) 336 as an association group KEY to associate many candidate paths, 337 however it is only for association purpose but not constraint purpose 338 for path computation. 340 A color template can be defined to use existing constraints such as 341 metric, bandwidth, delay, affinity parameters, and the sub-topology 342 constraints above defined in this document. 344 3.6. The FA-id TLV 346 FA-id defined in [I-D.ietf-lsr-flex-algo] is a short mapping of SR 347 policy color to optimize segment stack depth for the IGP area partial 348 of the entire SR policy. The overlay service that want to be carried 349 over a particular SR-FA path must firstly let the SR policy supplier 350 know that requirement. There are two possible ways to map a color to 351 an FA-id. One is explicit mapping configuration within color 352 template, the other is dynamicly replacing a long segment list to 353 short FA segment by headend or controller once the information 354 contained in the color-template equal to that contained in FAD. 356 In a PCReq message, a PCC MAY insert one FA-id TLV to indicate the 357 above explicit FA-id mapping. The PCE will perform path computation 358 based on the FA-id. In detailed, The PCE will check if there are 359 connectivity within the corresponding Flex-algo plane to the 360 destination. If yes, the path computation result will be represented 361 as segment list with a single prefix-SID@FA for intra-domain case, or 362 several prefix-SID@FA for inter-domain case. 364 In a PCRep/PCInit/PCUpd message, the FA-id TLV MAY be inserted so as 365 to provide the FA plane information for the computed path. 367 In general, the FA-id TLV is only meaningful for the domain that 368 headend node belongs to. For inter-domain case, operator MUST ensure 369 the FA-id configuration of different domain are same for an E2E 370 slice, when he want to explicitly indicate FA-id in PCEP message. 372 The format of the FA-id TLV is shown as Figure 6: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type=TBD6 | Length=4 | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | FA-id | Reserved | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 6: FA-id TLV 384 The code point for the TLV type is TBD6. The TLV length is 4 octets. 386 FA-id (8 bits): indicate an explicit FA-id mapping information. 388 4. Security Considerations 390 TBA 392 5. Acknowledgements 394 TBA 396 6. IANA Considerations 398 IANA is requested to make allocations from the registry, as follows: 400 +--------+----------------------------+------------------+ 401 | Type | TLV | Reference | 402 +--------+----------------------------+------------------+ 403 | TBD1 | Source Protocol TLV | [this document] | 404 | TBD2 | Multi-topology TLV | [this document] | 405 | TBD3 | AII TLV | [this document] | 406 | TBD4 | Application Specific TLV | [this document] | 407 | TBD5 | Color TLV | [this document] | 408 | TBD6 | FA-id TLV | [this document] | 409 +--------+----------------------------+------------------+ 411 Table 1 413 7. Normative References 415 [I-D.barth-pce-segment-routing-policy-cp] 416 Koldychev, M., Sivabalan, S., Barth, C., Li, C., and H. 417 Bidgoli, "PCEP extension to support Segment Routing Policy 418 Candidate Paths", draft-barth-pce-segment-routing-policy- 419 cp-05 (work in progress), May 2020. 421 [I-D.ietf-idr-tunnel-encaps] 422 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 423 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 424 (work in progress), December 2019. 426 [I-D.ietf-isis-te-app] 427 Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 428 J. Drake, "IS-IS TE Attributes per application", draft- 429 ietf-isis-te-app-13 (work in progress), May 2020. 431 [I-D.ietf-lsr-flex-algo] 432 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 433 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 434 algo-07 (work in progress), April 2020. 436 [I-D.ietf-spring-segment-routing-policy] 437 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 438 P. Mattes, "Segment Routing Policy Architecture", draft- 439 ietf-spring-segment-routing-policy-07 (work in progress), 440 May 2020. 442 [I-D.peng-lsr-network-slicing] 443 Peng, S., Chen, R., and G. Mirsky, "Packet Network Slicing 444 using Segment Routing", draft-peng-lsr-network-slicing-00 445 (work in progress), February 2019. 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, 449 DOI 10.17487/RFC2119, March 1997, 450 . 452 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 453 Element (PCE)-Based Architecture", RFC 4655, 454 DOI 10.17487/RFC4655, August 2006, 455 . 457 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 458 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 459 RFC 4915, DOI 10.17487/RFC4915, June 2007, 460 . 462 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 463 Topology (MT) Routing in Intermediate System to 464 Intermediate Systems (IS-ISs)", RFC 5120, 465 DOI 10.17487/RFC5120, February 2008, 466 . 468 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 469 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 470 DOI 10.17487/RFC5440, March 2009, 471 . 473 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 474 S. Ray, "North-Bound Distribution of Link-State and 475 Traffic Engineering (TE) Information Using BGP", RFC 7752, 476 DOI 10.17487/RFC7752, March 2016, 477 . 479 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 480 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 481 May 2017, . 483 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 484 Computation Element Communication Protocol (PCEP) 485 Extensions for Stateful PCE", RFC 8231, 486 DOI 10.17487/RFC8231, September 2017, 487 . 489 Authors' Addresses 491 Shaofu Peng 492 ZTE Corporation 493 No.50 Software Avenue 494 Nanjing, Jiangsu 210012 495 China 497 Email: peng.shaofu@zte.com.cn 499 Quan Xiong 500 ZTE Corporation 501 No.6 Huashi Park Rd 502 Wuhan, Hubei 430223 503 China 505 Email: xiong.quan@zte.com.cn 507 Fengwei Qin 508 China Mobile 509 Beijing 510 China 512 Email: qinfengwei@chinamobile.com