idnits 2.17.1 draft-zheng-teas-gmpls-controller-inter-work-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 (February 15, 2019) is 1890 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'TE-Tunnel' is defined on line 623, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-19 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-04 Summary: 0 errors (**), 0 flaws (~~), 4 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: August 19, 2019 February 15, 2019 13 Interworking of GMPLS Control and Centralized Controller System 15 draft-zheng-teas-gmpls-controller-inter-work-03 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 August 19, 2019. 59 Copyright Notice 61 Copyright (c) 2019 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. 4 83 3. Link Management Protocol .................................... 6 84 4. Routing Options ............................................. 6 85 4.1. OSPF-TE ................................................ 6 86 4.2. ISIS-TE ................................................ 6 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 ................................................ 10 102 11.1. Normative References.................................. 10 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. One example 170 architecture can be found in ACTN [RFC8453]. In such systems, a 171 controller is aware of the network topology and is responsible for 172 provisioning incoming service requests. 174 Multiple hierarchies of controllers are designed at different levels 175 implementing different functions. This kind of architecture enables 176 multi-vendor, multi-domain, and multi-technology control. For 177 example, an higher-level controller coordinates several lower-level 178 controllers controlling different domains, for topology collection 179 and service provisioning. Vendor-specific features can be abstracted 180 between controllers, and standard API (e.g., generated from 181 RESTconf/YANG) is used. 183 2.3. GMPLS Control Interwork with Centralized Controller System 185 Besides the GMPLS and the interactions among the controller 186 hierarchies, it is also necessary for the controllers to communicate 187 with the network elements. Within each domain, GMPLS control can be 188 applied to each NE. The bottom-level central controller can act as a 189 NE to collect network information and initiate LSP. Figure 1 shows 190 an example of GMPLS interworking with centralized controllers (ACTN 191 terminologies are used in the figure). 193 +----------+ 194 | MDSC | 195 +----------+ 196 ^ ^ 197 | | 198 +---------+ +---------+ 199 | RESTConf / YANG models | 200 V V 201 +---------+ +---------+ 202 | PNC | | PNC | 203 +---------+ +---------+ 204 ^ ^ ^ ^ 205 | | | | 206 Netconf| |PCEP Netconf| |PCEP 207 /YANG | | /YANG | | 208 V V V V 209 .-------------. Inter- .-------------. 210 / \ domain / \ 211 | LMP | link | LMP | 212 | OSPF-TE ========== OSPF-TE | 213 | RSVP-TE | | RSVP-TE | 214 \ / \ / 215 `------------` `------------` 216 GMPLS domain GMPLS domain 218 Figure 1: Example of GMPLS interworks with Controllers 220 In Figure 1, each domain has the GMPLS control plane enabled at the 221 physical network level. The PNC can exploit GMPLS capability 222 implemented in the domain to listen to the IGP routing protocol 223 messages (OSPF LSAs for example) that the GMPLS control plane 224 instances are disseminating into the network and thus learn the 225 network topology. For path computation in the domain with PNC 226 implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP 227 to ask the PNC for a path and get replies. The MDSC communicates 228 with PNCs using for example REST/RESTConf based on YANG data models. 229 As a PNC has learned its domain topology, it can report the topology 230 to the MDSC. When a service arrives, the MDSC computes the path and 231 coordinates PNCs to establish the corresponding LSP segment. 233 Alternatively, the NETCONF protocol can be used to retrieve topology 234 information utilizing the e.g.[TE-topo] Yang model and the 235 technology-specific YANG model augmentations required for the 236 specific network technology. The PNC can retrieve topology 237 information from any NE (the GMPLS control plane instance of each NE 238 in the domain has the same topological view), construct the topology 239 of the domain and export an abstracted view to the MDSC. Based on 240 the topology retrieved from multiple PNCs, the MDSC can create 241 topology graph of the multi-domain network, and can use it for path 242 computation. To setup a service, the MDSC can exploit e.g.[TE- 243 Tunnel] Yang model together with the technology-specific YANG model 244 augmentations. 246 3. Link Management Protocol 248 Link management protocol (LMP) [RFC4204] runs between a pair of 249 nodes and is used to manage TE links. In addition to the setup and 250 maintenance of control channels, LMP can be used to verify the data 251 link connectivity and correlate the link property. In this way, link 252 resources, which are fundamental resources in the network, are 253 discovered by both ends of the link. 255 4. Routing Options 257 In GMPLS control, link state information is flooded within the 258 network as defined in [RFC4202]. Each node in the network can build 259 the network topology according to the flooded link state 260 information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE 261 [RFC5307] have been extended to support different interfaces in 262 GMPLS. 264 In centralized controller system, central controller can be placed 265 at the GMPLS network and passively receive the information flooded 266 in the network. In this way, the central controller can construct 267 and update the network topology. 269 4.1. OSPF-TE 271 OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions 272 have been defined in [RFC4203] to enable the capability of link 273 state information for GMPLS network. Based on this work, OSPF 274 protocol has been extended to support technology-specific routing. 275 The routing protocol for OTN, WSON and optical flexi-grid network 276 are defined in [RFC7138], [RFC7688] and [RFC8363], respectively. 278 4.2. ISIS-TE 280 ISIS-TE is introduced for TE networks in [RFC5305] and is extended 281 to support GMPLS routing functions [RFC5307], and has been updated 282 to [RFC7074] to support the latest GMPLS switching capability and 283 Types fields. 285 4.3. Netconf/RESTconf 287 Netconf [RFC6241] and RESTconf [RFC8040] protocols are originally 288 used for network configuration. Besides, these protocols can also be 289 used for topology retrieval by using topology-related YANG models, 290 such as [RFC8345] and [TE-topo]. These protocols provide a powerful 291 mechanism for notification that permits to notify the client about 292 topology changes. 294 5. Path Computation 296 Once a controller learns the network topology, it can utilize the 297 available resources to serve service requests by performing path 298 computation. Due to abstraction, the controllers may not have 299 sufficient information to compute the optimal path. In this case, 300 the controller can interact with other controllers by sending Yang 301 Path Computation requests [PAT-COMP] to compute a set of potential 302 optimal paths and then, based on its own constraints, policy and 303 specific knowledge (e.g. cost of access link) can choose the more 304 feasible path for service e2e path setup. 306 Path computation is one of the key objectives in various types of 307 controllers. In the given architecture, it is possible for different 308 components that have the capability to compute the path. 310 5.1. Constraint-based Path Computing in GMPLS Control 312 In GMPLS control, a routing path is computed by the ingress node 313 [RFC3473] and is based on the ingress node TED. Constraint-based 314 path computation is performed according to the local policy of the 315 ingress node. 317 5.2. Path Computation Element (PCE) 319 PCE has been introduced in [RFC4655] as a functional component that 320 provides services to compute path in a network. In [RFC5440], the 321 path computation is accomplished by using the Traffic Engineering 322 Database (TED), which maintains the link resources in the network. 323 The emergence of PCE efficiently improve the quality of network 324 planning and offline computation, but there is a risk that the 325 computed path may be infeasible if there is a diversity requirement, 326 because stateless PCE has no knowledge about the former computed 327 paths. 329 To address this issue, stateful PCE has been proposed in [RFC8231]. 330 Besides the TED, an additional LSP Database (LSP-DB) is introduced 331 to archive each LSP computed by the PCE. In this way, PCE can easily 332 figure out the relationship between the computing path and former 333 computed paths. In this approach, PCE provides computed paths to 334 PCC, and then PCC decides which path is deployed and when to be 335 established. 337 In PCE Initiation [RFC8281], PCE is allowed to trigger the PCC to 338 setup, maintenance, and teardown of the PCE-initiated LSP under the 339 stateful PCE model. This would allow a dynamic network that is 340 centrally controlled and deployed. 342 In centralized controller system, the PCE can be implemented in a 343 central controller, and the central controller performs path 344 computation according to its local policies. On the other hand, the 345 PCE can also be placed outside of the central controller. In this 346 case, the central controller acts as a PCC to request path 347 computation to the PCE through PCEP. One of the reference 348 architecture can be found at [RFC7491]. 350 6. Signaling Options 352 Signaling mechanisms are used to setup LSPs in GMPLS control. 353 Messages are sent hop by hop between the ingress node and the egress 354 node of the LSP to allocate labels. Once the labels are allocated 355 along the path, the LSP setup is accomplished. Signaling protocols 356 such as RSVP-TE [RFC3473] have been extended to support different 357 interfaces in GMPLS. 359 6.1. RSVP-TE 361 RSVP-TE is introduced in [RFC3209] and extended to support GMPLS 362 signaling in [RFC3473]. Several label formats are defined for a 363 generalized label request, a generalized label, suggested label and 364 label sets. Based on [RFC3473], RSVP-TE has been extended to support 365 technology-specific signaling. The RSVP-TE extensions for OTN, WSON, 366 optical flexi-grid network are defined in [RFC7139], [RFC7689], and 367 [RFC7792], respectively. 369 7. Interworking Scenarios 371 7.1. Topology Collection & Synchronization 373 Topology information is necessary on both network elements and 374 controllers. The topology on network element is usually raw 375 information, while the topology on the controller can be either raw 376 or abstracted. Three different abstraction methods have been 377 described in [RFC8453], and different controllers can select the 378 corresponding method depending on application. 380 When there are changes in the network topology, the impacted network 381 element(s) need to report changes to all the other network elements, 382 together with the controller, to sync up the topology information. 383 The inter-NE synchronization can be achieved via protocols mentioned 384 in section 3 and 4. The topology synchronization between NEs and 385 controllers can either be achieved by routing protocols OSPF- 386 TE/PCEP-LS in [PCEP-LS] or Netconf protocol notifications with YANG 387 model. 389 7.2. Multi-domain/layer Service Provisioning 391 Based on the topology information on controllers and network 392 elements, service provisioning can be deployed. Plenty of methods 393 have been specified for single domain service provisioning, such as 394 using PCEP and RSVP-TE. 396 Multi-domain/layer service provisioning would request coordination 397 among the controller hierarchies. Given the service request, the 398 end-to-end delivery procedure may include interactions at any level 399 (i.e. interface) in the hierachy of the controllers (e.g. MPI and 400 SBI for ACTN). The computation for a cross-domain/layer path is 401 usually completed by controllers who have a global view of the 402 topologies. Then the configuration is decomposed into lower layer 403 controllers, to configure the network elements to set up the path. 405 A combination of the centralized and distributed protocols may be 406 necessary for the interaction between network elements and 407 controller. A typical example would be the PCE Initiation scenario, 408 in which a PCE message (PCInitiate) is sent from the controller to 409 the first-end node, and then trigger a RSVP procedure along the 410 path. Similarly, the interaction between the controller and the 411 ingress node of a domain can be achieved by Netconf protocol with 412 corresponding YANG models, and then completed by running RSVP among 413 the network elements. 415 7.3. Recovery 417 The GMPLS recovery functions are described in [RFC4426]. Two models, 418 span protection and end-to-end protection and restoration, are 419 discussed with different protection schemes and message exchange 420 requirements. Related RSVP-TE extensions to support end-to-end 421 recovery is described in [RFC4872]. The extensions in [RFC4872] 422 include protection, restoration, preemption, and rerouting 423 mechanisms for an end-to-end LSP. Besides end-to-end recovery, a 424 GMPLS segment recovery mechanism is defined in [RFC4873]. By 425 introducing secondary record route objects, LSP segment can be 426 switched to another path like fast reroute [RFC4090]. 428 For the recovery with controllers, timely interaction between 429 controller and network elements are required. Usually the re-routing 430 can be decomposed into path computation and delivery, the controller 431 can take some advantage in the path computation due to the global 432 topology view. And the delivery can be achieved by the procedure 433 described in section 7.2. 435 7.4. Controller Reliability 437 Given the important role in the network, the reliability of 438 controller is critical. Once a controller is shut down, the network 439 should operate as well. It can be either achieved by controller back 440 up or functionality back up. There are several of controller backup 441 or federation mechanisms in the literature. It is also more reliable 442 to have some function back up in the network element, to guarantee 443 the performance in the network. 445 8. Manageability Considerations 447 Each entity in the network, including both controllers and network 448 elements, should be managed properly as it will interact with other 449 entities. The manageability considerations in controller hierarchies 450 and network elements still apply respectively. For the protocols 451 applied in the network, manageability is also requested. 453 The responsibility of each entity should be clarified. The control 454 of function and policy among different controllers should be 455 consistent via proper negotiation process. 457 9. Security Considerations 459 This document provides the interwork between the GMPLS and 460 controller hierarchies. The security requirements in both system 461 still applies respectively. Protocols referenced in this document 462 also have various security considerations, which is also expected to 463 be satisfied. 465 Other considerations on the interface between the controller and the 466 network element are also important. Such security includes the 467 functions to authenticate and authorize the control access to the 468 controller from multiple network elements. Security mechanisms on 469 the controller are also required to safeguard the underlying network 470 elements against attacks on the control plane and/or unauthorized 471 usage of data transport resources. 473 10. IANA Considerations 475 This document requires no IANA actions. 477 11. References 479 11.1. Normative References 481 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 482 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 483 Tunnels", RFC 3209, December 2001. 485 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 486 Switching (GMPLS) Signaling Resource ReserVation Protocol- 487 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 488 January 2003. 490 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 491 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 492 September 2003. 494 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 495 Switching (GMPLS) Architecture", RFC 3945, October 2004. 497 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions 498 in Support of Generalized Multi-Protocol Label Switching 499 (GMPLS)", RFC 4203, October 2005. 501 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 502 Element (PCE)-Based Architecture", RFC 4655, August 2006. 504 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 505 Ed., "RSVP-TE Extensions in Support of End-to-End 506 Generalized Multi-Protocol Label Switching (GMPLS) 507 Recovery", RFC 4872, May 2007. 509 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 510 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 512 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 513 Engineering", RFC 5305, October 2008. 515 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 516 in Support of Generalized Multi-Protocol Label Switching 517 (GMPLS)", RFC 5307, October 2008. 519 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 520 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 521 March 2009. 523 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., 524 "Network Configuration Protocol (NETCONF)", RFC 6241, June 525 2011. 527 [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the 528 GMPLS Switching Capability and Type Fields", RFC 7074, 529 November 2013. 531 [RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for 532 Application-Based Network Operations", RFC7491, March 533 2015. 535 [RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli, 536 D. and Zhang, X., "Problem Statement and Architecture for 537 Information Exchange between Interconnected Traffic- 538 Engineered Networks", RFC7926, July 2016. 540 [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF 541 Protocol", RFC 8040, January 2017. 543 [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 544 Control of Traffic Engineered Networks", RFC 8453, August 545 2018. 547 11.2. Informative References 549 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 550 Switching (GMPLS) Signaling Functional Description", RFC 551 3471, January 2003. 553 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 554 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 555 May 2005. 557 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 558 in Support of Generalized Multi-Protocol Label Switching 559 (GMPLS)", RFC 4202, October 2005. 561 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 562 4204, October 2005. 564 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. 565 Papadimitriou, Ed., "Generalized Multi-Protocol Label 566 witching (GMPLS) Recovery Functional Specification", RFC 567 4426, March 2006. 569 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 570 J. Drake, "Traffic Engineering Extensions to OSPF for 571 GMPLS Control of Evolving G.709 Optical Transport 572 Networks", RFC 7138, March 2014. 574 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 575 and K. Pithewan, "GMPLS Signaling Extensions for Control 576 of Evolving G.709 Optical Transport Networks", RFC 7139, 577 March 2014. 579 [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF 580 Enhancement for Signal and Network Element Compatibility 581 for Wavelength Switched Optical Networks", RFC 7688, 582 November 2015. 584 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 585 and H. Harai, "Signaling Extensions for Wavelength 586 Switched Optical Networks", RFC 7689, November 2015. 588 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 589 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 590 Support of Flexi-Grid Dense Wavelength Division 591 Multiplexing (DWDM) Networks", RFC 7792, March 2016. 593 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 594 Computation Element Communication Protocol (PCEP) 595 Extensions for Stateful PCE", RFC 8231, September 2017. 597 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 598 Extensions for PCE-initiated LSP Setup in a Stateful PCE 599 Model", RFC 8281, October 2017. 601 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 602 Ananthakrishnan, H., Liu, X., "A YANG Data Model for 603 Network Topologies", RFC 8345, March 2018. 605 [RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D. 606 Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi- 607 grid DWDM networks", RFC8363, February 2017. 609 [TE-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., 610 Gonzalez De Dios, O., "YANG Data Model for Traffic 611 Engineering (TE) Topologies", draft-ietf-teas-yang-te- 612 topo-19, work in progress. 614 [PAT-COMP] Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O., 615 Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang 616 model for requesting Path Computation", draft-ietf-teas- 617 yang-path-computation-04, work in progress. 619 [PCEP-LS] Dhody, D., Lee, Y., Ceccarelli, D., "PCEP Extensions for 620 Distribution of Link-State and TE Information", draft- 621 dhodylee-pce-pcep-ls, work in progress. 623 [TE-Tunnel] Saad, T. et al., "A YANG Data Model for Traffic 624 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 625 te, work in progress. 627 12. Authors' Addresses 629 Haomian Zheng 630 Huawei Technologies 631 F3 R&D Center, Huawei Industrial Base, 632 Bantian, Longgang District, 633 Shenzhen 518129 P.R.China 634 Email: zhenghaomian@huawei.com 636 Xianlong Luo 637 Huawei Technologies 638 F3 R&D Center, Huawei Industrial Base, 639 Bantian, Longgang District, 640 Shenzhen 518129 P.R.China 641 Email: luoxianlong@huawei.com 643 Yunbin Xu 644 CAICT 645 Email: xuyunbin@ritt.cn 647 Yang Zhao 648 China Mobile 649 Email: zhaoyangyjy@chinamobile.com 651 Sergio Belotti 652 Nokia 653 Email: sergio.belotti@nokia.com 655 Dieter Beller 656 Nokia 657 Email: Dieter.Beller@nokia.com