idnits 2.17.1 draft-zheng-teas-gmpls-controller-inter-work-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 6, 2018) is 1967 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-18 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Haomian Zheng 2 Internet Draft Xianlong Luo 3 Category: Informational Huawei Technologies 4 Yang Zhao 5 China Mobile 6 Yunbin Xu 7 CAICT 8 Sergio Belotti 9 Dieter Beller 10 Nokia 11 Expires: June 6, 2019 December 6, 2018 13 Interworking of GMPLS Control and Centralized Controller System 15 draft-zheng-teas-gmpls-controller-inter-work-02 17 Abstract 19 Generalized Multi-Protocol Label Switching (GMPLS) control allows 20 each network element (NE) to perform local resource discovery, 21 routing and signaling in a distributed manner. 23 On the other hand, with the development of software-defined 24 transport networking technology, a set of NEs can be controlled via 25 centralized controller hierarchies to address the issue from multi- 26 domain, multi-vendor and multi-technology. An example of such 27 centralized architecture is ACTN controller hierarchy described in 28 RFC 8453. 30 Instead of competing with each other, both the distributed and the 31 centralized control plane have their own advantages, and should be 32 complementary in the system. This document describes how the GMPLS 33 distributed control plane can interwork with a centralized 34 controller system in a transport network. 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 June 6, 2019. 59 Copyright Notice 61 Copyright (c) 2018 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 Conventions used in this document 76 Table of Contents 78 1. Introduction ................................................ 3 79 2. Overview .................................................... 4 80 2.1. Overview of GMPLS Control Plane ........................... 4 81 2.2. Overview of Centralized Controller System ................. 4 82 2.3. GMPLS Control Interwork with Centralized Controller System. 5 83 3. Link Management Protocol .................................... 6 84 4. Routing Options ............................................. 6 85 4.1. OSPF-TE ................................................ 6 86 4.2. ISIS-TE ................................................ 7 87 4.3. Netconf/RESTconf ....................................... 7 88 5. Path Computation ............................................ 7 89 5.1. Constraint-based Path Computing in GMPLS Control ....... 7 90 5.2. Path Computation Element (PCE) ......................... 7 91 6. Signaling Options ........................................... 8 92 6.1. RSVP-TE ................................................ 8 93 7. Interworking Scenarios ...................................... 8 94 7.1. Topology Collection & Synchronization .................. 8 95 7.2. Multi-domain/layer Service Provisioning ................ 9 96 7.3. Recovery ............................................... 9 97 7.4. Controller Reliability ................................ 10 98 8. Manageability Considerations ............................... 10 99 9. Security Considerations .................................... 10 100 10. IANA Considerations........................................ 10 101 11. References ................................................ 11 102 11.1. Normative References ................................. 11 103 11.2. Informative References ............................... 12 104 12. Authors' Addresses ........................................ 14 106 1. Introduction 108 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 109 MPLS to support different classes of interfaces and switching 110 capabilities such as Time-Division Multiplex Capable (TDM), Lambda 111 Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network 112 element (NE) running a GMPLS control plane collects network 113 information from other NEs and supports service provisioning through 114 signaling in a distributed manner. More generic description for 115 Traffic-engineering networking information exchange can be found in 116 [RFC7926]. 118 On the other hand, Software-Defined Networking (SDN) technologies 119 have been introduced to control the transport network in a 120 centralized manner. Central controllers can collect network 121 information from each node and provision services to corresponding 122 nodes. One of the examples is the Abstraction and Control of Traffic 123 Engineered Networks (ACTN) [RFC8453], which defines a hierarchical 124 architecture with Provisioning Network Controller(PNC), Multi-domain 125 Service Coordinator(MDSC) and Customer Network Controller(CNC) as 126 central controllers for different network abstraction levels. A Path 127 Computation Element (PCE) based approach has been proposed as 128 Application-Based Network Operations (ABNO) in [RFC7491]. 130 In such centralized controller architectures, GMPLS can be applied 131 for the NE-level control. A central controller may support GMPLS 132 enabled domains and may interact with a GMPLS enabled domain where 133 the GMPLS control plane does the service provisioning from ingress 134 to egress. In this case the centralized controller sends the request 135 to the ingress node and does not have to configure all NEs along the 136 path through the domain from ingress to egress thus leveraging the 137 GMPLS control plane. This document describes how GMPLS control 138 interworks with centralized controller system in transport network. 140 2. Overview 142 In this section, overviews of GMPLS control plane and centralized 143 controller system are discussed as well as the interactions between 144 the GMPLS control plane and centralized controllers. 146 2.1. Overview of GMPLS Control Plane 148 GMPLS separates the control plane and the data plane to support 149 time-division, wavelength, and spatial switching, which are 150 significant in transport networks. For the NE level control in 151 GMPLS, each node runs a GMPLS control plane instance. 152 Functionalities such as service provisioning, protection, and 153 restoration can be performed via GMPLS communication among multiple 154 NEs. At the same time, the controller can also collect node and 155 link resources in the network to construct the network topology and 156 compute routing paths for serving service requests. 158 Several protocols have been designed for GMPLS control [RFC3945] 159 including link management [RFC4204], signaling [RFC3471], and 160 routing [RFC4202] protocols. The controllers applying these 161 protocols communicate with each other to exchange resource 162 information and establish Label Switched Paths (LSPs). In this way, 163 controllers in different nodes in the network have the same view of 164 the network topology and provision services based on local policies. 166 2.2. Overview of Centralized Controller System 168 With the development of SDN technologies, a centralized controller 169 architecture has been introduced to transport networks such as ACTN 170 [RFC8453]. In centralized controller systems, a controller is aware 171 of the network topology and is responsible for provisioning incoming 172 service requests. In ACTN, multiple abstraction levels are designed 173 and controllers at different levels implement different functions. 174 This kind of abstraction enables multi-vendor, multi-domain, and 175 multi-technology control. 177 For example in ACTN, an MDSC coordinates several PNCs controlling 178 different domains. Each PNC provides a topological view of the 179 domain it controls, which can be abstracted, to the MDSC, so that 180 the MDSC learns the topology of the network encompassing multiple 181 domains. When a multi-domain service request arrives at the MDSC, 182 the MDSC first computes an end-to-end path based on the abstracted 183 topology view provided by the PNCs. Then, the MDSC splits this path 184 to multiple segment according to domain boundaries and allocate each 185 segment to corresponding PNC for detailed path computation and LSP 186 segment setup. When each PNC has reported the establishment of its 187 LSP segment, the multi-domain service is established. 189 2.3. GMPLS Control Interwork with Centralized Controller System 191 The ACTN framework [RFC8453] defines a hierarchical controller 192 architecture and describes how these controllers communicate with 193 each other in order to control a multi-domain transport network. The 194 controllers at the different levels in the hierarchy typically 195 perform network abstraction of the domain they control and provide 196 an abstracted view of their domain to the controller at the next 197 level in the hierarchy. The controllers at the different 198 hierarchical levels also interact with each other during end-to-end 199 service establishment, which can span multiple domains. Within each 200 domain, GMPLS control can be applied to each NE. The bottom-level 201 central controller like PNC can act as a NE to collect network 202 information and initiate LSP. Figure 1 shows an example of GMPLS 203 interworking with ACTN. 205 +----------+ 206 | MDSC | 207 +----------+ 208 ^ ^ 209 | | 210 +---------+ +---------+ 211 | RESTConf / YANG models | 212 V V 213 +---------+ +---------+ 214 | PNC | | PNC | 215 +---------+ +---------+ 216 ^ ^ ^ ^ 217 | | | | 218 OSPF-TE| |PCEP OSPF-TE| |PCEP 219 Netconf| | Netconf| | 220 V V V V 221 .-------------. Inter- .-------------. 222 / \ domain / \ 223 | LMP | link | LMP | 224 | OSPF-TE ========== OSPF-TE | 225 | RSVP-TE | | RSVP-TE | 226 \ / \ / 227 `------------` `------------` 228 GMPLS domain GMPLS domain 230 Figure 1: Example of GMPLS interworks with ACTN 232 In Figure 1, each domain has the GMPLS control plane enabled at the 233 physical network level. The PNC can listen to the IGP routing 234 protocol messages (OSPF LSAs for example) that the GMPLS control 235 plane instances are disseminating into the network and thus learn 236 the network topology. For path computation in the domain with PNC 237 implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP 238 to ask the PNC for a path and get replies. The MDSC communicates 239 with PNCs using for example REST/RESTConf based on YANG data models. 240 As a PNC has learned its domain topology, it can report the topology 241 to the MDSC. When a service arrives, the MDSC computes the path and 242 coordinates PNCs to establish the corresponding LSP segment. 244 Alternatively, the NETCONF protocol can be used to retrieve topology 245 information utilizing the [TE-topo] Yang model and the technology- 246 specific YANG model augmentations required for the specific network 247 technology. The PNC can retrieve topology information from any NE 248 (the GMPLS control plane instance of each NE in the domain has the 249 same topological view), construct the topology of the domain and 250 export an abstracted view to the MDSC. Based on the topology 251 retrieved from multiple PNCs, the MDSC can create topology graph of 252 the multi-domain network, and can use it for path computation. To 253 setup a service, the MDSC can exploit Yang tunnel model together 254 with the technology-specific YANG model augmentations. 256 3. Link Management Protocol 258 Link management protocol (LMP) [RFC4204] runs between a pair of 259 nodes and is used to manage TE links. In addition to the setup and 260 maintenance of control channels, LMP can be used to verify the data 261 link connectivity and correlate the link property. In this way, link 262 resources, which are fundamental resources in the network, are 263 discovered by both ends of the link. 265 4. Routing Options 267 In GMPLS control, link state information is flooded within the 268 network as defined in [RFC4202]. Each node in the network can build 269 the network topology according to the flooded link state 270 information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE 271 [RFC5307] have been extended to support different interfaces in 272 GMPLS. 274 In centralized controller system, central controller can be placed 275 at the GMPLS network and passively receive the information flooded 276 in the network. In this way, the central controller can construct 277 and update the network topology. 279 4.1. OSPF-TE 281 OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions 282 have been defined in [RFC4203] to enable the capability of link 283 state information for GMPLS network. Based on this work, OSPF 284 protocol has been extended to support technology-specific routing. 286 The routing protocol for OTN, WSON and optical flexi-grid network 287 are defined in [RFC7138], [RFC7688] and [RFC8363], respectively. 289 4.2. ISIS-TE 291 ISIS-TE is introduced for TE networks in [RFC5305] and is extended 292 to support GMPLS routing functions [RFC5307], and has been updated 293 to [RFC7074] to support the latest GMPLS switching capability and 294 Types fields. 296 4.3. Netconf/RESTconf 298 Netconf [RFC6241] and RESTconf [RFC8040] protocols are originally 299 used for network configuration. Besides, these protocols can also be 300 used for topology retrieval by using topology-related YANG models, 301 such as [RFC8345] and [TE-topo]. These protocols provide a powerful 302 mechanism for notification that permits to notify the client about 303 topology changes. 305 5. Path Computation 307 Once a controller learns the network topology, it can utilize the 308 available resources to serve service requests by performing path 309 computation. Due to abstraction, the MDSC may not have sufficient 310 information to compute the optimal path. In this case, the MDSC can 311 interact with different domain controllers by sending Yang Path 312 Computation requests [PAT-COMP] to compute a set of potential 313 optimal paths and then, based on its own constraints, policy and 314 specific knowledge (e.g. cost of access link) can choose the more 315 feasible path for service e2e path setup. 317 Path computation is one of the key objectives in various types of 318 controllers. In the given architecture, it is possible for different 319 components that have the capability to compute the path. 321 5.1. Constraint-based Path Computing in GMPLS Control 323 In GMPLS control, a routing path is computed by the ingress node 324 [RFC3473] and is based on the ingress node TED. Constraint-based 325 path computation is performed according to the local policy of the 326 ingress node. 328 5.2. Path Computation Element (PCE) 330 PCE has been introduced in [RFC4655] as a functional component that 331 provides services to compute path in a network. In [RFC5440], the 332 path computation is accomplished by using the Traffic Engineering 333 Database (TED), which maintains the link resources in the network. 334 The emergence of PCE efficiently improve the quality of network 335 planning and offline computation, but there is a risk that the 336 computed path may be infeasible if there is a diversity requirement, 337 because stateless PCE has no knowledge about the former computed 338 paths. 340 To address this issue, stateful PCE has been proposed in [RFC8231]. 341 Besides the TED, an additional LSP Database (LSP-DB) is introduced 342 to archive each LSP computed by the PCE. In this way, PCE can easily 343 figure out the relationship between the computing path and former 344 computed paths. In this approach, PCE provides computed paths to 345 PCC, and then PCC decides which path is deployed and when to be 346 established. 348 In PCE Initiation [RFC8281], PCE is allowed to trigger the PCC to 349 setup, maintenance, and teardown of the PCE-initiated LSP under the 350 stateful PCE model. This would allow a dynamic network that is 351 centrally controlled and deployed. 353 In centralized controller system, the PCE can be implement in a 354 central controller, and the central controller performs path 355 computation according to its local policies. On the other hand, the 356 PCE can also be placed outside of the central controller. In this 357 case, the central controller acts as a PCC to request path 358 computation to the PCE through PCEP. 360 6. Signaling Options 362 Signaling mechanisms are used to setup LSPs in GMPLS control. 363 Messages are sent hop by hop between the ingress node and the egress 364 node of the LSP to allocate labels. Once the labels are allocated 365 along the path, the LSP setup is accomplished. Signaling protocols 366 such as RSVP-TE [RFC3473] have been extended to support different 367 interfaces in GMPLS. 369 6.1. RSVP-TE 371 RSVP-TE is introduced in [RFC3209] and extended to support GMPLS 372 signaling in [RFC3473]. Several label formats are defined for a 373 generalized label request, a generalized label, suggested label and 374 label sets. Based on [RFC3473], RSVP-TE has been extended to support 375 technology-specific signaling. The RSVP-TE extensions for OTN, WSON, 376 optical flexi-grid network are defined in [RFC7139], [RFC7689], and 377 [RFC7792], respectively. 379 7. Interworking Scenarios 381 7.1. Topology Collection & Synchronization 383 Topology information is necessary on both network elements and 384 controllers. The topology on network element is usually raw 385 information, while the topology on the controller can be either raw 386 or abstracted. Three different abstraction methods have been 387 described in [RFC8453], and different controllers can select the 388 corresponding method depending on application. 390 When there are changes in the network topology, the impacted network 391 element(s) need to report changes to all the other network elements, 392 together with the controller, to sync up the topology information. 393 The inter-NE synchronization can be achieved via protocols mentioned 394 in section 3 and 4. The topology synchronization between NEs and 395 controllers can either be achieved by routing protocols OSPF- 396 TE/PCEP-LS in [PCEP-LS] or Netconf protocol with YANG model. 398 7.2. Multi-domain/layer Service Provisioning 400 Based on the topology information on controllers and network 401 elements, service provisioning can be deployed. Plenty of methods 402 have been specified for single domain service provisioning, such as 403 using PCEP and RSVP-TE. 405 Multi-domain/layer service provisioning would request coordination 406 among the controller hierarchies. Given the service request, the 407 end-to-end delivery procedure may include interactions on MPI and 408 SBI. The computation for a cross-domain/layer path is usually 409 completed by MDSC, who has a global view of the topologies. Then the 410 configuration is decomposed into lower layer controllers, including 411 both MDSC and PNCs, to configure the network elements to set up the 412 path. 414 A combination of the centralized and distributed protocols may be 415 necessary for the interaction between network elements and 416 controller. A typical example would be the PCE Initiation scenario, 417 in which a PCE message (PCInitiate) is sent from the controller to 418 the first-end node, and then trigger a RSVP procedure along the 419 path. Similarly, the interaction between the controller and the 420 ingress node of a domain can be achieved by Netconf protocol with 421 corresponding YANG models, and then completed by running RSVP among 422 the network elements. 424 7.3. Recovery 426 The GMPLS recovery functions are described in [RFC4426]. Two models, 427 span protection and end-to-end protection and restoration, are 428 discussed with different protection schemes and message exchange 429 requirements. Related RSVP-TE extensions to support end-to-end 430 recovery is described in [RFC4872]. The extensions in [RFC4872] 431 include protection, restoration, preemption, and rerouting 432 mechanisms for an end-to-end LSP. Besides end-to-end recovery, a 433 GMPLS segment recovery mechanism is defined in [RFC4873]. By 434 introducing secondary record route objects, LSP segment can be 435 switched to another path like fast reroute [RFC4090]. 437 For the recovery with controllers, timely interaction between 438 controller and network elements are required. Usually the re-routing 439 can be decomposed into path computation and delivery, the controller 440 can take some advantage in the path computation due to the global 441 topology view. And the delivery can be achieved by the procedure 442 described in section 7.2. 444 7.4. Controller Reliability 446 Given the important role in the network, the reliability of 447 controller is critical. Once a controller is shut down, the network 448 should operate as well. It can be either achieved by controller back 449 up or functionality back up. There are several of controller backup 450 or federation mechanisms in the literature. It is also more reliable 451 to have some function back up in the network element, to guarantee 452 the performance in the network. 454 8. Manageability Considerations 456 Each entity in the network, including both controllers and network 457 elements, should be managed properly as it will interact with other 458 entities. The manageability considerations in controller hierarchies 459 and network elements still apply respectively. For the protocols 460 applied in the network, manageability is also requested. 462 The responsibility of each entity should be clarified. The control 463 of function and policy among different controllers should be 464 consistent via proper negotiation process. 466 9. Security Considerations 468 This document provides the interwork between the GMPLS and 469 controller hierarchies. The security requirements in both system 470 still applies respectively. Protocols referenced in this document 471 also have various security considerations, which is also expected to 472 be satisfied. 474 Other considerations on the interface between the controller and the 475 network element are also important. Such security includes the 476 functions to authenticate and authorize the control access to the 477 controller from multiple network elements. Security mechanisms on 478 the controller are also required to safeguard the underlying network 479 elements against attacks on the control plane and/or unauthorized 480 usage of data transport resources. 482 10. IANA Considerations 484 This document requires no IANA actions. 486 11. References 488 11.1. Normative References 490 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 491 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 492 Tunnels", RFC 3209, December 2001. 494 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 495 Switching (GMPLS) Signaling Resource ReserVation Protocol- 496 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 497 January 2003. 499 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 500 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 501 September 2003. 503 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 504 Switching (GMPLS) Architecture", RFC 3945, October 2004. 506 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions 507 in Support of Generalized Multi-Protocol Label Switching 508 (GMPLS)", RFC 4203, October 2005. 510 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 511 Element (PCE)-Based Architecture", RFC 4655, August 2006. 513 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 514 Ed., "RSVP-TE Extensions in Support of End-to-End 515 Generalized Multi-Protocol Label Switching (GMPLS) 516 Recovery", RFC 4872, May 2007. 518 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 519 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 521 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 522 Engineering", RFC 5305, October 2008. 524 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 525 in Support of Generalized Multi-Protocol Label Switching 526 (GMPLS)", RFC 5307, October 2008. 528 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 529 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 530 March 2009. 532 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., 533 "Network Configuration Protocol (NETCONF)", RFC 6241, June 534 2011. 536 [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the 537 GMPLS Switching Capability and Type Fields", RFC 7074, 538 November 2013. 540 [RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for 541 Application-Based Network Operations", RFC7491, March 542 2015. 544 [RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli, 545 D. and Zhang, X., "Problem Statement and Architecture for 546 Information Exchange between Interconnected Traffic- 547 Engineered Networks", RFC7926, July 2016. 549 [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF 550 Protocol", RFC 8040, January 2017. 552 [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 553 Control of Traffic Engineered Networks", RFC 8453, August 554 2018. 556 11.2. Informative References 558 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 559 Switching (GMPLS) Signaling Functional Description", RFC 560 3471, January 2003. 562 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 563 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 564 May 2005. 566 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 567 in Support of Generalized Multi-Protocol Label Switching 568 (GMPLS)", RFC 4202, October 2005. 570 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 571 4204, October 2005. 573 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. 574 Papadimitriou, Ed., "Generalized Multi-Protocol Label 575 witching (GMPLS) Recovery Functional Specification", RFC 576 4426, March 2006. 578 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 579 J. Drake, "Traffic Engineering Extensions to OSPF for 580 GMPLS Control of Evolving G.709 Optical Transport 581 Networks", RFC 7138, March 2014. 583 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 584 and K. Pithewan, "GMPLS Signaling Extensions for Control 585 of Evolving G.709 Optical Transport Networks", RFC 7139, 586 March 2014. 588 [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF 589 Enhancement for Signal and Network Element Compatibility 590 for Wavelength Switched Optical Networks", RFC 7688, 591 November 2015. 593 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 594 and H. Harai, "Signaling Extensions for Wavelength 595 Switched Optical Networks", RFC 7689, November 2015. 597 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 598 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 599 Support of Flexi-Grid Dense Wavelength Division 600 Multiplexing (DWDM) Networks", RFC 7792, March 2016. 602 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 603 Computation Element Communication Protocol (PCEP) 604 Extensions for Stateful PCE", RFC 8231, September 2017. 606 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 607 Extensions for PCE-initiated LSP Setup in a Stateful PCE 608 Model", RFC 8281, October 2017. 610 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 611 Ananthakrishnan, H., Liu, X., "A YANG Data Model for 612 Network Topologies", RFC 8345, March 2018. 614 [RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D. 615 Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi- 616 grid DWDM networks", RFC8363, February 2017. 618 [TE-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., 619 Gonzalez De Dios, O., "YANG Data Model for Traffic 620 Engineering (TE) Topologies", draft-ietf-teas-yang-te- 621 topo-18, work in progress. 623 [PAT-COMP] Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O., 624 Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang 625 model for requesting Path Computation", draft-ietf-teas- 626 yang-path-computation-04, work in progress. 628 [PCEP-LS] Dhody, D., Lee, Y., Ceccarelli, D., "PCEP Extensions for 629 Distribution of Link-State and TE Information", draft- 630 dhodylee-pce-pcep-ls, work in progress. 632 12. Authors' Addresses 634 Haomian Zheng 635 Huawei Technologies 636 F3 R&D Center, Huawei Industrial Base, 637 Bantian, Longgang District, 638 Shenzhen 518129 P.R.China 639 Email: zhenghaomian@huawei.com 641 Xianlong Luo 642 Huawei Technologies 643 F3 R&D Center, Huawei Industrial Base, 644 Bantian, Longgang District, 645 Shenzhen 518129 P.R.China 646 Email: luoxianlong@huawei.com 648 Yunbin Xu 649 CAICT 650 Email: xuyunbin@ritt.cn 652 Yang Zhao 653 China Mobile 654 Email: zhaoyangyjy@chinamobile.com 656 Sergio Belotti 657 Nokia 658 Email: sergio.belotti@nokia.com 660 Dieter Beller 661 Nokia 662 Email: Dieter.Beller@nokia.com