idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1744 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'TE-Tunnel' is defined on line 719, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-19 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Haomian Zheng 2 Internet Draft Xianlong Luo 3 Category: Informational Huawei Technologies 4 Yang Zhao 5 China Mobile 6 Yunbin Xu 7 CAICT 8 Sergio Belotti 9 Dieter Beller 10 Nokia 11 Expires: January 8, 2020 July 8, 2019 13 Interworking of GMPLS Control and Centralized Controller System 15 draft-ietf-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, 21 routing and signaling in a distributed manner. 23 On the other hand, with the development of software-defined 24 transport networking technology, a set of NEs can be controlled via 25 centralized controller hierarchies to address the issue from multi- 26 domain, multi-vendor and multi-technology. An example of such 27 centralized architecture is ACTN controller hierarchy described in 28 RFC 8453. 30 Instead of competing with each other, both the distributed and the 31 centralized control plane have their own advantages, and should be 32 complementary in the system. This document describes how the GMPLS 33 distributed control plane can interwork with a centralized 34 controller system in a transport network. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with 39 the provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other documents 48 at any time. It is inappropriate to use Internet-Drafts as 49 reference material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on January 8, 2020. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with 69 respect to this document. Code Components extracted from this 70 document must include Simplified BSD License text as described in 71 Section 4.e of the Trust Legal Provisions and are provided without 72 warranty as described in the Simplified BSD License. 74 Conventions used in this document 76 Table of Contents 78 1. Introduction...................................................3 79 2. Overview.......................................................4 80 2.1. Overview of GMPLS Control Plane..............................4 81 2.2. Overview of Centralized Controller System....................4 82 2.3. GMPLS Control Interwork with Centralized Controller System...4 83 3. Link Management Protocol............Error! Bookmark not defined. 84 4. Routing Options................................................6 85 4.1. OSPF-TE...................................................6 86 4.2. ISIS-TE...................................................7 87 4.3. Netconf/RESTconf..........................................7 88 5. Path Computation...............................................7 89 5.1. Constraint-based Path Computing in GMPLS Control..........7 90 5.2. Path Computation Element (PCE)............................7 91 6. Signaling Options..............................................8 92 6.1. RSVP-TE...................................................8 93 7. Interworking Scenarios.........................................8 94 7.1. Topology Collection & Synchronization.....................8 95 7.2. Multi-domain Service Provisioning.........................9 96 7.3. Multi-layer Service Provisioning.........................11 97 7.4. Recovery.................................................11 98 7.5. Controller Reliability...................................11 99 8. Manageability Considerations..................................12 100 9. Security Considerations.......................................12 101 10. IANA Considerations..........................................12 102 11. References...................................................12 103 11.1. Normative References....................................12 104 11.2. Informative References..................................14 105 12. Authors' Addresses ...........................................16 107 1. Introduction 109 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 110 MPLS to support different classes of interfaces and switching 111 capabilities such as Time-Division Multiplex Capable (TDM), Lambda 112 Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network 113 element (NE) running a GMPLS control plane collects network 114 information from other NEs and supports service provisioning through 115 signaling in a distributed manner. More generic description for 116 Traffic-engineering networking information exchange can be found in 117 [RFC7926]. 119 On the other hand, Software-Defined Networking (SDN) technologies 120 have been introduced to control the transport network in a 121 centralized manner. Central controllers can collect network 122 information from each node and provision services to corresponding 123 nodes. One of the examples is the Abstraction and Control of Traffic 124 Engineered Networks (ACTN) [RFC8453], which defines a hierarchical 125 architecture with Provisioning Network Controller(PNC), Multi-domain 126 Service Coordinator(MDSC) and Customer Network Controller(CNC) as 127 central controllers for different network abstraction levels. A Path 128 Computation Element (PCE) based approach has been proposed as 129 Application-Based Network Operations (ABNO) in [RFC7491]. 131 In such centralized controller architectures, GMPLS can be applied 132 for the NE-level control. A central controller may support GMPLS 133 enabled domains and may interact with a GMPLS enabled domain where 134 the GMPLS control plane does the service provisioning from ingress 135 to egress. In this case the centralized controller sends the request 136 to the ingress node and does not have to configure all NEs along the 137 path through the domain from ingress to egress thus leveraging the 138 GMPLS control plane. This document describes how GMPLS control 139 interworks with centralized controller system in transport network. 141 2. Overview 143 In this section, overviews of GMPLS control plane and centralized 144 controller system are discussed as well as the interactions between 145 the GMPLS control plane and centralized controllers. 147 2.1. Overview of GMPLS Control Plane 149 GMPLS separates the control plane and the data plane to support 150 time-division, wavelength, and spatial switching, which are 151 significant in transport networks. For the NE level control in 152 GMPLS, each node runs a GMPLS control plane instance. 153 Functionalities such as service provisioning, protection, and 154 restoration can be performed via GMPLS communication among multiple 155 NEs. At the same time, the controller can also collect node and 156 link resources in the network to construct the network topology and 157 compute routing paths for serving service requests. 159 Several protocols have been designed for GMPLS control [RFC3945] 160 including link management [RFC4204], signaling [RFC3471], and 161 routing [RFC4202] protocols. The controllers applying these 162 protocols communicate with each other to exchange resource 163 information and establish Label Switched Paths (LSPs). In this way, 164 controllers in different nodes in the network have the same view of 165 the network topology and provision services based on local policies. 167 2.2. Overview of Centralized Controller System 169 With the development of SDN technologies, a centralized controller 170 architecture has been introduced to transport networks. One example 171 architecture can be found in ACTN [RFC8453]. In such systems, a 172 controller is aware of the network topology and is responsible for 173 provisioning incoming service requests. 175 Multiple hierarchies of controllers are designed at different levels 176 implementing different functions. This kind of architecture enables 177 multi-vendor, multi-domain, and multi-technology control. For 178 example, a higher-level controller coordinates several lower-level 179 controllers controlling different domains, for topology collection 180 and service provisioning. Vendor-specific features can be abstracted 181 between controllers, and standard API (e.g., generated from 182 RESTconf/YANG) is used. 184 2.3. GMPLS Control Interwork with Centralized Controller System 186 Besides the GMPLS and the interactions among the controller 187 hierarchies, it is also necessary for the controllers to communicate 188 with the network elements. Within each domain, GMPLS control can be 189 applied to each NE. The bottom-level central controller can act as a 190 NE to collect network information and initiate LSP. Figure 1 shows 191 an example of GMPLS interworking with centralized controllers (ACTN 192 terminologies are used in the figure). 194 +--------------------+ 195 | Orchestrator | 196 +--------------------+ 197 ^ ^ ^ 198 | | | 199 +-------------+ | +------------+ 200 | | RESTConf/YANG models | 201 V V V 202 +----------+ +----------+ +----------+ 203 |Controller| |Controller| |Controller| 204 +----------+ +----------+ +----------+ 205 ^ ^ ^ ^ ^ 206 | | | | | 207 Netconf| |PCEP Netconf| |PCEP | IF* 208 /YANG | | /YANG | | | 209 V V V V V 210 .------------. Inter- .-----------. Inter- .-----------. 211 / \ domain / \ domain / \ 212 | | link | LMP | link | LMP | 213 | |======| OSPF-TE |=======| OSPF-TE | 214 | | | RSVP-TE | | RSVP-TE | 215 \ / \ / \ / 216 `-----------` `------------` `----------` 217 non-GMPLS domain 1 GMPLS domain 2 GMPLS domain 3 219 Figure 1: Example of GMPLS/non-GMPLS interworks with Controllers 221 Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS 222 domain. This system supports the interworking among non-GMPLS 223 domain, GMPLS domain and the controller hierarchies. For domain 1, 224 the network element were not enabled with GMPLS so the control can 225 be purely from the controller, via Netconf/YANG and/or PCEP. For 226 domain 2 and 3, each domain has the GMPLS control plane enabled at 227 the physical network level. The PNC can exploit GMPLS capability 228 implemented in the domain to listen to the IGP routing protocol 229 messages (OSPF LSAs for example) that the GMPLS control plane 230 instances are disseminating into the network and thus learn the 231 network topology. For path computation in the domain with PNC 232 implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP 233 to ask the PNC for a path and get replies. The MDSC communicates 234 with PNCs using for example REST/RESTConf based on YANG data models. 235 As a PNC has learned its domain topology, it can report the topology 236 to the MDSC. When a service arrives, the MDSC computes the path and 237 coordinates PNCs to establish the corresponding LSP segment. 239 Alternatively, the NETCONF protocol can be used to retrieve topology 240 information utilizing the e.g.[TE-topo] Yang model and the 241 technology-specific YANG model augmentations required for the 242 specific network technology. The PNC can retrieve topology 243 information from any NE (the GMPLS control plane instance of each NE 244 in the domain has the same topological view), construct the topology 245 of the domain and export an abstracted view to the MDSC. Based on 246 the topology retrieved from multiple PNCs, the MDSC can create 247 topology graph of the multi-domain network, and can use it for path 248 computation. To setup a service, the MDSC can exploit e.g.[TE- 249 Tunnel] Yang model together with the technology-specific YANG model 250 augmentations. 252 3. Discovery Options 254 In GMPLS control, the link connectivity need to be verified between 255 each pair of nodes. In this way, link resources, which are 256 fundamental resources in the network, are discovered by both ends of 257 the link. 259 3.1. LMP 261 Link management protocol (LMP) [RFC4204] runs between a pair of 262 nodes and is used to manage TE links. In addition to the setup and 263 maintenance of control channels, LMP can be used to verify the data 264 link connectivity and correlate the link property. 266 4. Routing Options 268 In GMPLS control, link state information is flooded within the 269 network as defined in [RFC4202]. Each node in the network can build 270 the network topology according to the flooded link state 271 information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE 272 [RFC5307] have been extended to support different interfaces in 273 GMPLS. 275 In centralized controller system, central controller can be placed 276 at the GMPLS network and passively receive the information flooded 277 in the network. In this way, the central controller can construct 278 and update the network topology. 280 4.1. OSPF-TE 282 OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions 283 have been defined in [RFC4203] to enable the capability of link 284 state information for GMPLS network. Based on this work, OSPF 285 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 learns the network topology, it can utilize the 309 available resources to serve service requests by performing path 310 computation. Due to abstraction, the controllers may not have 311 sufficient information to compute the optimal path. In this case, 312 the controller can interact with other controllers by sending Yang 313 Path 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 [RFC8281], PCE is allowed to trigger the PCC to 350 setup, maintenance, and teardown of the PCE-initiated LSP under the 351 stateful PCE model. This would allow a dynamic network that is 352 centrally controlled and deployed. 354 In centralized controller system, the PCE can be implemented 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. One of the reference 360 architecture can be found at [RFC7491]. 362 6. Signaling Options 364 Signaling mechanisms are used to setup LSPs in GMPLS control. 365 Messages are sent hop by hop between the ingress node and the egress 366 node of the LSP to allocate labels. Once the labels are allocated 367 along the path, the LSP setup is accomplished. Signaling protocols 368 such as RSVP-TE [RFC3473] have been extended to support different 369 interfaces in GMPLS. 371 6.1. RSVP-TE 373 RSVP-TE is introduced in [RFC3209] and extended to support GMPLS 374 signaling in [RFC3473]. Several label formats are defined for a 375 generalized label request, a generalized label, suggested label and 376 label sets. Based on [RFC3473], RSVP-TE has been extended to support 377 technology-specific signaling. The RSVP-TE extensions for OTN, WSON, 378 optical flexi-grid network are defined in [RFC7139], [RFC7689], and 379 [RFC7792], respectively. 381 7. Interworking Scenarios 383 7.1. Topology Collection & Synchronization 385 Topology information is necessary on both network elements and 386 controllers. The topology on network element is usually raw 387 information, while the topology on the controller can be either raw 388 or abstracted. Three different abstraction methods have been 389 described in [RFC8453], and different controllers can select the 390 corresponding method depending on application. 392 When there are changes in the network topology, the impacted network 393 element(s) need to report changes to all the other network elements, 394 together with the controller, to sync up the topology information. 395 The inter-NE synchronization can be achieved via protocols mentioned 396 in section 3 and 4. The topology synchronization between NEs and 397 controllers can either be achieved by routing protocols OSPF- 398 TE/PCEP-LS in [PCEP-LS] or Netconf protocol notifications with YANG 399 model. 401 7.2. Multi-domain Service Provisioning 403 Based on the topology information on controllers and network 404 elements, service provisioning can be deployed. Plenty of methods 405 have been specified for single domain service provisioning, such as 406 using PCEP and RSVP-TE. 408 Multi-domain service provisioning would request coordination among 409 the controller hierarchies. Given the service request, the end-to- 410 end delivery procedure may include interactions at any level (i.e. 411 interface) in the hierachy of the controllers (e.g. MPI and SBI for 412 ACTN). The computation for a cross-domain path is usually completed 413 by controllers who have a global view of the topologies. Then the 414 configuration is decomposed into lower layer controllers, to 415 configure the network elements to set up the path. 417 A combination of the centralized and distributed protocols may be 418 necessary for the interaction between network elements and 419 controller. Several methods can be used to create the inter-domain 420 path: 422 1) One end-to-end RSVP-TE session: 424 In this method, an end-to-end RSVP-TE session from the source NE to 425 the destination NE will be used to create the inter-domain path. A 426 typical example would be the PCE Initiation scenario, in which a PCE 427 message (PCInitiate) is sent from the controller to the first-end 428 node, and then trigger a RSVP procedure along the path. Similarly, 429 the interaction between the controller and the ingress node of a 430 domain can be achieved by Netconf protocol with corresponding YANG 431 models, and then completed by running RSVP among the network 432 elements. 434 This method requires the interworking of RSVP-TE protocols between 435 different domains. 437 2) Multiple RSVP-TE sessions for multiple path segments: 439 In this method, each SDN controller is responsible to create the 440 path segment within its domain. 442 Note that path segments in the source domain and the destination 443 domain are "asymmetrical" segments, because the configuration of 444 client signal mapping into server layer tunnel is needed at only one 445 end of the segment, while configuration of server layer cross- 446 connect is needed at the other end of the segment. For example, the 447 path segment 1 and 3 in Figure 3 are asymmetrical segments, because 448 one end of the segment requires mapping GE into ODU0, while the 449 other end of the segment requires setting up ODU0 cross-connect. 451 +-----------------+ +----------------+ +-----------------+ 452 |Client | | | | Client| 453 |Signal Domain 1| | Domain 2 | |Domain 3 Signal| 454 |(GE) | | | | (GE) | 455 | | ODU0 tunnel| | | | | | 456 |+-+-+ ^ | | | | +-+-+| 457 || | | +--+ |+--+| |+--+ +--+ +--+| |+--+ +--+ | | || 458 || | | | | || || || | | | | || || | | | | | || 459 || ******************************************************** || 460 || | | | | || . || | | | | || . || | | | | || 461 |+---+ +--+ +--+| . |+--+ +--+ +--+| . |+--+ +--+ +---+| 462 +-----------------+ . +----------------+ . +-----------------+ 463 . . . . 464 .<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->. 465 . . . . 467 Figure 3: Example of asymmetrical path segment 469 The PCEP / GMPLS protocols should support creation of such 470 asymmetrical segment. 472 Note also that mechanisms to assign the labels in the inter-domain 473 links are also needed to be considered. There are two possible 474 methods: 476 2.1) Inter-domain labels assigned by NEs: 478 The concept of Stitching Label that allows stitching local path 479 segments was introduced in [RFC5150] and [sPCE-ID], in order to form 480 the inter-domain path crossing several different domains. It also 481 describes the BRPC and H-PCE PCInitiate procedure, i.e., the ingress 482 boarder node of each downstream domain assigns the stitching label 483 for the inter-domain link between the downstream domain and its 484 upstream neighbor domain, and this stitching label will be passed to 485 the upstream neighbor domain by PCE protocol, which will be used for 486 the path segment creation in the upstream neighbor domain. 488 2.2) Inter-domain labels assigned by SDN controller: 490 If the resource of inter-domain links are managed by the multi- 491 domain SDN controller, each single-domain SDN controller can provide 492 to the multi-domain SDN controller the list of available labels 493 (e.g. timeslots if OTN is the scenario) using IETF Topology model 494 and related technology specific extension. Once that multi-domain 495 SDN controller has computed e2e path RSVP-TE or PCEP can be used in 496 the different domains to setup related segment tunnel consisting 497 with label inter-domain information, e.g. for PCEP the label ERO can 498 be included in the PCInitiate message to indicate the inter-domain 499 labels, so that each boarder node of each domain can configure the 500 correct cross-connect within itself. 502 7.3. Multi-layer Service Provisioning 504 For further study. Plan to be updated in the next version. 506 7.4. Recovery 508 The GMPLS recovery functions are described in [RFC4426]. Two models, 509 span protection and end-to-end protection and restoration, are 510 discussed with different protection schemes and message exchange 511 requirements. Related RSVP-TE extensions to support end-to-end 512 recovery is described in [RFC4872]. The extensions in [RFC4872] 513 include protection, restoration, preemption, and rerouting 514 mechanisms for an end-to-end LSP. Besides end-to-end recovery, a 515 GMPLS segment recovery mechanism is defined in [RFC4873]. By 516 introducing secondary record route objects, LSP segment can be 517 switched to another path like fast reroute [RFC4090]. 519 For the recovery with controllers, timely interaction between 520 controller and network elements are required. Usually the re-routing 521 can be decomposed into path computation and delivery, the controller 522 can take some advantage in the path computation due to the global 523 topology view. And the delivery can be achieved by the procedure 524 described in section 7.2. 526 7.5. Controller Reliability 528 Given the important role in the network, the reliability of 529 controller is critical. Once a controller is shut down, the network 530 should operate as well. It can be either achieved by controller back 531 up or functionality back up. There are several of controller backup 532 or federation mechanisms in the literature. It is also more reliable 533 to have some function back up in the network element, to guarantee 534 the performance in the network. 536 8. Manageability Considerations 538 Each entity in the network, including both controllers and network 539 elements, should be managed properly as it will interact with other 540 entities. The manageability considerations in controller hierarchies 541 and network elements still apply respectively. For the protocols 542 applied in the network, manageability is also requested. 544 The responsibility of each entity should be clarified. The control 545 of function and policy among different controllers should be 546 consistent via proper negotiation process. 548 9. Security Considerations 550 This document provides the interwork between the GMPLS and 551 controller hierarchies. The security requirements in both system 552 still applies respectively. Protocols referenced in this document 553 also have various security considerations, which is also expected to 554 be satisfied. 556 Other considerations on the interface between the controller and the 557 network element are also important. Such security includes the 558 functions to authenticate and authorize the control access to the 559 controller from multiple network elements. Security mechanisms on 560 the controller are also required to safeguard the underlying network 561 elements against attacks on the control plane and/or unauthorized 562 usage of data transport resources. 564 10. IANA Considerations 566 This document requires no IANA actions. 568 11. References 570 11.1. Normative References 572 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 573 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 574 Tunnels", RFC 3209, December 2001. 576 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 577 Switching (GMPLS) Signaling Resource ReserVation Protocol- 578 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 579 January 2003. 581 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 582 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 583 September 2003. 585 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 586 Switching (GMPLS) Architecture", RFC 3945, October 2004. 588 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions 589 in Support of Generalized Multi-Protocol Label Switching 590 (GMPLS)", RFC 4203, October 2005. 592 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 593 Element (PCE)-Based Architecture", RFC 4655, August 2006. 595 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 596 Ed., "RSVP-TE Extensions in Support of End-to-End 597 Generalized Multi-Protocol Label Switching (GMPLS) 598 Recovery", RFC 4872, May 2007. 600 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 601 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 603 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 604 Engineering", RFC 5305, October 2008. 606 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 607 in Support of Generalized Multi-Protocol Label Switching 608 (GMPLS)", RFC 5307, October 2008. 610 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 611 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 612 March 2009. 614 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., 615 "Network Configuration Protocol (NETCONF)", RFC 6241, June 616 2011. 618 [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the 619 GMPLS Switching Capability and Type Fields", RFC 7074, 620 November 2013. 622 [RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for 623 Application-Based Network Operations", RFC7491, March 624 2015. 626 [RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli, 627 D. and Zhang, X., "Problem Statement and Architecture for 628 Information Exchange between Interconnected Traffic- 629 Engineered Networks", RFC7926, July 2016. 631 [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF 632 Protocol", RFC 8040, January 2017. 634 [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 635 Control of Traffic Engineered Networks", RFC 8453, August 636 2018. 638 11.2. Informative References 640 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 641 Switching (GMPLS) Signaling Functional Description", RFC 642 3471, January 2003. 644 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 645 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 646 May 2005. 648 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 649 in Support of Generalized Multi-Protocol Label Switching 650 (GMPLS)", RFC 4202, October 2005. 652 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 653 4204, October 2005. 655 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. 656 Papadimitriou, Ed., "Generalized Multi-Protocol Label 657 witching (GMPLS) Recovery Functional Specification", RFC 658 4426, March 2006. 660 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, J.P., Farrel, A., 661 "Label Switched Path Stitching with Generalized 662 Multiprotocol Label Switching Traffic Engineering (GMPLS 663 TE)", RFC 5150, February, 2008. 665 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 666 J. Drake, "Traffic Engineering Extensions to OSPF for 667 GMPLS Control of Evolving G.709 Optical Transport 668 Networks", RFC 7138, March 2014. 670 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 671 and K. Pithewan, "GMPLS Signaling Extensions for Control 672 of Evolving G.709 Optical Transport Networks", RFC 7139, 673 March 2014. 675 [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF 676 Enhancement for Signal and Network Element Compatibility 677 for Wavelength Switched Optical Networks", RFC 7688, 678 November 2015. 680 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 681 and H. Harai, "Signaling Extensions for Wavelength 682 Switched Optical Networks", RFC 7689, November 2015. 684 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 685 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 686 Support of Flexi-Grid Dense Wavelength Division 687 Multiplexing (DWDM) Networks", RFC 7792, March 2016. 689 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 690 Computation Element Communication Protocol (PCEP) 691 Extensions for Stateful PCE", RFC 8231, September 2017. 693 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 694 Extensions for PCE-initiated LSP Setup in a Stateful PCE 695 Model", RFC 8281, October 2017. 697 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 698 Ananthakrishnan, H., Liu, X., "A YANG Data Model for 699 Network Topologies", RFC 8345, March 2018. 701 [RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D. 702 Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi- 703 grid DWDM networks", RFC8363, February 2017. 705 [TE-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., 706 Gonzalez De Dios, O., "YANG Data Model for Traffic 707 Engineering (TE) Topologies", draft-ietf-teas-yang-te- 708 topo-19, work in progress. 710 [PAT-COMP] Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O., 711 Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang 712 model for requesting Path Computation", draft-ietf-teas- 713 yang-path-computation-04, work in progress. 715 [PCEP-LS] Dhody, D., Lee, Y., Ceccarelli, D., "PCEP Extensions for 716 Distribution of Link-State and TE Information", draft- 717 dhodylee-pce-pcep-ls, work in progress. 719 [TE-Tunnel] Saad, T. et al., "A YANG Data Model for Traffic 720 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 721 te, work in progress. 723 [sPCE-ID] Dugeon, O. et al., "PCEP Extension for Stateful Inter- 724 Domain Tunnels", draft-dugeon-pce-stateful-interdomain, 725 work in progress. 727 12. Authors' Addresses 729 Haomian Zheng 730 Huawei Technologies 731 F3 R&D Center, Huawei Industrial Base, 732 Bantian, Longgang District, 733 Shenzhen 518129 P.R.China 734 Email: zhenghaomian@huawei.com 736 Xianlong Luo 737 Huawei Technologies 738 F3 R&D Center, Huawei Industrial Base, 739 Bantian, Longgang District, 740 Shenzhen 518129 P.R.China 741 Email: luoxianlong@huawei.com 743 Yunbin Xu 744 CAICT 745 Email: xuyunbin@ritt.cn 747 Yang Zhao 748 China Mobile 749 Email: zhaoyangyjy@chinamobile.com 751 Sergio Belotti 752 Nokia 753 Email: sergio.belotti@nokia.com 755 Dieter Beller 756 Nokia 757 Email: Dieter.Beller@nokia.com