idnits 2.17.1 draft-zheng-ccamp-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-teas-actn-framework]), 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 (June 27, 2018) is 2123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TE-TOPO' is mentioned on line 245, but not defined == Missing Reference: 'I-D.ietf-pce-pce-initiated-lsp' is mentioned on line 348, but not defined == Missing Reference: 'PCEP-LS' is mentioned on line 402, but not defined == Unused Reference: 'I-D.ietf-ccamp-flexible-grid-ospf-ext' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'RFC8281' is defined on line 591, 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 (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP 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: December 27, 2018 June 27, 2018 13 Interworking of GMPLS Control and Centralized Controller System 15 draft-zheng-ccamp-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 (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 [I-D.ietf- 29 teas-actn-framework]. 31 Instead of competing with each other, both the distributed and the 32 centralized control plane have their own advantage, and should be 33 complementary in the system. This document describes how the GMPLS 34 distributed control plane can interwork with a centralized 35 controller system in a transport network. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with 40 the provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other documents 49 at any time. It is inappropriate to use Internet-Drafts as 50 reference material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt. 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 This Internet-Draft will expire on December 27, 2018. 60 Copyright Notice 62 Copyright (c) 2018 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with 70 respect to this document. Code Components extracted from this 71 document must include Simplified BSD License text as described in 72 Section 4.e of the Trust Legal Provisions and are provided without 73 warranty as described in the Simplified BSD License. 75 Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 Table of Contents 83 1. Introduction ................................................ 3 84 2. Overview .................................................... 4 85 2.1. Overview of GMPLS Control Plane............................ 4 86 2.2. Overview of Centralized Controller System ................. 4 87 2.3. GMPLS Control Interwork with Centralized Controller System. 5 88 3. Link Management Protocol..................................... 6 89 4. Routing Options ............................................. 6 90 4.1. OSPF-TE ................................................ 6 91 4.2. ISIS-TE ................................................ 7 92 5. Path Computation ............................................ 7 93 5.1. Constraint-based Path Computing in GMPLS Control........ 7 94 5.2. Path Computation Element (PCE) ......................... 7 95 6. Signaling Options ........................................... 8 96 6.1. RSVP-TE ................................................ 8 97 6.2. CR-LDP ................................................. 9 98 7. Interworking Scenarios....................................... 9 99 7.1. Topology Collection & Synchronization .................. 9 100 7.2. Multi-domain/layer Service Provisioning ................ 9 101 7.3. Recovery .............................................. 10 102 7.4. Controller Reliability................................. 10 103 8. Network Management ......................................... 10 104 9. Security Considerations .................................... 10 105 10. IANA Considerations........................................ 10 106 11. References ................................................ 11 107 11.1. Normative References ................................. 11 108 11.2. Informative References................................ 14 109 12. Authors' Addresses ........................................ 14 111 1. Introduction 113 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 114 MPLS to support different classes of interfaces and switching 115 capabilities such as Time-Division Multiplex Capable (TDM), Lambda 116 Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network 117 element (NE) running a GMPLS control plane collects network 118 information from other NEs and supports service provisioning through 119 signaling in a distributed manner. 121 On the other hand, Software-Defined Networking (SDN) technologies 122 have been introduced to control the transport network in a 123 centralized manner. Central controllers can collect network 124 information from each node and provision services to corresponding 125 nodes. One of the examples is the Abstraction and Control of Traffic 126 Engineered Networks (ACTN) [I-D.ietf-teas-actn-framework], which 127 defines a hierarchical architecture with PNC, MDSC and CNC as 128 central controllers for different network abstraction levels. 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 LSP. In this way, controllers in different 163 nodes in the network have the same network topology and provision 164 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 [I-D.ietf-teas-actn-framework]. In centralized controller system, a 171 controller is aware of the network topology and is responsible for 172 provisioning incoming service requests. In ACTN, multiple 173 abstraction levels are designed and controllers at different levels 174 implement different functions. This kind of abstraction enables 175 multi-vendor, multi-domain, and 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 [I-D.ietf-teas-actn-framework] defines a 192 hierarchical controller architecture and describes how these 193 controllers communicate with each other in order to control a multi- 194 domain transport network. The controllers at the different levels in 195 the hierarchy typically perform network abstraction of the domain 196 they control and provide an abstracted view of their domain to the 197 controller at the next level in the hierarchy. The controllers at 198 the different hierarchical levels also interact with each other 199 during end-to-end service establishment, which can span multiple 200 domains. Within each domain, GMPLS control can be applied to each 201 NE. The bottom-level central controller like PNC can act as a NE to 202 collect network information and initiate LSP. Following figure shows 203 an example of GMPLS 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 setup and 260 maintain control channels, LMP can be used to verify the data link 261 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. 285 The routing protocol for OTN, WSON and optical flexi-grid network 286 are defined in [RFC7138], [RFC7688] and [I-D.ietf-ccamp-flexible- 287 grid-ospf-ext], 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 learn 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 [I-D.ietf-pce-pce-initiated-lsp], PCE is allowed 349 to trigger the PCC to setup, maintenance, and teardown of the PCE- 350 initiated LSP under the stateful PCE model. This would allow a 351 dynamic network that is 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 mechanism is used to setup LSPs in GMPLS control. Messages 363 are sent hop by hop between the ingress node and the egress node of 364 the LSP to allocate labels. Once the labels are allocated along the 365 path, the LSP setup is accomplished. Signaling protocols such as 366 RSVP-TE [RFC3473] and CR-LDP [RFC3472] have been extended to support 367 different 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 6.2. CR-LDP 381 In order to support the label formats and signaling mechanism 382 defined in [RFC3471], CR-LDP is extended in [RFC3472]. Several label 383 formats are defined and bidirectional LSPs are supported. 385 7. Interworking Scenarios 387 7.1. Topology Collection & Synchronization 389 Topology information is necessary on both network elements and 390 controllers. The topology on network element is usually raw 391 information, while the topology on the controller can be either raw 392 or abstracted. Three different abstraction method has been described 393 in [I-D.ietf-teas-actn-framework], and different controllers can 394 select the corresponding method depending on application. 396 When there are changes in the network topology, the impacted network 397 element(s) need to report changes to all the other network elements, 398 together with the controller, to sync up the topology information. 399 The inter-NE synchronization can be achieved via protocols mentioned 400 in section 3 and 4. The topology synchronization between NEs and 401 controllers can either be achieved by routing protocols OSPF- 402 TE/PCEP-LS in [PCEP-LS] or Netconf protocol with YANG model. 404 7.2. Multi-domain/layer Service Provisioning 406 Based on the topology information on controllers and network 407 elements, service provisioning can be deployed. Plenty of methods 408 have been specified for single domain service provisioning, such as 409 using PCEP and RSVP-TE. 411 Multi-domain/layer service provisioning would request coordination 412 among the controller hierarchies. Given the service request, the 413 end-to-end delivery procedure may include interactions on MPI and 414 SBI. The computation for a cross-domain/layer path is usually 415 completed by MDSC, who has a global view of the topologies. Then the 416 configuration is decomposed into lower layer controllers, including 417 both MDSC and PNCs, to configure the network elements to set up the 418 path. 420 A combination of the centralized and distributed protocols may be 421 necessary for the interaction between network elements and 422 controller. A typical example would be the PCE Initiation scenario, 423 in which a PCE message (PCInitiate) is sent from the controller to 424 the first-end node, and then trigger a RSVP procedure along the 425 path. Similarly, the interaction between the controller and the 426 ingress node of a domain can be achieved by Netconf protocol with 427 corresponding YANG models, and then completed by running RSVP among 428 the network elements. 430 7.3. Recovery 432 The GMPLS recovery functions are described in [RFC4426]. Two models, 433 span protection and end-to-end protection and restoration, are 434 discussed with different protection schemes and message exchange 435 requirements. Related RSVP-TE extensions to support end-to-end 436 recovery is described in [RFC4872]. The extensions in [RFC4872] 437 include protection, restoration, preemption, and rerouting 438 mechanisms for an end-to-end LSP. Besides end-to-end recovery, a 439 GMPLS segment recovery mechanism is defined in [RFC4873]. By 440 introducing secondary record route objects, LSP segment can be 441 switched to another path like fast reroute [RFC4090]. 443 For the recovery with controllers, timely interaction between 444 controller and network elements are required. Usually the re-routing 445 can be decomposed into path computation and delivery, the controller 446 can take some advantage in the path computation due to the global 447 topology view. And the delivery can be achieved by the procedure 448 described in section 7.2. 450 7.4. Controller Reliability 452 Given the important role in the network, the reliability of 453 controller is critical. Once a controller is shut down, the network 454 should operate as well. It can be either achieved by controller back 455 up or functionality back up. There are several of controller backup 456 or federation mechanisms in the literature. It is also more reliable 457 to have some function back up in the network element, to guarantee 458 the performance in the network. 460 8. Network Management 462 TBD. 464 9. Security Considerations 466 TBD. 468 10. IANA Considerations 470 This document requires no IANA actions. 472 11. References 474 11.1. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", RFC 2119, March 1997. 479 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 480 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 481 Tunnels", RFC 3209, December 2001. 483 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 484 Switching (GMPLS) Signaling Functional Description", RFC 485 3471, January 2003. 487 [RFC3472] Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized 488 Multi-Protocol Label Switching (GMPLS) Signaling 489 Constraint-based Routed Label Distribution Protocol (CR- 490 LDP) Extensions", RFC 3472, January 2003. 492 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 493 Switching (GMPLS) Signaling Resource ReserVation Protocol- 494 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 495 January 2003. 497 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 498 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 499 September 2003. 501 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 502 Switching (GMPLS) Architecture", RFC 3945, October 2004. 504 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 505 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 506 May 2005. 508 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing 509 Extensions in Support of Generalized Multi-Protocol Label 510 Switching (GMPLS)", RFC 4202, October 2005. 512 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions 513 in Support of Generalized Multi-Protocol Label Switching 514 (GMPLS)", RFC 4203, October 2005. 516 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 517 4204, October 2005. 519 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. 520 Papadimitriou, Ed., "Generalized Multi-Protocol Label 521 witching (GMPLS) Recovery Functional Specification", RFC 522 4426, March 2006. 524 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 525 Element (PCE)-Based Architecture", RFC 4655, August 2006. 527 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 528 Ed., "RSVP-TE Extensions in Support of End-to-End 529 Generalized Multi-Protocol Label Switching (GMPLS) 530 Recovery", RFC 4872, May 2007. 532 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 533 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 535 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 536 Engineering", RFC 5305, October 2008. 538 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 539 in Support of Generalized Multi-Protocol Label Switching 540 (GMPLS)", RFC 5307, October 2008. 542 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 543 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 544 March 2009. 546 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., 547 "Network Configuration Protocol (NETCONF)", RFC 6241, June 548 2011. 550 [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the 551 GMPLS Switching Capability and Type Fields", RFC 7074, 552 November 2013. 554 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 555 J. Drake, "Traffic Engineering Extensions to OSPF for 556 GMPLS Control of Evolving G.709 Optical Transport 557 Networks", RFC 7138, March 2014. 559 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 560 and K. Pithewan, "GMPLS Signaling Extensions for Control 561 of Evolving G.709 Optical Transport Networks", RFC 7139, 562 March 2014. 564 [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF 565 Enhancement for Signal and Network Element Compatibility 566 for Wavelength Switched Optical Networks", RFC 7688, 567 November 2015. 569 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 570 and H. Harai, "Signaling Extensions for Wavelength 571 Switched Optical Networks", RFC 7689, November 2015. 573 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 574 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 575 Support of Flexi-Grid Dense Wavelength Division 576 Multiplexing (DWDM) Networks", RFC 7792, March 2016. 578 [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF 579 Protocol", RFC 8040, January 2017. 581 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 582 Computation Element Communication Protocol (PCEP) 583 Extensions for Stateful PCE", RFC 8231, September 2017. 585 [I-D.ietf-ccamp-flexible-grid-ospf-ext] Zhang, X., Zheng, H., 586 Casellas, R., Dios, O., and D. Ceccarelli, "GMPLS OSPF-TE 587 Extensions in support of Flexi-grid DWDM networks", draft- 588 ietf-ccamp-flexible-grid-ospf-ext-09 (work in progress), 589 February 2017. 591 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 592 Extensions for PCE-initiated LSP Setup in a Stateful PCE 593 Model", RFC 8281, October 2017. 595 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 596 Ananthakrishnan, H., Liu, X., "A YANG Data Model for 597 Network Topologies", RFC 8345, March 2018. 599 [I-D.ietf-teas-actn-framework] Ceccarelli, D. and Y. Lee, 600 "Framework for Abstraction and Control of Traffic 601 Engineered Networks", draft-ietf-teas-actn-framework work 602 in progress. 604 [I-D. dhodylee-pce-pcep-ls] Dhody, D., Lee, Y., Ceccarelli, D., 605 "PCEP Extensions for Distribution of Link-State and TE 606 Information", draft-dhodylee-pce-pcep-ls, work in 607 progress. 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-15, 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-01, work in progress. 619 11.2. Informative References 621 12. Authors' Addresses 623 Haomian Zheng 624 Huawei Technologies 625 F3 R&D Center, Huawei Industrial Base, 626 Bantian, Longgang District, 627 Shenzhen 518129 P.R.China 628 Email: zhenghaomian@huawei.com 630 Xianlong Luo 631 Huawei Technologies 632 F3 R&D Center, Huawei Industrial Base, 633 Bantian, Longgang District, 634 Shenzhen 518129 P.R.China 635 Email: luoxianlong@huawei.com 637 Yunbin Xu 638 CAICT 639 Email: xuyunbin@ritt.cn 641 Yang Zhao 642 China Mobile 643 Email: zhaoyangyjy@chinamobile.com 645 Sergio Belotti 646 Nokia 647 Email: sergio.belotti@nokia.com 649 Dieter Beller 650 Nokia 651 Email: Dieter.Beller@nokia.com