idnits 2.17.1 draft-lee-pce-pcep-ls-optical-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 230: '... MUST be included in the PCEP....' RFC 2119 keyword, line 270: '...on nodes, the PCE SHOULD be capable to...' RFC 2119 keyword, line 383: '... [RFC5440], [I-D.ietf-pce-pceps]. The PCE implementation SHOULD...' RFC 2119 keyword, line 387: '... general precaution, it is RECOMMENDED...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 5, 2017) is 2423 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5307' is mentioned on line 114, but not defined == Missing Reference: 'Stateful-PCE' is mentioned on line 522, but not defined == Missing Reference: 'PCE-initiated' is mentioned on line 137, but not defined == Missing Reference: 'I-D.ietf-pce-pceps' is mentioned on line 383, but not defined == Unused Reference: 'RFC4674' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC5089' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'JMS' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'S-PCE-GMPLS' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC7449' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'G.680' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'PCE-Initiated' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'FlexOSPF' is defined on line 536, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4674 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5088 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5089 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5250 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5305 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5440 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-flexible-grid-ospf-ext-05 Summary: 8 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Young Lee 2 Haomian Zheng 3 Internet Draft Huawei 4 Intended Status: Standard 5 Expires: March 2018 Daniele Ceccarelli 6 Ericsson 8 Wei Wang 9 Beijing Univ. of Posts and Telecom 11 Peter Park 12 KT 14 Bin Young Yoon 15 ETRI 17 September 5, 2017 19 PCEP Extension for Distribution of Link-State and TE information for 20 Optical Networks 22 draft-lee-pce-pcep-ls-optical-03 24 Abstract 26 In order to compute and provide optimal paths, Path Computation 27 Elements (PCEs) require an accurate and timely Traffic Engineering 28 Database (TED). Traditionally this Link State and TE information has 29 been obtained from a link state routing protocol (supporting traffic 30 engineering extensions). 32 This document extends the Path Communication Element Communication 33 Protocol (PCEP)_ with Link-State and TE information for optical 34 networks. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with 39 the provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other documents 48 at any time. It is inappropriate to use Internet-Drafts as 49 reference material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html 57 This Internet-Draft will expire on March 5, 2018. 59 Copyright Notice 61 Copyright (c) 2017 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with 69 respect to this document. Code Components extracted from this 70 document must include Simplified BSD License text as described in 71 Section 4.e of the Trust Legal Provisions and are provided without 72 warranty as described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction...................................................3 77 2. Applicability..................................................4 78 3. Requirements for PCEP extension................................5 79 4. PCEP-LS extension for Optical Networks.........................7 80 4.1. Node Attributes TLV.......................................7 81 4.2. Link Attributes TLV.......................................8 82 5. Security Considerations........................................9 83 6. IANA Considerations...........................................10 84 6.1. PCEP-LS Sub-TLV Type Indicators..........................10 85 7. References....................................................11 86 7.1. Normative References.....................................11 87 7.2. Informative References...................................11 88 Appendix A. Contributor Addresses................................13 89 Author's Addresses...............................................13 91 1. Introduction 93 In Multiprotocol Label Switching (MPLS) and Generalized MPLS 94 (GMPLS), a Traffic Engineering Database (TED) is used in computing 95 paths for connection oriented packet services and for circuits. The 96 TED contains all relevant information that a Path Computation 97 Element (PCE) needs to perform its computations. It is important 98 that the TED should be complete and accurate anytime so that the PCE 99 can perform path computations. 101 In MPLS and GMPLS networks, Interior Gateway routing Protocols 102 (IGPs) have been used to create and maintain a copy of the TED at 103 each node. One of the benefits of the PCE architecture [RFC4655] is 104 the use of computationally more sophisticated path computation 105 algorithms and the realization that these may need enhanced 106 processing power not necessarily available at each node 107 participating in an IGP. 109 Section 4.3 of [RFC4655] describes the potential load of the TED on 110 a network node and proposes an architecture where the TED is 111 maintained by the PCE rather than the network nodes. However it does 112 not describe how a PCE would obtain the information needed to 113 populate its TED. PCE may construct its TED by participating in the 114 IGP ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] 115 for GMPLS). An alternative is offered by [BGP-LS]. 117 [RFC7399] touches upon this issue: "It has also been proposed that 118 the PCE Communication Protocol (PCEP) [RFC5440] could be extended to 119 serve as an information collection protocol to supply information 120 from network devices to a PCE. The logic is that the network devices 121 may already speak PCEP and so the protocol could easily be used to 122 report details about the resources and state in the network, 123 including the LSP state discussed in Sections 14 and 15." 125 [Stateful-PCE] describes a set of extensions to PCEP to provide 126 stateful control. A stateful PCE has access to not only the 127 information carried by the network's Interior Gateway Protocol 128 (IGP), but also the set of active paths and their reserved resources 129 for its computations. PCC can delegate the rights to modify the LSP 130 parameters to an Active Stateful PCE. This requires PCE to quickly 131 be updated on any changes in the Topology and TEDB, so that PCE can 132 meet the need for updating LSPs effectively and in a timely manner. 133 The fastest way for a PCE to be updated on TED changes is via a 134 direct interface with each network node and with incremental update 135 from each network node. 137 [PCE-initiated] describes the setup, maintenance and teardown of 138 PCE-initiated LSPs under the stateful PCE model, without the need 139 for local configuration on the PCC, thus allowing for a dynamic 140 network that is centrally controlled and deployed. This model 141 requires timely topology and TED update at the PCE. 143 [PCEP-LS-Arch] proposes alternative architecture approaches for 144 learning and maintaining the Link State (and TE) information 145 directly on a PCE from network nodes as an alternative to IGPs and 146 BGP transport and investigate the impact from the PCE, routing 147 protocol, and network node perspectives. 149 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which 150 can be used for computing end-to-end paths for inter-domain MPLS 151 Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs). 152 Within the Hierarchical PCE (H-PCE) architecture [RFC6805], the 153 Parent PCE (P-PCE) is used to compute a multi-domain path based on 154 the domain connectivity information. A Child PCE (C-PCE) may be 155 responsible for a single domain or multiple domains, it is used to 156 compute the intra-domain path based on its domain topology 157 information. 159 [Stateful H-PCE] presents general considerations for stateful PCE(s) 160 in hierarchical PCE architecture. In particular, the behavior 161 changes and additions to the existing stateful PCE mechanisms 162 (including PCE-initiated LSP setup and active PCE usage) in the 163 context of networks using the H-PCE architecture. 165 [PCEP-LS] describes a mechanism by which Link State and TE 166 information can be collected from packet networks and shared with 167 PCE with the PCEP itself. This is achieved using a new PCEP message 168 format. 170 This draft describes an optical extension of [PCEP-LS] and explains 171 how encodings suggested by [PCEP-LS] can be used in the optical 172 network contexts. 174 2. Applicability 176 There are three main applicability of this alternative proposed by 177 this draft: 179 - Case 1: Where there is IGP running in optical network but 180 there is a need for a faster link-state and TE resource 181 collection at the PCE directly from an optical node (PCC) via 182 a PCC-PCE interface. 184 o A PCE may receive an incremental update (as opposed to 185 the entire TE information of the node/link). 187 Note: A PCE may receive full information from IGP using 188 existing mechanism. In some cases, the convergence of full 189 link-state and TE resource information of the entire network 190 may not be appropriate for certain applications. Incremental 191 update capability will enhance the accuracy of the TE 192 information at a given time. 194 - Case 2: Where there is no IGP running in the optical network 195 and there is a need for link-state and TE resource collections 196 at the PCE directly from an optical node (PCC) via a PCC-PCE 197 interface. 199 - Case 3: Where there is a need for transporting abstract 200 optical link-state and TE information from child PCE and to a 201 parent PCE in H-PCE [RFC6805] and [Stateful H-PCE] as well as 202 for Physical Network Controller (PNC) to Multi-Domain Service 203 Coordinator (MDSC) in Abstraction and Control of TE Networks 204 (ACTN) [ACTN-Frame]. 206 Note: The applicability for Case 3 may arise as a consequence 207 of Case 1 and Case 2. When TE information changes occur in the 208 optical network, this may also affect abstracted TE 209 information and thus needs to be updated to Parent PCE/MSDC 210 from each child PCE/PNC. 212 3. Requirements for PCEP extension 214 The key requirements associated with link-state (and TE) 215 distribution are identified for PCEP and listed in Section 4 of 216 [PCEP-LS]. These new functions required in PCEP to support 217 distribution of link-state (and TE) information are described in 218 Section 5 of [PCEP-LS]. Details of PCEP messages and related 219 Objects/TLVs are specified in Sections 8 and 9 of [PCEP-LS]. The key 220 requirements and new functions specified in [PCEP-LS] are equally 221 applicable to optical networks. 223 Besides the generic requirements specified in [PCEP-LS], optical 224 specific features also need to be considered in this document. As 225 connection-based network, there are specific parameters such as 226 reachable table, optical latency, wavelength consistency and some 227 other parameters that need to be included during the topology 228 collection. Without these restrictions, the path computation may be 229 inaccurate or infeasible for deployment, therefore these information 230 MUST be included in the PCEP. 232 The procedure on how the optical parameters are used is described in 233 following sections. 235 ion 237 The reachable source-destination node pair indicates that there are 238 a few number of OCh paths between two nodes. The reachability is 239 restricted by impairment, wavelength consistency and so on. This 240 information is necessary at PCE to promise the path computed between 241 source node and destination node is reachable. In this scenario, the 242 PCE should be responsible to compute how many OCh paths are 243 available to set up connections between source and destination node. 244 Moreover, if a set of optical wavelength is indicated in the path 245 computation request, the PCE should also determine whether a 246 wavelength of the set of preselected optical wavelength is available 247 for the source-destination pair connection. 249 To enable PCE to complete the above functions, the reachable 250 relationship and OMS link information need to be reported to PCE. 251 Once PCE detect that any wavelength is available, the corresponding 252 OMS link should be included in a lambda plane. Then this link can be 253 used for path computation in future. 255 Moreover, in a hierarchical PCE architecture, the information above 256 need to be reported from child PCE to parent PCE, who acts as a 257 service coordinator. 259 It is a usual case that the PCC indicates the latency when 260 requesting the path computation. In optical networks the latency is 261 a very sensitive parameter and there is stricter requirement on 262 latency. Given the maximal number of OCh paths between source- 263 destination nodes, the PCE also need to determine how many OCh path 264 satisfies the indicated latency threshold. 266 There is usually high-performance algorithm running on the PCE to 267 guarantee the performance of the computed path. During the 268 computation, the delay factor may be converted into a kind of link 269 weight. After the algorithm provides a few candidate paths between 270 the source and destination nodes, the PCE SHOULD be capable to 271 selecting one shortest path by computing the total path delay. 273 Optical PCEs are embedded with optimization algorithm, e.g., 274 shortest path algorithm, to improve the performance of computed 275 path. 277 4. PCEP-LS extension for Optical Networks 279 This section provides additional PCEP-LS extension necessary to 280 support optical networks. All Objects/TLVs defined in [PCEP-LS] are 281 applicable to optical networks. 283 4.1. Node Attributes TLV 285 Node-Attributed TLV is defined in Section 9.2.10.1 in [PCEP-LS] as 286 follows. This TLV is applicable for LS Node Object-Type as defined 287 in [PCEP-LS]. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type | Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 // Node Attributes Sub-TLVs (variable) // 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 The following 'Node Attribute' sub-TLVs are valid for optical 300 networks: 302 +-----------+------------------+--------------+-------------------+ 303 | Sub-TLV | Description | TLV/Sub-TLV | Length |Reference| 304 +-----------+------------------+--------------+---------+---------+ 305 | TBD | Connectivity | 5/14 | variable|[RFC7579]| 306 | | Matrix | | |[RFC7580]| 307 | TBD | Resource Block | 6/1 | variable|[RFC7688]| 308 | | Information | | | | 309 | TBD | Resource Block | 6/2 | variable|[RFC7688]| 310 | | Accessibility | | | | 311 | TBD | Resource Block | 6/3 | variable|[RFC7688]| 312 | | Wavelength Const | | | | 313 | TBD | Resource Block | 6/4 | variable|[RFC7688]| 314 | | Pool State | | | | 315 | TBD | Resource Block | 6/5 | variable|[RFC7688]| 316 | | Shared Access | | | | 317 | | Wavelength Avail.| | | | 318 +------------------------------------------------------=----------+ 320 4.2. Link Attributes TLV 322 Link-Attributes TLV is defined in Section 9.2.10.2 in [PCEP-LS] as 323 follows. This TLV is applicable for LS Link Object-Type as defined 324 in [PCEP-LS]. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type | Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 // Link Attributes Sub-TLVs (variable) // 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 The following 'Link Attribute' sub-TLVs are valid for optical 337 networks: 339 +-----------+-----------------+--------------+--------+----------+ 340 | Sub-TLV | Description | TLV/Sub-TLV | Length |Reference | 341 | | | | | | 342 +-----------+-----------------+--------------+--------+----------+ 343 | TBD | ISCD | 15 |Variable|[RFC4203] | 344 | | | | | | 345 | TBD | OTN-TDM SCSI | 15/1,2 |Variable|[RFC4203] | 346 | | | | |[RFC7138] | 347 | TBD | WSON-LSC SCSI | 15/1,2 |Variable|[RFC4203] | 348 | | | | |[RFC7688] | 349 | TBD | Flexi-grid SCSI | 15/1 |Variable|[FlexOSPF]| 350 | | | | | 351 | TBD | Port Label | 34 |Variable|[RFC7579] | 352 | | Restriction | | |[RFC7580] | 353 | | | | |[FlexOSPF]| 354 +-----------+-----------------+--------------+--------+----------+ 356 4.3. PCEP-LS for Optical Network Abstraction 358 This section provides additional PCEP-LS extension necessary to 359 support optical networks parameters discussed in Sections 3.1 and 360 3.2. Abstraction is primarily applied to C-PCE and P-PCE although 361 the same principle can be applied to PCC (NE) to PCE. 363 For OTN networks, max bandwidth available may be per ODU 0/1/2/3 364 switching level or aggregated across all ODU switching levels (i.e., 365 ODUj/k). 367 For WSON networks, max bandwidth available may be per 368 lambda/frequency level (OCh) or aggregated across all 369 lambda/frequency level. Per OCh level abstraction gives more 370 detailed data to the P-PCE at the expense of more information 371 processing. Either OCh-level or aggregated level abstraction should 372 factor in the RWA constraint (i.e., wavelength continuity) at the C- 373 PCE level. This means the C-PCE should have this capability and 374 advertise it as such. 376 [Editor's Note: Encoding will be provided in the revision] 378 5. Security Considerations 380 This document extends PCEP for LS (and TE) distribution including a 381 set of TLVs. Procedures and protocol extensions defined in this 382 document do not effect the overall PCEP security model. See 383 [RFC5440], [I-D.ietf-pce-pceps]. The PCE implementation SHOULD 384 provide mechanisms to prevent strains created by network flaps and 385 amount of LS (and TE) information. Thus it is suggested that any 386 mechanism used for securing the transmission of other PCEP message 387 be applied here as well. As a general precaution, it is RECOMMENDED 388 that these PCEP extensions only be activated on authenticated and 389 encrypted sessions belonging to the same administrative authority. 391 6. IANA Considerations 393 This document requests IANA actions to allocate code points for the 394 protocol elements defined in this document. 396 6.1. PCEP-LS Sub-TLV Type Indicators 398 This document specifies a set of PCEP-LS Sub-TLVs. IANA is requested 399 to create an "PCEP-LS Sub-TLV Types" sub-registry in the "PCEP TLV 400 Type Indicators" for the sub-TLVs carried in the PCEP-LS TLV (Node 401 Attributes TLV and Link Attributes TLV). 403 +-----------+------------------+--------------+----------+ 404 | Sub-TLV | Description | Ref Sub-TLV | Reference| 405 +-----------+------------------+--------------+----------+ 406 | TBD | Connectivity | 5/14 | [RFC7579]| 407 | | Matrix | | [RFC7580]| 408 | TBD | Resource Block | 6/1 | [RFC7688]| 409 | | Information | | | 410 | TBD | Resource Block | 6/2 | [RFC7688]| 411 | | Accessibility | | | 412 | TBD | Resource Block | 6/3 | [RFC7688]| 413 | | Wavelength Const | | | 414 | TBD | Resource Block | 6/4 | [RFC7688]| 415 | | Pool State | | | 416 | TBD | Resource Block | 6/5 | [RFC7688]| 417 | | Shared Access | | | 418 | | Wavelength Avail.| | | 419 | TBD | ISCD | 15 |[RFC4203] | 420 | | | | | 421 | TBD | OTN-TDM SCSI | 15/1,2 |[RFC4203] | 422 | | | |[RFC7138] | 423 | TBD | WSON-LSC SCSI | 15/1,2 |[RFC4203] | 424 | | | |[RFC7688] | 425 | TBD | Flexi-grid SCSI | 15/1 |[FlexOSPF]| 426 | | | | | 427 | TBD | Port Label | 34 |[RFC7579] | 428 | | Restriction | |[RFC7580] | 429 | | | |[FlexOSPF]| 430 +-----------+------------------+--------------+----------+ 432 7. References 434 7.1. Normative References 436 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 437 Computation Element (PCE)-Based Architecture", RFC 4655, 438 August 2006. 440 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 441 Element (PCE) Discovery", RFC 4674, October 2006. 443 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 444 Zhang, "OSPF Protocol Extensions for Path Computation 445 Element (PCE) Discovery", RFC 5088, January 2008. 447 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 448 Zhang, "IS-IS Protocol Extensions for Path Computation 449 Element (PCE) Discovery", RFC 5089, January 2008. 451 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 452 OSPF Opaque LSA Option", RFC 5250, July 2008. 454 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 455 Engineering", RFC 5305, October 2008. 457 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 458 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 459 March 2009. 461 7.2. Informative References 463 [JMS] Java Message Service, Version 1.1, April 2002, Sun 464 Microsystems. 466 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 467 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 468 September 2003. 470 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions 471 in Support of Generalized Multi-Protocol Label Switching 472 (GMPLS)", RFC 4203, October 2005. 474 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 475 Element (PCE)-Based Architecture", RFC 4655, August 2006. 477 [BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and 478 S.Ray, "North-Bound Distribution of Link-State and TE 479 information using BGP", draft-ietf-idr-ls-distribution, 480 work in progress. 482 [S-PCE-GMPLS] X. Zhang, et. al, "Path Computation Element (PCE) 483 Protocol Extensions for Stateful PCE Usage in GMPLS- 484 controlled Networks", draft-ietf-pce-pcep-stateful-pce- 485 gmpls, work in progress. 487 [RFC7399] A. Farrel and D. king, "Unanswered Questions in the Path 488 Computation Element Architecture", RFC 7399, October 2015. 490 [RFC7449] Y. Lee, G. Bernstein, "Path Computation Element 491 Communication Protocol (PCEP) Requirements for Wavelength 492 Switched Optical Network (WSON) Routing and Wavelength 493 Assignment", RFC 7449, February 2015. 495 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 496 Reflection: An Alternative to Full Mesh Internal BGP 497 (IBGP)", RFC 4456, April 2006. 499 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 500 and PCE Control of Wavelength Switched Optical Networks", 501 RFC 6163, 503 [G.680] ITU-T Recommendation G.680, Physical transfer functions of 504 optical network elements, July 2007. 506 [ACTN-Frame] D.Ceccarelli, and Y. Lee (Editors), "Framework for 507 Abstraction and Control of TE Networks", draft-ietf-teas- 508 actn-framework, work in progress. 510 [RFC6805] A. Farrel and D. King, "The Application of the Path 511 Computation Element Architecture to the Determination of a 512 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 513 2012. 515 [PCEP-LS-Arch] Y. Lee, D. Dhody and D. Ceccarelli, "Architecture and 516 Requirement for Distribution of Link-State and TE 517 Information via PCEP", draft-leedhody-teas-pcep-ls, work 518 in progress. 520 [PCEP-LS] D. Dhody, Y. Lee and D. Ceccarelli "PCEP Extension for 521 Distribution of Link-State and TE Information.", work in 522 progress, September 21, 2015[Stateful-PCE] Crabbe, E., 523 Minei, I., Medved, J., and R. Varga, "PCEP Extensions for 524 Stateful PCE", draft-ietf-pce-stateful-pce, work in 525 progress. 527 [PCE-Initiated] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, 528 "PCEP Extensions for PCE-initiated LSP Setup in a Stateful 529 PCE Model", draft-ietf-pce-pce-initiated-lsp, work in 530 progress. 532 [Stateful H-PCE] D. Dhody, Y. Lee and D. Ceccarelli, "Hierarchical 533 Stateful Path Computation Element (PCE)", draft-ietf-pce- 534 stateful-hpce, work-in-progress. 536 [FlexOSPF] X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. 537 Ceccarelli, "GMPLS OSPF Extensions in support of Flexi- 538 grid DWDM networks", draft-ietf-ccamp-flexible-grid-ospf- 539 ext-05, work in progress. 541 Appendix A. Contributor Addresses 543 Dhruv Dhody 544 Huawei Technologies 545 Divyashree Techno Park, Whitefield 546 Bangalore, Karnataka 560066 547 India 548 Email: dhruv.ietf@gmail.com 550 Author's Addresses 552 Young Lee 553 Huawei Technologies 554 5340 Legacy Drive, Building 3 555 Plano, TX 75023, USA 557 Email: leeyoung@huawei.com 558 Haomian Zheng 559 Huawei Technologies Co., Ltd. 560 F3-1-B R&D Center, Huawei Base, 561 Bantian, Longgang District 562 Shenzhen 518129 P.R.China 564 Email: zhenghaomian@huawei.com 566 Daniele Ceccarelli 567 Ericsson 568 Torshamnsgatan,48 569 Stockholm 570 Sweden 572 EMail: daniele.ceccarelli@ericsson.com 574 Wei Wang 575 Beijing University of Posts and Telecom 576 No. 10, Xitucheng Rd. Haidian District, Beijing 100876, P.R.China 578 Email: weiw@bupt.edu.cn 580 Peter Park 581 KT 582 Email: peter.park@kt.com 584 Bin Yeong Yoon 585 ETRI 586 Email: byyun@etri.re.kr