idnits 2.17.1 draft-zheng-teas-gmpls-controller-inter-work-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8453]), 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2018) is 2003 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TE-TOPO' is mentioned on line 247, but not defined == Missing Reference: 'I-D.ietf-pce-pce-initiated-lsp' is mentioned on line 349, but not defined == Missing Reference: 'PCEP-LS' is mentioned on line 397, but not defined == Unused Reference: 'RFC8281' is defined on line 593, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-15 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-01 Summary: 1 error (**), 0 flaws (~~), 8 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: April 22, 2019 October 22, 2018 13 Interworking of GMPLS Control and Centralized Controller System 15 draft-zheng-teas-gmpls-controller-inter-work-01 17 Abstract 19 Generalized Multi-Protocol Label Switching (GMPLS) control allows 20 each network element (NE) to perform local resource discovery (e.g., 21 LMP), routing (e.g., OSPF-TE) and signaling (e.g., RSVP-TE) in a 22 distributed manner. 24 On the other hand, with the development of software-defined 25 transport networking technology, a set of NEs can be controlled via 26 centralized controller hierarchies to address the issue from multi- 27 domain, multi-vendor and multi-technology. An example of such 28 centralized architecture is ACTN controller hierarchy [RFC8453]. 30 Instead of competing with each other, both the distributed and the 31 centralized control plane have their own advantage, 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 April 22, 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 Table of Contents 82 1. Introduction ................................................ 3 83 2. Overview .................................................... 4 84 2.1. Overview of GMPLS Control Plane ........................... 4 85 2.2. Overview of Centralized Controller System ................. 4 86 2.3. GMPLS Control Interwork with Centralized Controller System. 5 87 3. Link Management Protocol .................................... 6 88 4. Routing Options ............................................. 6 89 4.1. OSPF-TE ................................................ 7 90 4.2. ISIS-TE ................................................ 7 91 4.3. Netconf/RESTconf ....................................... 7 92 5. Path Computation ............................................ 7 93 5.1. Constraint-based Path Computing in GMPLS Control ....... 7 94 5.2. Path Computation Element (PCE) ......................... 8 95 6. Signaling Options ........................................... 8 96 6.1. RSVP-TE ................................................ 8 97 7. Interworking Scenarios ...................................... 9 98 7.1. Topology Collection & Synchronization .................. 9 99 7.2. Multi-domain/layer Service Provisioning ................ 9 100 7.3. Recovery .............................................. 10 101 7.4. Controller Reliability ................................ 10 102 8. Network Management ......................................... 10 103 9. Security Considerations .................................... 10 104 10. IANA Considerations........................................ 10 105 11. References ................................................ 10 106 11.1. Normative References ................................. 10 107 11.2. Informative References ............................... 14 108 12. Authors' Addresses ........................................ 14 110 1. Introduction 112 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 113 MPLS to support different classes of interfaces and switching 114 capabilities such as Time-Division Multiplex Capable (TDM), Lambda 115 Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network 116 element (NE) running a GMPLS control plane collects network 117 information from other NEs and supports service provisioning through 118 signaling in a distributed manner. More generic description for 119 Traffic-engineering networking information exchange can be found in 120 [RFC7926]. 122 On the other hand, Software-Defined Networking (SDN) technologies 123 have been introduced to control the transport network in a 124 centralized manner. Central controllers can collect network 125 information from each node and provision services to corresponding 126 nodes. One of the examples is the Abstraction and Control of Traffic 127 Engineered Networks (ACTN) [RFC8453], which defines a hierarchical 128 architecture with PNC, MDSC and CNC as central controllers for 129 different network abstraction levels. A PCE-based approach has been 130 proposed as Application-Based Network Operations (ABNO) in 131 [RFC7491]. 133 In such centralized controller architectures, GMPLS can be applied 134 for the NE-level control. A central controller may support GMPLS 135 enabled domains and may interact with a GMPLS enabled domain where 136 the GMPLS control plane does the service provisioning from ingress 137 to egress. In this case the centralized controller sends the request 138 to the ingress node and does not have to configure all NEs along the 139 path through the domain from ingress to egress thus leveraging the 140 GMPLS control plane. This document describes how GMPLS control 141 interworks with centralized controller system in transport network. 143 2. Overview 145 In this section, overviews of GMPLS control plane and centralized 146 controller system are discussed as well as the interactions between 147 the GMPLS control plane and centralized controllers. 149 2.1. Overview of GMPLS Control Plane 151 GMPLS separates the control plane and the data plane to support 152 time-division, wavelength, and spatial switching, which are 153 significant in transport networks. For the NE level control in 154 GMPLS, each node runs a GMPLS control plane instance. 155 Functionalities such as service provisioning, protection, and 156 restoration can be performed via GMPLS communication among multiple 157 NEs. At the same time, the controller can also collect node and 158 link resources in the network to construct the network topology and 159 compute routing paths for serving service requests. 161 Several protocols have been designed for GMPLS control [RFC3945] 162 including link management [RFC4204], signaling [RFC3471], and 163 routing [RFC4202] protocols. The controllers applying these 164 protocols communicate with each other to exchange resource 165 information and establish LSP. In this way, controllers in different 166 nodes in the network have the same network topology and provision 167 services based on local policies. 169 2.2. Overview of Centralized Controller System 171 With the development of SDN technologies, a centralized controller 172 architecture has been introduced to transport networks such as ACTN 173 [RFC8453]. In centralized controller system, a controller is aware 174 of the network topology and is responsible for provisioning incoming 175 service requests. In ACTN, multiple abstraction levels are designed 176 and controllers at different levels implement different functions. 177 This kind of abstraction enables multi-vendor, multi-domain, and 178 multi-technology control. 180 For example in ACTN, an MDSC coordinates several PNCs controlling 181 different domains. Each PNC provides a topological view of the 182 domain it controls, which can be abstracted, to the MDSC, so that 183 the MDSC learns the topology of the network encompassing multiple 184 domains. When a multi-domain service request arrives at the MDSC, 185 the MDSC first computes an end-to-end path based on the abstracted 186 topology view provided by the PNCs. Then, the MDSC splits this path 187 to multiple segment according to domain boundaries and allocate each 188 segment to corresponding PNC for detailed path computation and LSP 189 segment setup. When each PNC has reported the establishment of its 190 LSP segment, the multi-domain service is established. 192 2.3. GMPLS Control Interwork with Centralized Controller System 194 The ACTN framework [RFC8453] defines a hierarchical controller 195 architecture and describes how these controllers communicate with 196 each other in order to control a multi-domain transport network. The 197 controllers at the different levels in the hierarchy typically 198 perform network abstraction of the domain they control and provide 199 an abstracted view of their domain to the controller at the next 200 level in the hierarchy. The controllers at the different 201 hierarchical levels also interact with each other during end-to-end 202 service establishment, which can span multiple domains. Within each 203 domain, GMPLS control can be applied to each NE. The bottom-level 204 central controller like PNC can act as a NE to collect network 205 information and initiate LSP. Following figure shows an example of 206 GMPLS interworking with ACTN. 208 +----------+ 209 | MDSC | 210 +----------+ 211 ^ ^ 212 | | 213 +---------+ +---------+ 214 | RESTConf / YANG models | 215 V V 216 +---------+ +---------+ 217 | PNC | | PNC | 218 +---------+ +---------+ 219 ^ ^ ^ ^ 220 | | | | 221 OSPF-TE| |PCEP OSPF-TE| |PCEP 222 Netconf| | Netconf| | 223 V V V V 224 .-------------. Inter- .-------------. 225 / \ domain / \ 226 | LMP | link | LMP | 227 | OSPF-TE ========== OSPF-TE | 228 | RSVP-TE | | RSVP-TE | 229 \ / \ / 230 `------------` `------------` 231 GMPLS domain GMPLS domain 232 Figure 1: Example of GMPLS interworks with ACTN 234 In Figure 1, each domain has the GMPLS control plane enabled at the 235 physical network level. The PNC can listen to the IGP routing 236 protocol messages (OSPF LSAs for example) that the GMPLS control 237 plane instances are disseminating into the network and thus learn 238 the network topology. For path computation in the domain with PNC 239 implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP 240 to ask the PNC for a path and get replies. The MDSC communicates 241 with PNCs using for example REST/RESTConf based on YANG data models. 242 As a PNC has learned its domain topology, it can report the topology 243 to the MDSC. When a service arrives, the MDSC computes the path and 244 coordinates PNCs to establish the corresponding LSP segment. 246 Alternatively, the NETCONF protocol can be used to retrieve topology 247 information utilizing the [TE-TOPO] Yang model and the technology- 248 specific YANG model augmentations required for the specific network 249 technology. The PNC can retrieve topology information from any NE 250 (the GMPLS control plane instance of each NE in the domain has the 251 same topological view), construct the topology of the domain and 252 export an abstracted view to the MDSC. Based on the topology 253 retrieved from multiple PNCs, the MDSC can create topology graph of 254 the multi-domain network, and can use it for path computation. To 255 setup a service, the MDSC can exploit Yang tunnel model together 256 with the technology-specific YANG model augmentations. 258 3. Link Management Protocol 260 Link management protocol (LMP) [RFC4204] runs between a pair of 261 nodes and is used to manage TE links. In addition to setup and 262 maintain control channels, LMP can be used to verify the data link 263 connectivity and correlate the link property. In this way, link 264 resources, which are fundamental resources in the network, are 265 discovered by both ends of the link. 267 4. Routing Options 269 In GMPLS control, link state information is flooded within the 270 network as defined in [RFC4202]. Each node in the network can build 271 the network topology according to the flooded link state 272 information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE 273 [RFC5307] have been extended to support different interfaces in 274 GMPLS. 276 In centralized controller system, central controller can be placed 277 at the GMPLS network and passively receive the information flooded 278 in the network. In this way, the central controller can construct 279 and update the network topology. 281 4.1. OSPF-TE 283 OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions 284 have been defined in [RFC4203] to enable the capability of link 285 state information for GMPLS network. Based on this work, OSPF 286 protocol has been extended to support technology-specific routing. 287 The routing protocol for OTN, WSON and optical flexi-grid network 288 are defined in [RFC7138], [RFC7688] and [RFC8363], respectively. 290 4.2. ISIS-TE 292 ISIS-TE is introduced for TE networks in [RFC5305] and is extended 293 to support GMPLS routing functions [RFC5307], and has been updated 294 to [RFC7074] to support the latest GMPLS switching capability and 295 Types fields. 297 4.3. Netconf/RESTconf 299 Netconf [RFC6241] and RESTconf [RFC8040] protocols are originally 300 used for network configuration. Besides, these protocols can also be 301 used for topology retrieval by using topology-related YANG models, 302 such as [RFC8345] and [TE-topo]. These protocols provide a powerful 303 mechanism for notification that permits to notify the client about 304 topology changes. 306 5. Path Computation 308 Once a controller learn the network topology, it can utilize the 309 available resources to serve service requests by performing path 310 computation. Due to abstraction, the MDSC may not have sufficient 311 information to compute the optimal path. In this case, the MDSC can 312 interact with different domain controllers by sending Yang Path 313 Computation requests [PAT-COMP] to compute a set of potential 314 optimal paths and then, based on its own constraints, policy and 315 specific knowledge (e.g. cost of access link) can choose the more 316 feasible path for service e2e path setup. 318 Path computation is one of the key objectives in various types of 319 controllers. In the given architecture, it is possible for different 320 components that have the capability to compute the path. 322 5.1. Constraint-based Path Computing in GMPLS Control 324 In GMPLS control, a routing path is computed by the ingress node 325 [RFC3473] and is based on the ingress node TED. Constraint-based 326 path computation is performed according to the local policy of the 327 ingress node. 329 5.2. Path Computation Element (PCE) 331 PCE has been introduced in [RFC4655] as a functional component that 332 provides services to compute path in a network. In [RFC5440], the 333 path computation is accomplished by using the Traffic Engineering 334 Database (TED), which maintains the link resources in the network. 335 The emergence of PCE efficiently improve the quality of network 336 planning and offline computation, but there is a risk that the 337 computed path may be infeasible if there is a diversity requirement, 338 because stateless PCE has no knowledge about the former computed 339 paths. 341 To address this issue, stateful PCE has been proposed in [RFC8231]. 342 Besides the TED, an additional LSP Database (LSP-DB) is introduced 343 to archive each LSP computed by the PCE. In this way, PCE can easily 344 figure out the relationship between the computing path and former 345 computed paths. In this approach, PCE provides computed paths to 346 PCC, and then PCC decides which path is deployed and when to be 347 established. 349 In PCE Initiation [I-D.ietf-pce-pce-initiated-lsp], PCE is allowed 350 to trigger the PCC to setup, maintenance, and teardown of the PCE- 351 initiated LSP under the stateful PCE model. This would allow a 352 dynamic network that is centrally controlled and deployed. 354 In centralized controller system, the PCE can be implement in a 355 central controller, and the central controller performs path 356 computation according to its local policies. On the other hand, the 357 PCE can also be placed outside of the central controller. In this 358 case, the central controller acts as a PCC to request path 359 computation to the PCE through PCEP. 361 6. Signaling Options 363 Signaling mechanism is used to setup LSPs in GMPLS control. Messages 364 are sent hop by hop between the ingress node and the egress node of 365 the LSP to allocate labels. Once the labels are allocated along the 366 path, the LSP setup is accomplished. Signaling protocols such as 367 RSVP-TE [RFC3473] and CR-LDP [RFC3472] have been extended to support 368 different interfaces in GMPLS. 370 6.1. RSVP-TE 372 RSVP-TE is introduced in [RFC3209] and extended to support GMPLS 373 signaling in [RFC3473]. Several label formats are defined for a 374 generalized label request, a generalized label, suggested label and 375 label sets. Based on [RFC3473], RSVP-TE has been extended to support 376 technology-specific signaling. The RSVP-TE extensions for OTN, WSON, 377 optical flexi-grid network are defined in [RFC7139], [RFC7689], and 378 [RFC7792], respectively. 380 7. Interworking Scenarios 382 7.1. Topology Collection & Synchronization 384 Topology information is necessary on both network elements and 385 controllers. The topology on network element is usually raw 386 information, while the topology on the controller can be either raw 387 or abstracted. Three different abstraction method has been described 388 in [RFC8453], and different controllers can select the corresponding 389 method depending on application. 391 When there are changes in the network topology, the impacted network 392 element(s) need to report changes to all the other network elements, 393 together with the controller, to sync up the topology information. 394 The inter-NE synchronization can be achieved via protocols mentioned 395 in section 3 and 4. The topology synchronization between NEs and 396 controllers can either be achieved by routing protocols OSPF- 397 TE/PCEP-LS in [PCEP-LS] or Netconf protocol with YANG model. 399 7.2. Multi-domain/layer Service Provisioning 401 Based on the topology information on controllers and network 402 elements, service provisioning can be deployed. Plenty of methods 403 have been specified for single domain service provisioning, such as 404 using PCEP and RSVP-TE. 406 Multi-domain/layer service provisioning would request coordination 407 among the controller hierarchies. Given the service request, the 408 end-to-end delivery procedure may include interactions on MPI and 409 SBI. The computation for a cross-domain/layer path is usually 410 completed by MDSC, who has a global view of the topologies. Then the 411 configuration is decomposed into lower layer controllers, including 412 both MDSC and PNCs, to configure the network elements to set up the 413 path. 415 A combination of the centralized and distributed protocols may be 416 necessary for the interaction between network elements and 417 controller. A typical example would be the PCE Initiation scenario, 418 in which a PCE message (PCInitiate) is sent from the controller to 419 the first-end node, and then trigger a RSVP procedure along the 420 path. Similarly, the interaction between the controller and the 421 ingress node of a domain can be achieved by Netconf protocol with 422 corresponding YANG models, and then completed by running RSVP among 423 the network elements. 425 7.3. Recovery 427 The GMPLS recovery functions are described in [RFC4426]. Two models, 428 span protection and end-to-end protection and restoration, are 429 discussed with different protection schemes and message exchange 430 requirements. Related RSVP-TE extensions to support end-to-end 431 recovery is described in [RFC4872]. The extensions in [RFC4872] 432 include protection, restoration, preemption, and rerouting 433 mechanisms for an end-to-end LSP. Besides end-to-end recovery, a 434 GMPLS segment recovery mechanism is defined in [RFC4873]. By 435 introducing secondary record route objects, LSP segment can be 436 switched to another path like fast reroute [RFC4090]. 438 For the recovery with controllers, timely interaction between 439 controller and network elements are required. Usually the re-routing 440 can be decomposed into path computation and delivery, the controller 441 can take some advantage in the path computation due to the global 442 topology view. And the delivery can be achieved by the procedure 443 described in section 7.2. 445 7.4. Controller Reliability 447 Given the important role in the network, the reliability of 448 controller is critical. Once a controller is shut down, the network 449 should operate as well. It can be either achieved by controller back 450 up or functionality back up. There are several of controller backup 451 or federation mechanisms in the literature. It is also more reliable 452 to have some function back up in the network element, to guarantee 453 the performance in the network. 455 8. Network Management 457 TBD. 459 9. Security Considerations 461 TBD. 463 10. IANA Considerations 465 This document requires no IANA actions. 467 11. References 469 11.1. Normative References 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", RFC 2119, March 1997. 474 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 475 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 476 Tunnels", RFC 3209, December 2001. 478 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 479 Switching (GMPLS) Signaling Functional Description", RFC 480 3471, January 2003. 482 [RFC3472] Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized 483 Multi-Protocol Label Switching (GMPLS) Signaling 484 Constraint-based Routed Label Distribution Protocol (CR- 485 LDP) Extensions", RFC 3472, January 2003. 487 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 488 Switching (GMPLS) Signaling Resource ReserVation Protocol- 489 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 490 January 2003. 492 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 493 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 494 September 2003. 496 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 497 Switching (GMPLS) Architecture", RFC 3945, October 2004. 499 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 500 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 501 May 2005. 503 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing 504 Extensions in Support of Generalized Multi-Protocol Label 505 Switching (GMPLS)", RFC 4202, October 2005. 507 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions 508 in Support of Generalized Multi-Protocol Label Switching 509 (GMPLS)", RFC 4203, October 2005. 511 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 512 4204, October 2005. 514 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. 515 Papadimitriou, Ed., "Generalized Multi-Protocol Label 516 witching (GMPLS) Recovery Functional Specification", RFC 517 4426, March 2006. 519 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 520 Element (PCE)-Based Architecture", RFC 4655, August 2006. 522 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 523 Ed., "RSVP-TE Extensions in Support of End-to-End 524 Generalized Multi-Protocol Label Switching (GMPLS) 525 Recovery", RFC 4872, May 2007. 527 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 528 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 530 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 531 Engineering", RFC 5305, October 2008. 533 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 534 in Support of Generalized Multi-Protocol Label Switching 535 (GMPLS)", RFC 5307, October 2008. 537 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 538 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 539 March 2009. 541 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., 542 "Network Configuration Protocol (NETCONF)", RFC 6241, June 543 2011. 545 [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the 546 GMPLS Switching Capability and Type Fields", RFC 7074, 547 November 2013. 549 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 550 J. Drake, "Traffic Engineering Extensions to OSPF for 551 GMPLS Control of Evolving G.709 Optical Transport 552 Networks", RFC 7138, March 2014. 554 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 555 and K. Pithewan, "GMPLS Signaling Extensions for Control 556 of Evolving G.709 Optical Transport Networks", RFC 7139, 557 March 2014. 559 [RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for 560 Application-Based Network Operations", RFC7491, March 561 2015. 563 [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF 564 Enhancement for Signal and Network Element Compatibility 565 for Wavelength Switched Optical Networks", RFC 7688, 566 November 2015. 568 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 569 and H. Harai, "Signaling Extensions for Wavelength 570 Switched Optical Networks", RFC 7689, November 2015. 572 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 573 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 574 Support of Flexi-Grid Dense Wavelength Division 575 Multiplexing (DWDM) Networks", RFC 7792, March 2016. 577 [RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli, 578 D. and Zhang, X., "Problem Statement and Architecture for 579 Information Exchange between Interconnected Traffic- 580 Engineered Networks", RFC7926, July 2016. 582 [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF 583 Protocol", RFC 8040, January 2017. 585 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 586 Computation Element Communication Protocol (PCEP) 587 Extensions for Stateful PCE", RFC 8231, September 2017. 589 [RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D. 590 Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi- 591 grid DWDM networks", RFC8363, February 2017. 593 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 594 Extensions for PCE-initiated LSP Setup in a Stateful PCE 595 Model", RFC 8281, October 2017. 597 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 598 Ananthakrishnan, H., Liu, X., "A YANG Data Model for 599 Network Topologies", RFC 8345, March 2018. 601 [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 602 Control of Traffic Engineered Networks", RFC 8453, August 603 2018. 605 [I-D. dhodylee-pce-pcep-ls] Dhody, D., Lee, Y., Ceccarelli, D., 606 "PCEP Extensions for Distribution of Link-State and TE 607 Information", draft-dhodylee-pce-pcep-ls, work in 608 progress. 610 [TE-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., 611 Gonzalez De Dios, O., "YANG Data Model for Traffic 612 Engineering (TE) Topologies", draft-ietf-teas-yang-te- 613 topo-15, work in progress. 615 [PAT-COMP] Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O., 616 Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang 617 model for requesting Path Computation", draft-ietf-teas- 618 yang-path-computation-01, work in progress. 620 11.2. Informative References 622 12. Authors' Addresses 624 Haomian Zheng 625 Huawei Technologies 626 F3 R&D Center, Huawei Industrial Base, 627 Bantian, Longgang District, 628 Shenzhen 518129 P.R.China 629 Email: zhenghaomian@huawei.com 631 Xianlong Luo 632 Huawei Technologies 633 F3 R&D Center, Huawei Industrial Base, 634 Bantian, Longgang District, 635 Shenzhen 518129 P.R.China 636 Email: luoxianlong@huawei.com 638 Yunbin Xu 639 CAICT 640 Email: xuyunbin@ritt.cn 642 Yang Zhao 643 China Mobile 644 Email: zhaoyangyjy@chinamobile.com 646 Sergio Belotti 647 Nokia 648 Email: sergio.belotti@nokia.com 650 Dieter Beller 651 Nokia 652 Email: Dieter.Beller@nokia.com