idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 66 characters in excess of 72. ** The abstract seems to contain references ([Stateful-PCE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 40 has weird spacing: '... months and ...' == Line 41 has weird spacing: '... at any time...' == Line 42 has weird spacing: '...ference mate...' -- The document date (July 3, 2014) is 3577 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: 'Stateful-PCE' is mentioned on line 512, but not defined == Missing Reference: 'RFC 4655' is mentioned on line 103, but not defined == Missing Reference: 'RFC 5440' is mentioned on line 113, but not defined == Missing Reference: 'RFC5521' is mentioned on line 435, but not defined == Unused Reference: 'RFC5089' is defined on line 539, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Xian Zhang 2 Internet-Draft Young Lee 3 Intended status: Standards Track Fatai Zhang 4 Huawei 5 Ramon Casellas 6 CTTC 7 Oscar Gonzalez de Dios 8 Telefonica I+D 9 Zafar Ali 10 Cisco Systems 12 Expires: January 3, 2015 July 3, 2014 14 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 15 Usage in GMPLS-controlled Networks 17 draft-ietf-pce-pcep-stateful-pce-gmpls-01.txt 19 Abstract 21 The Path Computation Element (PCE) facilitates Traffic Engineering 22 (TE) based path calculation in large, multi-domain, multi-region, or 23 multi-layer networks. [Stateful-PCE] provides the fundamental PCE 24 communication Protocol (PCEP) extensions needed to support stateful 25 PCE functions, without specifying the technology-specific extensions. 26 This memo provides extensions required for PCEP so as to enable the 27 usage of a stateful PCE capability in GMPLS-controlled networks. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with 32 the provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other 41 documents at any time. It is inappropriate to use Internet-Drafts 42 as reference material or to cite them other than as "work in 43 progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt. 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 This Internet-Draft will expire on January 3, 2015. 53 Copyright Notice 55 Copyright (c) 2014 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 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided without 66 warranty as described in the Simplified BSD License. 68 Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC-2119 [RFC2119]. 74 Table of Contents 76 Table of Contents .............................................. 2 77 1. Introduction ................................................ 3 78 2. PCEP Extensions ............................................. 4 79 2.1. Overview of Requirements................................ 4 80 2.2. Stateful PCE Capability Advertisement ................... 4 81 2.2.1. PCE Capability Advertisement in Multi-layer Networks 5 82 2.3. LSP Delegation in GMPLS-controlled Networks ............. 6 83 2.4. LSP Synchronization in GMPLS-controlled Networks......... 6 84 2.5. Modification of Existing PCEP Messages and Procedures .... 8 85 2.5.1. Use cases ......................................... 9 86 2.5.2. Modification for LSP Re-optimization ...............9 87 2.5.3. Modification for Route Exclusion .................. 10 88 3. IANA Considerations ........................................ 11 89 3.1. New PCEP Error Codes................................... 11 90 3.2. New Subobject for the Exclude Route Object .............11 91 4. Manageability Considerations................................ 12 92 4.1. Requirements on Other Protocols and Functional Components12 93 5. Security Considerations..................................... 12 94 6. Acknowledgement ............................................ 12 95 7. References ................................................. 12 96 7.1. Normative References................................... 12 97 7.2. Informative References................................. 13 98 8. Contributors' Address....................................... 13 99 Authors' Addresses ............................................ 14 101 1. Introduction 103 [RFC 4655] presents the architecture of a Path Computation Element 104 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 105 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 106 Paths (TE LSPs). To perform such a constrained computation, a PCE 107 stores the network topology (i.e., TE links and nodes) and resource 108 information (i.e., TE attributes) in its TE Database (TED). Such a 109 PCE is usually referred as a stateless PCE. To request path 110 computation services to a PCE, [RFC 5440] defines the PCE 111 communication Protocol (PCEP) for interaction between a Path 112 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 113 specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP 114 extensions needed for GMPLS-controlled networks are provided in 115 [PCEP-GMPLS]. 117 Stateful PCEs are shown to be helpful in many application scenarios, 118 in both MPLS and GMPLS networks, as illustrated in [Stateful-APP]. 119 In order for these applications to able to exploit the capability of 120 stateful PCEs, extensions to PCEP are required. 122 [Stateful-PCE] provides the fundamental extensions needed for 123 stateful PCE to support general functionality, but leaves out the 124 specification for technology-specific objects/TLVs. Complementarily, 125 this document focuses on the extensions that are necessary in order 126 for the deployment of stateful PCEs in GMPLS-controlled networks. 128 2. PCEP Extensions 130 2.1. Overview of Requirements 132 This section notes the main functional requirements for PCEP 133 extensions to support stateful PCE for use in GMPLS-controlled 134 networks, based on the description in [Stateful-APP]. Many 135 requirements are common across a variety of network types (e.g., 136 MPLS-TE networks and GMPLS networks) and the protocol extensions to 137 meet the requirements are already described in [Stateful-PCE]. This 138 document does not repeat the description of those protocol 139 extensions. Other requirements that are also common across a 140 variety of network types do not currently have protocol extensions 141 defined in [Stateful-PCE]. In these cases, this document presents 142 protocol extensions for discussion by the PCE working group and 143 potential inclusion in [Stateful-PCE]. In addition, this document 144 presents protocol extensions for a set of requirements which are 145 specific to the use of a stateful PCE in a GMPLS-controlled network. 147 The basic requirements are as follows: 149 o Advertisement of the stateful PCE capability. This generic 150 requirement is covered in Section 7.1.1. of [Stateful-PCE]. 151 Section 2.2. of this document discusses other potential extensions 152 for this functionality. 154 o LSP delegation is already covered in Section 5.5. of [Stateful- 155 PCE]. Section 2.3. of this document provides extension for its 156 application in GMPLS-controlled networks. Moreover, further 157 discussion of some generic details that may need additional 158 consideration is provided. 160 o LSP state synchronization and LSP state report. This is a generic 161 requirement already covered in Section 5.4. of [Stateful-PCE]. 162 However, there are further extensions required specifically for 163 GMPLS-controlled networks and discussed in Section 2.4. Reference 164 to LSPs by identifiers is discussed in Section 7.3. of [Stateful- 165 PCE]. This feature can be applied to reduce the data carried in 166 PCEP messages. Use cases and additional Error Codes are necessary, 167 as described in Section 2.5. of this draft. 169 2.2. Stateful PCE Capability Advertisement 171 Whether a PCE has stateful capability or not can be advertised 172 during the PCEP session establishment process. It can also be 173 advertised through routing protocols as described in [RFC5088]. In 174 either case, the following additional aspects should also be 175 considered. 177 2.2.1. PCE Capability Advertisement in Multi-layer Networks 179 In multi-layer network scenarios, such as an IP-over-optical network, 180 if there are dedicated PCEs responsible for each layer, then the 181 PCCs should be informed of which PCEs they should synchronize their 182 LSP states with, as well as send path computation requests to. The 183 Layer-Cap TLV defined in [INTER-LAYER] can be used to indicate which 184 layer a PCE is in charge of. (Editor's note: this change is 185 currently not included in the current version of the [INTER-LAYER] 186 draft. It is expected that it will be included in its next version.) 187 This TLV is optional and MAY be carried in the OPEN object. It is 188 RECOMMMENDED that a PCC synchronizes its LSP states with the same 189 PCEs that it can use for path computation in a multi-layer network. 190 In a single layer, this TLV MAY not be used. However, if the PCE 191 capability discovery depends on IGP and if an IGP instance spans 192 across multiple layers, this TLV is still needed. 194 Alternatively, the extension to current OSPF PCED TLV and IS-IS PCED 195 sub-TLV are needed. A new domain-type denoting the layer 196 information can be defined: 198 domain-type: T.B.D. (suggested value: 3) 200 which denotes the network layer information, in which a stateful PCE 201 has the stateful capability. 203 When it is carried in PCE-DOMAIN sub-TLV, it denotes the layer for 204 which a PCE is responsible for path computation as well as LSP state 205 synchronization. When carried in the PCE-NEIG-DOMAIN sub-TLV, it 206 denotes its adjacent layers for which a PCE can compute paths and 207 synchronize the LSP states. The DOMAIN-ID information can be 208 represented using the following format, to denote the layer 209 information: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | LSP Enc. Type | Switching Type| Reserved | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 The IS-IS PCE-DOMAIN sub-TLV is extended to have the following 218 format: 220 TYPE: 3 221 LENGTH: Variable 222 VALUE: This is composed of one octet indicating the domain-type 223 (area ID, AS Number or Network Layer) and a variable length IS-IS 224 area ID, 32-bit AS number, or a 32-Bit Network-Layer, with encoding 225 specified above identifying a network layer where the PCE has 226 visibility and can compute paths. 228 A new domain-type value is defined: 229 Value Meaning 230 3 Network Layer 232 2.3. LSP Delegation in GMPLS-controlled Networks 234 To enable the PCE to control an LSP, the PCUpd message is defined in 235 [Stateful-PCE]. However, the specification of technology specific 236 extensions is not covered. The following defines the 237 descriptor, present in the PCUpd message, that should be used in 238 GMPLS-controlled networks: 240 ::= 242 Where: 244 ::= [] 246 [] 248 [] 250 ::= [] 252 BANDWIDTH object used in the attribute-list is defined in [PCEP- 253 GMPLS]. Additional TLVs defined for object in [PCEP-GMPLS] 254 MAY also need to be included. 256 LSP parameter update controlled by a stateful PCE in a multi-domain 257 network is complex and requires well-defined operational procedures 258 as well as protocol design and is out of scope of this document and 259 left for further study. 261 2.4. LSP Synchronization in GMPLS-controlled Networks 263 For LSP state synchronization of stateful PCEs in GMPLS networks, 264 the LSP attributes, such as its bandwidth, associated route as well 265 as protection information etc, should be updated by PCCs to PCE LSP 266 database (LSP-DB). Note the LSP state synchronization described in 267 this document denotes both the bulk LSP report at the initialization 268 phase as well as the LSP state report afterwards described in 269 [Stateful-PCE]. 271 As per [Stateful-PCE], it does not cover technology-specific 272 specification for state synchronization. Therefore, extensions of 273 PCEP for stateful PCE usage in GMPLS networks are required. For LSP 274 state synchronization, the objects/TLVs that should be used for 275 stateful PCE in GMPLS networks are defined in [PCEP-GMPLS] and are 276 briefly summarized as below: 278 o BANDWIDTH (Generalized BANDWIDTH Object Type) 280 o END-POINTS (Generalized END-POINTS Object Type) 282 o PROTECTION ATTRIBUTE 284 o Use of IF_ID_ERROR_SPEC. [Stateful-PCE] section 7.3.4. only 285 considers RSVP ERROR_SPEC TLVs. GMPLS extends this to also support 286 IF_ID_ERROR_SPEC, for example, to report about failed unnumbered 287 interfaces. 289 o Extended objects to support the inclusion of the label and 290 unnumbered links. 292 Per [Stateful-PCE], the Path Computation Report (PCRpt) message is 293 defined for LSP state synchronization purposes. PCRpt is used by a 294 PCC to report one or more of its LSPs to a stateful PCE. However, 295 the descriptor is technology-specific and left undefined. 297 For LSP state synchronization in GMPLS-controlled networks, the 298 encoding of the descriptor is defined as follows: 300 ::= [] 302 Where: 304 ::= [] 305 [] 306 [] 307 [] 308 [] 309 [] 311 ::= [] 313 The objects included in the descriptor can be found in 314 [RFC5440], [PCEP-GMPLS] and [RFC5521]. 316 For all the objects presented in this section, the P and I bit MUST 317 be set to 0 since they are only used by a PCC to report its LSP 318 information. 320 In GMPLS-controlled networks, the object may include a list of 321 the label sub-object for SDH/SONET, OTN and DWDM networks. It may 322 also include a list of unnumbered interface IDs to denote the 323 allocated resource. The , and objects MAY include 324 unnumbered interface IDs and labels for networks such as OTN and WDM 325 networks. 327 If the LSP being reported is a protecting LSP, the TLV MUST be included in the object to denote its 329 attributes and restrictions. Moreover, if the status of the 330 protecting LSP changes from non-operational to operational, this 331 should be synchronized to the stateful PCE. For example, in 1:1 332 protection, the combination of S=0, P=1 and O=0 denotes the 333 protecting path is set up already but not used for carrying traffic. 334 Upon the working path failure, the operational status of the 335 aforementioned protecting LSP changes to in-use (i.e., O=1). This 336 information should be synchronized with a stateful PCE through a 337 PCRpt message. 339 The object type used here for and objects 340 MUST be the ones defined in [PCEP-GMPLS]. The are used 341 to report the end-points address associated with the LSP being 342 reported since the may not carry such information. 344 2.5. Modification of Existing PCEP Messages and Procedures 346 One of the advantages mentioned in [Stateful-APP] is that the 347 stateful nature of a PCE simplifies the information conveyed in PCEP 348 messages, notably between PCC and PCE, since it is possible to refer 349 to PCE managed state for active LSPs. To be more specific, with a 350 stateful PCE, it is possible to refer to a LSP with a unique 351 identifier in the scope of the PCC-PCEP session and thus use such 352 identifier to refer to that LSP. 354 2.5.1. Use cases 356 Use Case 1: Assuming a stateful PCE's LSP-DB is up-to-date, a PCC 357 (e.g. NMS) requesting for a re-optimization of one or several LSPs 358 can send the request with "R" bit set and only provides the relevant 359 LSP unique identifiers. 361 Upon receiving the PCReq message, PCE should be able to correlate 362 with one or multiple LSPs with their detailed state information and 363 carry out optimization accordingly. 365 The handling of RP object specified in [RFC5440] is stated as 366 following: 368 "The absence of an RRO in the PCReq message for a non-zero-bandwidth 369 TE LSP (when the R bit of the RP object is set) MUST trigger the 370 sending of a PCErr message with Error-Type="Required Object Missing" 371 and Error-value="RRO Object missing for re-optimization." 373 If a PCE has stateful capabilities, and such capabilities have been 374 negotiated and advertised, specific rules given in [RFC5440] may 375 need to be relaxed. In particular, the re-optimization case: if the 376 re-optimization request refers to a given LSP state, and the RRO 377 information is available, the PCE can proceed. 379 Use Case 2: in order to set up a LSP which has a constraint that its 380 route should not use resources used by one or more existing LSPs, a 381 PCC can send a PCReq with the identifiers of these LSPs. A stateful 382 PCE should be able to find the corresponding route and resource 383 information so as to meet the constraints set by the requesting PCC. 384 Hence, the LSP identifier TLV defined in [Stateful-PCE], encoded as 385 a subobject, can be used in XRO object for this purpose. Note that 386 if the PCC is a node in the network, the constraint LSP ID 387 information will be confined to the LSPs initiated by itself. 389 2.5.2. Modification for LSP Re-optimization 391 For re-optimization, upon receiving a path computation request and 392 the "R" bit is set, the stateful PCE SHOULD still perform the re- 393 optimization in the following two cases: 395 Case 1: the existing bandwidth and route information of the to-be- 396 optimized LSP is provided in the path computation request. This 397 information should be provided via , objects. 399 Case 2: the existing bandwidth and route information can be found 400 locally in its LSP-DB. In this case, the PCRep and PCReq messages 401 need to be modified to carry LSP identifiers. This is specified in 403 [Stateful-PCE]. The stateful PCE can find this information using the 404 per-node LSP ID (e.g., PLSP-ID defined in [Stateful-PCE]) together 405 with the PCC's address. 407 If no LSP state information is available to carry out re- 408 optimization, the stateful PCE should report the error "LSP state 409 information unavailable for the LSP re-optimization" (Error Type = 410 T.B.D., Error value= T.B.D.). 412 2.5.3. Modification for Route Exclusion 414 A LSP identifier sub-object is defined and its format as follows: 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 |X|Type (TBD.) | Length | Attributes | Flag | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | PLSP-ID | Reserved | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 X bit and Attribute fields are defined in [RFC5521]. 425 X bit: indicates whether the exclusion is mandatory (X=1) and MUST 426 be accommodated, or desired (X=0) and SHOULD be accommodated. 428 Type: Subobject Type for a per-node LSP identifier. 430 Length: The Length contains the total length of the subobject in 431 bytes, including the Type and Length fields. 433 Attributes: indicates how the exclusion object is to be 434 interpreted. Currently, Interface (Attributes = 0), Node (Attributes 435 =1) and SRLG (Attributes =2) are defined in [RFC5521] and this 436 document does not define new values. 438 Flags: is used to further specify the exclusion constraint with 439 regard to the LSP. Currently, no values are defined. 441 PLSP-ID: This is the identifier given to a LSP and it is unique on a 442 node basis. It is defined in [Stateful-PCE]. 444 Reserved: Reserved fields within subobjects MUST be transmitted as 445 zero and SHOULD be ignored on receipt. 447 One or multiple of these sub-objects can be present in the XRO 448 object. When a stateful PCE receives a path computation request 449 carrying this sub-object, it should find relevant information of 450 these LSPs and preclude the resource during the path computation 451 process. If a stateful PCE cannot recognize one or more of the 452 received LSP identifiers, it should reply PCErr saying "the LSP 453 state information for route exclusion purpose cannot be found" 454 (Error-type = T.B.D., Error-value= T.B.D.). Optionally, it may 455 provide with the unrecognized identifier information to the 456 requesting PCC. 458 3. IANA Considerations 460 IANA is requested to allocate new Types for the TLV/Object defined 461 in this document. 463 3.1. New PCEP Error Codes 465 IANA is requested to make the following allocation in the "PCEP- 466 ERROR Object Error Types and Values" registry. The values here are 467 suggested for use by IANA. 469 Error Type Meaning Reference 471 21 LSP state information missing 473 Error-value 1: LSP state information unavailable [This document] 475 for the LSP re-optimization 477 Error-value 2: LSP state information for route 479 exclusion purpose cannot be found [This document] 481 3.2. New Subobject for the Exclude Route Object 483 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 484 with an entry for the XRO object (Exclude Route Object). 486 IANA is requested to add a further sub-object that can be carried in 487 the XRO as follows: 489 Value Description Reference 491 TBD (suggested value: 5) LSP identifier sub-object [this document] 493 4. Manageability Considerations 495 The description and functionality specifications presented related 496 to stateful PCEs should also comply with the manageability 497 specifications covered in Section 8 of [RFC4655]. Furthermore, a 498 further list of manageability issues presented in [Stateful-PCE] 499 should also be considered. 501 Additional considerations are presented in the next sections. 503 4.1. Requirements on Other Protocols and Functional Components 505 When the detailed route information is included for LSP state 506 synchronization (either at the initial stage or during LSP state 507 report process), this require the ingress node of an LSP carry the 508 RRO object in order to enable the collection of such information. 510 5. Security Considerations 512 The security issues presented in [RFC5440] and [Stateful-PCE] apply 513 to this document. 515 6. Acknowledgement 517 We would like to thank Adrian Farrel and Cyril Margaria for the 518 useful comments and discussions. 520 7. References 522 7.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 525 requirements levels", RFC 2119, March 1997. 527 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 528 Computation Element (PCE)-Based Architecture", RFC 4655, 529 August 2006. 531 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 532 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 533 March 2009. 535 [RFC5088] Le Roux, JL., Vasseur, J.-P., Ikejiri, Y., Zhang, R., 536 "OSPF Protocol Extensions for Path Computation Element 537 (PCE) Discovery", RFC 5088, January 2008. 539 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 540 "IS-IS Protocol Extensions for Path Computation Element 541 (PCE) Discovery", RFC 5089, January 2008. 543 [INTER-LAYER] Oki, E., Takeda, Tomonori, Le Roux, JL., Farrel, A., 544 Zhang, F., "Extensions to the Path Computation Element 545 communication Protocol (PCEP) for Inter-Layer MPLS and 546 GMPLS Traffic Engineering", draft-ietf-pce-inter-layer-ext, 547 work in progress. 549 [Stateful-PCE]Crabbe, E., Medved, J., Varga, R., Minei, I., "PCEP 550 Extensions for Stateful PCE", draft-ietf-pce-stateful-pce, 551 work in progress. 553 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 554 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 555 extensions, work in progress. 557 7.2. Informative References 559 [Stateful-APP] Zhang, X., Minei, I., et al, "Applicability of 560 Stateful Path Computation Element (PCE) ", draft-ietf-pce- 561 stateful-pce-app, work in progress. 563 8. Contributors' Address 565 Dhruv Dhody 566 Huawei Technology 567 Leela Palace 568 Bangalore, Karnataka 560008 569 INDIA 571 EMail: dhruvd@huawei.com 573 Yi Lin 574 Huawei Technologies 575 F3-5-B R&D Center, Huawei Base 576 Bantian, Longgang District 577 Shenzhen 518129 P.R.China 579 Phone: +86-755-28972914 580 Email: yi.lin@huawei.com 582 Authors' Addresses 584 Xian Zhang 585 Huawei Technologies 586 F3-5-B R&D Center, Huawei Base 587 Bantian, Longgang District 588 Shenzhen 518129 P.R.China 590 Phone: +86-755-28972645 591 Email: zhang.xian@huawei.com 593 Young Lee 594 Huawei 595 1700 Alma Drive, Suite 100 596 Plano, TX 75075 597 US 599 Phone: +1 972 509 5599 x2240 600 Fax: +1 469 229 5397 601 EMail: ylee@huawei.com 603 Fatai Zhang 604 Huawei 605 F3-5-B R&D Center, Huawei Base 606 Bantian, Longgang District 607 P.R. China 609 Phone: +86-755-28972912 610 Email: zhangfatai@huawei.com 612 Ramon Casellas 613 CTTC 614 Av. Carl Friedrich Gauss n7 615 Castelldefels, Barcelona 08860 616 Spain 618 Phone: 619 Email: ramon.casellas@cttc.es 621 Oscar Gonzalez de Dios 622 Telefonica Investigacion y Desarrollo 623 Emilio Vargas 6 624 Madrid, 28045 625 Spain 626 Phone: +34 913374013 627 Email: ogondio@tid.es 629 Zafar Ali 630 Cisco Systems 631 Email: zali@cisco.com