idnits 2.17.1 draft-zheng-teas-gmpls-controller-inter-work-00.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 (August 3, 2018) is 2092 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 347, but not defined == Missing Reference: 'PCEP-LS' is mentioned on line 401, but not defined == Unused Reference: 'RFC8281' is defined on line 588, 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: February 3, 2019 August 3, 2018 13 Interworking of GMPLS Control and Centralized Controller System 15 draft-zheng-teas-gmpls-controller-inter-work-00 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 February 3, 2019. 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 [RFC8363], respectively. 288 4.2. ISIS-TE 290 ISIS-TE is introduced for TE networks in [RFC5305] and is extended 291 to support GMPLS routing functions [RFC5307], and has been updated 292 to [RFC7074] to support the latest GMPLS switching capability and 293 Types fields. 295 4.3. Netconf/RESTconf 297 Netconf [RFC6241] and RESTconf [RFC8040] protocols are originally 298 used for network configuration. Besides, these protocols can also be 299 used for topology retrieval by using topology-related YANG models, 300 such as [RFC8345] and [TE-topo]. These protocols provide a powerful 301 mechanism for notification that permits to notify the client about 302 topology changes. 304 5. Path Computation 306 Once a controller learn the network topology, it can utilize the 307 available resources to serve service requests by performing path 308 computation. Due to abstraction, the MDSC may not have sufficient 309 information to compute the optimal path. In this case, the MDSC can 310 interact with different domain controllers by sending Yang Path 311 Computation requests [PAT-COMP] to compute a set of potential 312 optimal paths and then, based on its own constraints, policy and 313 specific knowledge (e.g. cost of access link) can choose the more 314 feasible path for service e2e path setup. 316 Path computation is one of the key objectives in various types of 317 controllers. In the given architecture, it is possible for different 318 components that have the capability to compute the path. 320 5.1. Constraint-based Path Computing in GMPLS Control 322 In GMPLS control, a routing path is computed by the ingress node 323 [RFC3473] and is based on the ingress node TED. Constraint-based 324 path computation is performed according to the local policy of the 325 ingress node. 327 5.2. Path Computation Element (PCE) 329 PCE has been introduced in [RFC4655] as a functional component that 330 provides services to compute path in a network. In [RFC5440], the 331 path computation is accomplished by using the Traffic Engineering 332 Database (TED), which maintains the link resources in the network. 333 The emergence of PCE efficiently improve the quality of network 334 planning and offline computation, but there is a risk that the 335 computed path may be infeasible if there is a diversity requirement, 336 because stateless PCE has no knowledge about the former computed 337 paths. 339 To address this issue, stateful PCE has been proposed in [RFC8231]. 340 Besides the TED, an additional LSP Database (LSP-DB) is introduced 341 to archive each LSP computed by the PCE. In this way, PCE can easily 342 figure out the relationship between the computing path and former 343 computed paths. In this approach, PCE provides computed paths to 344 PCC, and then PCC decides which path is deployed and when to be 345 established. 347 In PCE Initiation [I-D.ietf-pce-pce-initiated-lsp], PCE is allowed 348 to trigger the PCC to setup, maintenance, and teardown of the PCE- 349 initiated LSP under the stateful PCE model. This would allow a 350 dynamic network that is centrally controlled and deployed. 352 In centralized controller system, the PCE can be implement in a 353 central controller, and the central controller performs path 354 computation according to its local policies. On the other hand, the 355 PCE can also be placed outside of the central controller. In this 356 case, the central controller acts as a PCC to request path 357 computation to the PCE through PCEP. 359 6. Signaling Options 361 Signaling mechanism is used to setup LSPs in GMPLS control. Messages 362 are sent hop by hop between the ingress node and the egress node of 363 the LSP to allocate labels. Once the labels are allocated along the 364 path, the LSP setup is accomplished. Signaling protocols such as 365 RSVP-TE [RFC3473] and CR-LDP [RFC3472] have been extended to support 366 different interfaces in GMPLS. 368 6.1. RSVP-TE 370 RSVP-TE is introduced in [RFC3209] and extended to support GMPLS 371 signaling in [RFC3473]. Several label formats are defined for a 372 generalized label request, a generalized label, suggested label and 373 label sets. Based on [RFC3473], RSVP-TE has been extended to support 374 technology-specific signaling. The RSVP-TE extensions for OTN, WSON, 375 optical flexi-grid network are defined in [RFC7139], [RFC7689], and 376 [RFC7792], respectively. 378 6.2. CR-LDP 380 In order to support the label formats and signaling mechanism 381 defined in [RFC3471], CR-LDP is extended in [RFC3472]. Several label 382 formats are defined and bidirectional LSPs are supported. 384 7. Interworking Scenarios 386 7.1. Topology Collection & Synchronization 388 Topology information is necessary on both network elements and 389 controllers. The topology on network element is usually raw 390 information, while the topology on the controller can be either raw 391 or abstracted. Three different abstraction method has been described 392 in [I-D.ietf-teas-actn-framework], and different controllers can 393 select the corresponding method depending on application. 395 When there are changes in the network topology, the impacted network 396 element(s) need to report changes to all the other network elements, 397 together with the controller, to sync up the topology information. 398 The inter-NE synchronization can be achieved via protocols mentioned 399 in section 3 and 4. The topology synchronization between NEs and 400 controllers can either be achieved by routing protocols OSPF- 401 TE/PCEP-LS in [PCEP-LS] or Netconf protocol with YANG model. 403 7.2. Multi-domain/layer Service Provisioning 405 Based on the topology information on controllers and network 406 elements, service provisioning can be deployed. Plenty of methods 407 have been specified for single domain service provisioning, such as 408 using PCEP and RSVP-TE. 410 Multi-domain/layer service provisioning would request coordination 411 among the controller hierarchies. Given the service request, the 412 end-to-end delivery procedure may include interactions on MPI and 413 SBI. The computation for a cross-domain/layer path is usually 414 completed by MDSC, who has a global view of the topologies. Then the 415 configuration is decomposed into lower layer controllers, including 416 both MDSC and PNCs, to configure the network elements to set up the 417 path. 419 A combination of the centralized and distributed protocols may be 420 necessary for the interaction between network elements and 421 controller. A typical example would be the PCE Initiation scenario, 422 in which a PCE message (PCInitiate) is sent from the controller to 423 the first-end node, and then trigger a RSVP procedure along the 424 path. Similarly, the interaction between the controller and the 425 ingress node of a domain can be achieved by Netconf protocol with 426 corresponding YANG models, and then completed by running RSVP among 427 the network elements. 429 7.3. Recovery 431 The GMPLS recovery functions are described in [RFC4426]. Two models, 432 span protection and end-to-end protection and restoration, are 433 discussed with different protection schemes and message exchange 434 requirements. Related RSVP-TE extensions to support end-to-end 435 recovery is described in [RFC4872]. The extensions in [RFC4872] 436 include protection, restoration, preemption, and rerouting 437 mechanisms for an end-to-end LSP. Besides end-to-end recovery, a 438 GMPLS segment recovery mechanism is defined in [RFC4873]. By 439 introducing secondary record route objects, LSP segment can be 440 switched to another path like fast reroute [RFC4090]. 442 For the recovery with controllers, timely interaction between 443 controller and network elements are required. Usually the re-routing 444 can be decomposed into path computation and delivery, the controller 445 can take some advantage in the path computation due to the global 446 topology view. And the delivery can be achieved by the procedure 447 described in section 7.2. 449 7.4. Controller Reliability 451 Given the important role in the network, the reliability of 452 controller is critical. Once a controller is shut down, the network 453 should operate as well. It can be either achieved by controller back 454 up or functionality back up. There are several of controller backup 455 or federation mechanisms in the literature. It is also more reliable 456 to have some function back up in the network element, to guarantee 457 the performance in the network. 459 8. Network Management 461 TBD. 463 9. Security Considerations 465 TBD. 467 10. IANA Considerations 469 This document requires no IANA actions. 471 11. References 473 11.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", RFC 2119, March 1997. 478 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 479 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 480 Tunnels", RFC 3209, December 2001. 482 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 483 Switching (GMPLS) Signaling Functional Description", RFC 484 3471, January 2003. 486 [RFC3472] Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized 487 Multi-Protocol Label Switching (GMPLS) Signaling 488 Constraint-based Routed Label Distribution Protocol (CR- 489 LDP) Extensions", RFC 3472, January 2003. 491 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 492 Switching (GMPLS) Signaling Resource ReserVation Protocol- 493 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 494 January 2003. 496 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 497 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 498 September 2003. 500 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 501 Switching (GMPLS) Architecture", RFC 3945, October 2004. 503 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 504 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 505 May 2005. 507 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing 508 Extensions in Support of Generalized Multi-Protocol Label 509 Switching (GMPLS)", RFC 4202, October 2005. 511 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions 512 in Support of Generalized Multi-Protocol Label Switching 513 (GMPLS)", RFC 4203, October 2005. 515 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 516 4204, October 2005. 518 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. 519 Papadimitriou, Ed., "Generalized Multi-Protocol Label 520 witching (GMPLS) Recovery Functional Specification", RFC 521 4426, March 2006. 523 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 524 Element (PCE)-Based Architecture", RFC 4655, August 2006. 526 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 527 Ed., "RSVP-TE Extensions in Support of End-to-End 528 Generalized Multi-Protocol Label Switching (GMPLS) 529 Recovery", RFC 4872, May 2007. 531 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 532 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 534 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 535 Engineering", RFC 5305, October 2008. 537 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 538 in Support of Generalized Multi-Protocol Label Switching 539 (GMPLS)", RFC 5307, October 2008. 541 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 542 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 543 March 2009. 545 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., 546 "Network Configuration Protocol (NETCONF)", RFC 6241, June 547 2011. 549 [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the 550 GMPLS Switching Capability and Type Fields", RFC 7074, 551 November 2013. 553 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 554 J. Drake, "Traffic Engineering Extensions to OSPF for 555 GMPLS Control of Evolving G.709 Optical Transport 556 Networks", RFC 7138, March 2014. 558 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 559 and K. Pithewan, "GMPLS Signaling Extensions for Control 560 of Evolving G.709 Optical Transport Networks", RFC 7139, 561 March 2014. 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 [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF 578 Protocol", RFC 8040, January 2017. 580 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 581 Computation Element Communication Protocol (PCEP) 582 Extensions for Stateful PCE", RFC 8231, September 2017. 584 [RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D. 585 Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi- 586 grid DWDM networks", RFC8363, February 2017. 588 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 589 Extensions for PCE-initiated LSP Setup in a Stateful PCE 590 Model", RFC 8281, October 2017. 592 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 593 Ananthakrishnan, H., Liu, X., "A YANG Data Model for 594 Network Topologies", RFC 8345, March 2018. 596 [I-D.ietf-teas-actn-framework] Ceccarelli, D. and Y. Lee, 597 "Framework for Abstraction and Control of Traffic 598 Engineered Networks", draft-ietf-teas-actn-framework work 599 in progress. 601 [I-D. dhodylee-pce-pcep-ls] Dhody, D., Lee, Y., Ceccarelli, D., 602 "PCEP Extensions for Distribution of Link-State and TE 603 Information", draft-dhodylee-pce-pcep-ls, work in 604 progress. 606 [TE-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., 607 Gonzalez De Dios, O., "YANG Data Model for Traffic 608 Engineering (TE) Topologies", draft-ietf-teas-yang-te- 609 topo-15, work in progress. 611 [PAT-COMP] Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O., 612 Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang 613 model for requesting Path Computation", draft-ietf-teas- 614 yang-path-computation-01, work in progress. 616 11.2. Informative References 618 12. Authors' Addresses 620 Haomian Zheng 621 Huawei Technologies 622 F3 R&D Center, Huawei Industrial Base, 623 Bantian, Longgang District, 624 Shenzhen 518129 P.R.China 625 Email: zhenghaomian@huawei.com 627 Xianlong Luo 628 Huawei Technologies 629 F3 R&D Center, Huawei Industrial Base, 630 Bantian, Longgang District, 631 Shenzhen 518129 P.R.China 632 Email: luoxianlong@huawei.com 634 Yunbin Xu 635 CAICT 636 Email: xuyunbin@ritt.cn 638 Yang Zhao 639 China Mobile 640 Email: zhaoyangyjy@chinamobile.com 642 Sergio Belotti 643 Nokia 644 Email: sergio.belotti@nokia.com 646 Dieter Beller 647 Nokia 648 Email: Dieter.Beller@nokia.com