idnits 2.17.1 draft-ietf-teas-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 : ---------------------------------------------------------------------------- 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 (November 4, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PAT-COMP' is mentioned on line 315, but not defined == Unused Reference: 'TE-Tunnel' is defined on line 766, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-19 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 Yi Lin 4 Category: Informational Huawei Technologies 5 Yang Zhao 6 China Mobile 7 Yunbin Xu 8 CAICT 9 Sergio Belotti 10 Dieter Beller 11 Nokia 12 Expires: May 4, 2020 November 4, 2019 14 Interworking of GMPLS Control and Centralized Controller System 16 draft-ietf-teas-gmpls-controller-inter-work-02 18 Abstract 20 Generalized Multi-Protocol Label Switching (GMPLS) control allows 21 each network element (NE) to perform local resource discovery, 22 routing and signaling in a 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 described in 29 RFC 8453. 31 Instead of competing with each other, both the distributed and the 32 centralized control plane have their own advantages, 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 May 4, 2020. 60 Copyright Notice 62 Copyright (c) 2019 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 Table of Contents 79 1. Introduction .................................................. 3 80 2. Overview ...................................................... 4 81 2.1. Overview of GMPLS Control Plane ............................. 4 82 2.2. Overview of Centralized Controller System ................... 4 83 2.3. GMPLS Control Interwork with Centralized Controller System .. 4 84 3. Discovery Options ............................................. 6 85 3.1. LMP ...................................................... 6 86 4. Routing Options ............................................... 6 87 4.1. OSPF-TE .................................................. 7 88 4.2. ISIS-TE .................................................. 7 89 4.3. Netconf/RESTconf ......................................... 7 90 5. Path Computation .............................................. 7 91 5.1. Constraint-based Path Computing in GMPLS Control ......... 7 92 5.2. Path Computation Element (PCE) ........................... 8 93 6. Signaling Options ............................................. 8 94 6.1. RSVP-TE .................................................. 8 95 7. Interworking Scenarios ........................................ 9 96 7.1. Topology Collection & Synchronization .................... 9 97 7.2. Multi-domain Service Provisioning ........................ 9 98 7.3. Multi-layer Service Provisioning ........................ 12 99 7.4. Recovery ................................................ 12 100 7.5. Controller Reliability .................................. 12 101 8. Manageability Considerations ................................. 13 102 9. Security Considerations ...................................... 13 103 10. IANA Considerations.......................................... 13 104 11. References .................................................. 13 105 11.1. Normative References ................................... 13 106 11.2. Informative References ................................. 15 107 12. Authors' Addresses .......................................... 17 109 1. Introduction 111 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 112 MPLS to support different classes of interfaces and switching 113 capabilities such as Time-Division Multiplex Capable (TDM), Lambda 114 Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network 115 element (NE) running a GMPLS control plane collects network 116 information from other NEs and supports service provisioning through 117 signaling in a distributed manner. More generic description for 118 Traffic-engineering networking information exchange can be found in 119 [RFC7926]. 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) [RFC8453], which defines a hierarchical 127 architecture with Provisioning Network Controller (PNC), Multi- 128 domain Service Coordinator (MDSC) and Customer Network Controller 129 (CNC) as central controllers for different network abstraction 130 levels. A Path Computation Element (PCE) based approach has been 131 proposed as Application-Based Network Operations (ABNO) in 132 [RFC7491]. 134 In such centralized controller architectures, GMPLS can be applied 135 for the NE-level control. A central controller may support GMPLS 136 enabled domains and may interact with a GMPLS enabled domain where 137 the GMPLS control plane does the service provisioning from ingress 138 to egress. In this case the centralized controller sends the request 139 to the ingress node and does not have to configure all NEs along the 140 path through the domain from ingress to egress thus leveraging the 141 GMPLS control plane. This document describes how GMPLS control 142 interworks with centralized controller system in transport network. 144 2. Overview 146 In this section, overviews of GMPLS control plane and centralized 147 controller system are discussed as well as the interactions between 148 the GMPLS control plane and centralized controllers. 150 2.1. Overview of GMPLS Control Plane 152 GMPLS separates the control plane and the data plane to support 153 time-division, wavelength, and spatial switching, which are 154 significant in transport networks. For the NE level control in 155 GMPLS, each node runs a GMPLS control plane instance. 156 Functionalities such as service provisioning, protection, and 157 restoration can be performed via GMPLS communication among multiple 158 NEs. At the same time, the controller can also collect node and 159 link resources in the network to construct the network topology and 160 compute routing paths for serving service requests. 162 Several protocols have been designed for GMPLS control [RFC3945] 163 including link management [RFC4204], signaling [RFC3471], and 164 routing [RFC4202] protocols. The controllers applying these 165 protocols communicate with each other to exchange resource 166 information and establish Label Switched Paths (LSPs). In this way, 167 controllers in different nodes in the network have the same view of 168 the network topology and provision services based on local policies. 170 2.2. Overview of Centralized Controller System 172 With the development of SDN technologies, a centralized controller 173 architecture has been introduced to transport networks. One example 174 architecture can be found in ACTN [RFC8453]. In such systems, a 175 controller is aware of the network topology and is responsible for 176 provisioning incoming service requests. 178 Multiple hierarchies of controllers are designed at different levels 179 implementing different functions. This kind of architecture enables 180 multi-vendor, multi-domain, and multi-technology control. For 181 example, a higher-level controller coordinates several lower-level 182 controllers controlling different domains, for topology collection 183 and service provisioning. Vendor-specific features can be abstracted 184 between controllers, and standard API (e.g., generated from 185 RESTconf/YANG) is used. 187 2.3. GMPLS Control Interwork with Centralized Controller System 189 Besides the GMPLS and the interactions among the controller 190 hierarchies, it is also necessary for the controllers to communicate 191 with the network elements. Within each domain, GMPLS control can be 192 applied to each NE. The bottom-level central controller can act as a 193 NE to collect network information and initiate LSP. Figure 1 shows 194 an example of GMPLS interworking with centralized controllers (ACTN 195 terminologies are used in the figure). 197 +--------------------+ 198 | Orchestrator | 199 +--------------------+ 200 ^ ^ ^ 201 | | | 202 +-------------+ | +------------+ 203 | | RESTConf/YANG models | 204 V V V 205 +----------+ +----------+ +----------+ 206 |Controller| |Controller| |Controller| 207 +----------+ +----------+ +----------+ 208 ^ ^ ^ ^ ^ 209 | | | | | 210 Netconf| |PCEP Netconf| |PCEP | IF* 211 /YANG | | /YANG | | | 212 V V V V V 213 .------------. Inter- .-----------. Inter- .-----------. 214 / \ domain / \ domain / \ 215 | | link | LMP | link | LMP | 216 | |======| OSPF-TE |=======| OSPF-TE | 217 | | | RSVP-TE | | RSVP-TE | 218 \ / \ / \ / 219 `-----------` `------------` `----------` 220 non-GMPLS domain 1 GMPLS domain 2 GMPLS domain 3 222 Figure 1: Example of GMPLS/non-GMPLS interworks with Controllers 224 Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS 225 domain. This system supports the interworking among non-GMPLS 226 domain, GMPLS domain and the controller hierarchies. For domain 1, 227 the network element were not enabled with GMPLS so the control can 228 be purely from the controller, via Netconf/YANG and/or PCEP. For 229 domain 2 and 3, each domain has the GMPLS control plane enabled at 230 the physical network level. The PNC can exploit GMPLS capability 231 implemented in the domain to listen to the IGP routing protocol 232 messages (OSPF LSAs for example) that the GMPLS control plane 233 instances are disseminating into the network and thus learn the 234 network topology. For path computation in the domain with PNC 235 implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP 236 to ask the PNC for a path and get replies. The MDSC communicates 237 with PNCs using for example REST/RESTConf based on YANG data models. 238 As a PNC has learned its domain topology, it can report the topology 239 to the MDSC. When a service arrives, the MDSC computes the path and 240 coordinates PNCs to establish the corresponding LSP segment. 242 Alternatively, the NETCONF protocol can be used to retrieve topology 243 information utilizing the e.g. [TE-topo] Yang model and the 244 technology-specific YANG model augmentations required for the 245 specific network technology. The PNC can retrieve topology 246 information from any NE (the GMPLS control plane instance of each NE 247 in the domain has the same topological view), construct the topology 248 of the domain and export an abstracted view to the MDSC. Based on 249 the topology retrieved from multiple PNCs, the MDSC can create 250 topology graph of the multi-domain network, and can use it for path 251 computation. To setup a service, the MDSC can exploit e.g. [TE- 252 Tunnel] Yang model together with the technology-specific YANG model 253 augmentations. 255 3. Discovery Options 257 In GMPLS control, the link connectivity need to be verified between 258 each pair of nodes. In this way, link resources, which are 259 fundamental resources in the network, are discovered by both ends of 260 the link. 262 3.1. LMP 264 Link management protocol (LMP) [RFC4204] runs between a pair of 265 nodes and is used to manage TE links. In addition to the setup and 266 maintenance of control channels, LMP can be used to verify the data 267 link connectivity and correlate the link property. 269 4. Routing Options 271 In GMPLS control, link state information is flooded within the 272 network as defined in [RFC4202]. Each node in the network can build 273 the network topology according to the flooded link state 274 information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE 275 [RFC5307] have been extended to support different interfaces in 276 GMPLS. 278 In centralized controller system, central controller can be placed 279 at the GMPLS network and passively receive the information flooded 280 in the network. In this way, the central controller can construct 281 and update the network topology. 283 4.1. OSPF-TE 285 OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions 286 have been defined in [RFC4203] to enable the capability of link 287 state information for GMPLS network. Based on this work, OSPF 288 protocol has been extended to support technology-specific routing. 289 The routing protocol for OTN, WSON and optical flexi-grid network 290 are defined in [RFC7138], [RFC7688] and [RFC8363], respectively. 292 4.2. ISIS-TE 294 ISIS-TE is introduced for TE networks in [RFC5305] and is extended 295 to support GMPLS routing functions [RFC5307], and has been updated 296 to [RFC7074] to support the latest GMPLS switching capability and 297 Types fields. 299 4.3. Netconf/RESTconf 301 Netconf [RFC6241] and RESTconf [RFC8040] protocols are originally 302 used for network configuration. Besides, these protocols can also be 303 used for topology retrieval by using topology-related YANG models, 304 such as [RFC8345] and [TE-topo]. These protocols provide a powerful 305 mechanism for notification that permits to notify the client about 306 topology changes. 308 5. Path Computation 310 Once a controller learns the network topology, it can utilize the 311 available resources to serve service requests by performing path 312 computation. Due to abstraction, the controllers may not have 313 sufficient information to compute the optimal path. In this case, 314 the controller can interact with other controllers by sending Yang 315 Path Computation requests [PAT-COMP] to compute a set of potential 316 optimal paths and then, based on its own constraints, policy and 317 specific knowledge (e.g. cost of access link) can choose the more 318 feasible path for service e2e path setup. 320 Path computation is one of the key objectives in various types of 321 controllers. In the given architecture, it is possible for different 322 components that have the capability to compute the path. 324 5.1. Constraint-based Path Computing in GMPLS Control 326 In GMPLS control, a routing path is computed by the ingress node 327 [RFC3473] and is based on the ingress node TED. Constraint-based 328 path computation is performed according to the local policy of the 329 ingress node. 331 5.2. Path Computation Element (PCE) 333 PCE has been introduced in [RFC4655] as a functional component that 334 provides services to compute path in a network. In [RFC5440], the 335 path computation is accomplished by using the Traffic Engineering 336 Database (TED), which maintains the link resources in the network. 337 The emergence of PCE efficiently improve the quality of network 338 planning and offline computation, but there is a risk that the 339 computed path may be infeasible if there is a diversity requirement, 340 because stateless PCE has no knowledge about the former computed 341 paths. 343 To address this issue, stateful PCE has been proposed in [RFC8231]. 344 Besides the TED, an additional LSP Database (LSP-DB) is introduced 345 to archive each LSP computed by the PCE. In this way, PCE can easily 346 figure out the relationship between the computing path and former 347 computed paths. In this approach, PCE provides computed paths to 348 PCC, and then PCC decides which path is deployed and when to be 349 established. 351 In PCE Initiation [RFC8281], PCE is allowed to trigger the PCC to 352 setup, maintenance, and teardown of the PCE-initiated LSP under the 353 stateful PCE model. This would allow a dynamic network that is 354 centrally controlled and deployed. 356 In centralized controller system, the PCE can be implemented in a 357 central controller, and the central controller performs path 358 computation according to its local policies. On the other hand, the 359 PCE can also be placed outside of the central controller. In this 360 case, the central controller acts as a PCC to request path 361 computation to the PCE through PCEP. One of the reference 362 architecture can be found at [RFC7491]. 364 6. Signaling Options 366 Signaling mechanisms are used to setup LSPs in GMPLS control. 367 Messages are sent hop by hop between the ingress node and the egress 368 node of the LSP to allocate labels. Once the labels are allocated 369 along the path, the LSP setup is accomplished. Signaling protocols 370 such as RSVP-TE [RFC3473] have been extended to support different 371 interfaces in GMPLS. 373 6.1. RSVP-TE 375 RSVP-TE is introduced in [RFC3209] and extended to support GMPLS 376 signaling in [RFC3473]. Several label formats are defined for a 377 generalized label request, a generalized label, suggested label and 378 label sets. Based on [RFC3473], RSVP-TE has been extended to support 379 technology-specific signaling. The RSVP-TE extensions for OTN, WSON, 380 optical flexi-grid network are defined in [RFC7139], [RFC7689], and 381 [RFC7792], respectively. 383 7. Interworking Scenarios 385 7.1. Topology Collection & Synchronization 387 Topology information is necessary on both network elements and 388 controllers. The topology on network element is usually raw 389 information, while the topology on the controller can be either raw 390 or abstracted. Three different abstraction methods have been 391 described in [RFC8453], and different controllers can select the 392 corresponding method depending on application. 394 When there are changes in the network topology, the impacted network 395 element(s) need to report changes to all the other network elements, 396 together with the controller, to sync up the topology information. 397 The inter-NE synchronization can be achieved via protocols mentioned 398 in section 3 and 4. The topology synchronization between NEs and 399 controllers can either be achieved by routing protocols OSPF- 400 TE/PCEP-LS in [PCEP-LS] or Netconf protocol notifications with YANG 401 model. 403 7.2. Multi-domain 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 service provisioning would request coordination among 411 the controller hierarchies. Given the service request, the end-to- 412 end delivery procedure may include interactions at any level (i.e. 413 interface) in the hierachy of the controllers (e.g. MPI and SBI for 414 ACTN). The computation for a cross-domain path is usually completed 415 by controllers who have a global view of the topologies. Then the 416 configuration is decomposed into lower layer controllers, to 417 configure the network elements to set up the path. 419 A combination of the centralized and distributed protocols may be 420 necessary for the interaction between network elements and 421 controller. Several methods can be used to create the inter-domain 422 path: 424 1) With end-to-end RSVP-TE session: 426 In this method, the SDN controller of the source domain triggers the 427 source node to create the end-to-end RSVP-TE session, and the 428 assignment and distribution of the labels on the inter-domain links 429 are done by the boarder nodes of each domain, using RSVP-TE 430 protocol. Therefore, this method requires the interworking of RSVP- 431 TE protocols between different domains. 433 There are two possible methods: 435 1.1) One single end-to-end RSVP-TE session 437 In this method, an end-to-end RSVP-TE session from the source NE to 438 the destination NE will be used to create the inter-domain path. A 439 typical example would be the PCE Initiation scenario, in which a PCE 440 message (PCInitiate) is sent from the controller to the first-end 441 node, and then trigger a RSVP procedure along the path. Similarly, 442 the interaction between the controller and the ingress node of a 443 domain can be achieved by Netconf protocol with corresponding YANG 444 models, and then completed by running RSVP among the network 445 elements. 447 1.2) LSP Stitching 449 The LSP stitching method defined in [RFC5150] can also be used to 450 create the end-to-end LSP. I.e., when the source node receives an 451 end-to-end path creation request (e.g., using PCEP or Netconf 452 protocol), the source node starts an end-to-end RSVP-TE session 453 along the end points of each LSP segment (refers to S-LSP in 454 [RFC5150]) of each domain, to assign the labels on the inter-domain 455 links between each pair of neighbor S-LSPs, and stitch the end-to- 456 end LSP to each S-LSP. See Figure 2 as an example. Note that the S- 457 LSP in each domain can be either created by each domain controller 458 in advance, or created dynamically triggered by the end-to-end RSVP- 459 TE session. 461 +-----------------+ +----------------+ +-----------------+ 462 |Client | | | | Client| 463 |Signal Domain 1| | Domain 2 | |Domain 3 Signal| 464 | | | | | | | | 465 |+-+-+ | | | | +-+-+| 466 || | | +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ | | || 467 || | | | | | || || | | | | || || | | | | | || 468 || ******************************************************** || 469 || | | | | || || | | | | || || | | | | || 470 |+---+ +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ +---+| 471 +-----------------+ +----------------+ +-----------------+ 472 | . . . . . . | 473 | .<-S-LSP 1->. .<- S-LSP 2 -->. .<-S-LSP 3->. | 474 | . . . . | 475 |-------------->.---->.------------->.---->.-------------->| 476 |<--------------.<----.<-------------.<----.<--------------| 477 | End-to-end RSVP-TE session for LSP stitching | 479 Figure 2: LSP stitching 480 2) Without end-to-end RSVP-TE session: 482 In this method, each SDN controller is responsible to create the 483 path segment within its domain. The boarder node does not need to 484 communicate with other boarder nodes in other domains for the 485 distribution of labels on inter-domain links, so end-to-end RSVP-TE 486 session through multiple domains is not required, and the 487 interworking of RSVP-TE protocol between different domains is not 488 needed. 490 Note that path segments in the source domain and the destination 491 domain are "asymmetrical" segments, because the configuration of 492 client signal mapping into server layer tunnel is needed at only one 493 end of the segment, while configuration of server layer cross- 494 connect is needed at the other end of the segment. For example, the 495 path segment 1 and 3 in Figure 3 are asymmetrical segments, because 496 one end of the segment requires mapping GE into ODU0, while the 497 other end of the segment requires setting up ODU0 cross-connect. 499 +-----------------+ +----------------+ +-----------------+ 500 |Client | | | | Client| 501 |Signal Domain 1| | Domain 2 | |Domain 3 Signal| 502 |(GE) | | | | (GE) | 503 | | ODU0 tunnel| | | | | | 504 |+-+-+ ^ | | | | +-+-+| 505 || | | +--+ |+--+| |+--+ +--+ +--+| |+--+ +--+ | | || 506 || | | | | || || || | | | | || || | | | | | || 507 || ******************************************************** || 508 || | | | | || . || | | | | || . || | | | | || 509 |+---+ +--+ +--+| . |+--+ +--+ +--+| . |+--+ +--+ +---+| 510 +-----------------+ . +----------------+ . +-----------------+ 511 . . . . 512 .<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->. 513 . . . . 515 Figure 3: Example of asymmetrical path segment 517 The PCEP / GMPLS protocols should support creation of such 518 asymmetrical segment. 520 Note also that mechanisms to assign the labels in the inter-domain 521 links are also needed to be considered. There are two possible 522 methods: 524 2.1) Inter-domain labels assigned by NEs: 526 The concept of Stitching Label that allows stitching local path 527 segments was introduced in [RFC5150] and [sPCE-ID], in order to form 528 the inter-domain path crossing several different domains. It also 529 describes the BRPC and H-PCE PCInitiate procedure, i.e., the ingress 530 boarder node of each downstream domain assigns the stitching label 531 for the inter-domain link between the downstream domain and its 532 upstream neighbor domain, and this stitching label will be passed to 533 the upstream neighbor domain by PCE protocol, which will be used for 534 the path segment creation in the upstream neighbor domain. 536 2.2) Inter-domain labels assigned by SDN controller: 538 If the resource of inter-domain links are managed by the multi- 539 domain SDN controller, each single-domain SDN controller can provide 540 to the multi-domain SDN controller the list of available labels 541 (e.g. timeslots if OTN is the scenario) using IETF Topology model 542 and related technology specific extension. Once that multi-domain 543 SDN controller has computed e2e path RSVP-TE or PCEP can be used in 544 the different domains to setup related segment tunnel consisting 545 with label inter-domain information, e.g. for PCEP the label ERO can 546 be included in the PCInitiate message to indicate the inter-domain 547 labels, so that each boarder node of each domain can configure the 548 correct cross-connect within itself. 550 7.3. Multi-layer Service Provisioning 552 For further study. Plan to be updated in the next version. 554 7.4. Recovery 556 The GMPLS recovery functions are described in [RFC4426]. Two models, 557 span protection and end-to-end protection and restoration, are 558 discussed with different protection schemes and message exchange 559 requirements. Related RSVP-TE extensions to support end-to-end 560 recovery is described in [RFC4872]. The extensions in [RFC4872] 561 include protection, restoration, preemption, and rerouting 562 mechanisms for an end-to-end LSP. Besides end-to-end recovery, a 563 GMPLS segment recovery mechanism is defined in [RFC4873]. By 564 introducing secondary record route objects, LSP segment can be 565 switched to another path like fast reroute [RFC4090]. 567 For the recovery with controllers, timely interaction between 568 controller and network elements are required. Usually the re-routing 569 can be decomposed into path computation and delivery, the controller 570 can take some advantage in the path computation due to the global 571 topology view. And the delivery can be achieved by the procedure 572 described in section 7.2. 574 7.5. Controller Reliability 576 Given the important role in the network, the reliability of 577 controller is critical. Once a controller is shut down, the network 578 should operate as well. It can be either achieved by controller back 579 up or functionality back up. There are several of controller backup 580 or federation mechanisms in the literature. It is also more reliable 581 to have some function back up in the network element, to guarantee 582 the performance in the network. 584 8. Manageability Considerations 586 Each entity in the network, including both controllers and network 587 elements, should be managed properly as it will interact with other 588 entities. The manageability considerations in controller hierarchies 589 and network elements still apply respectively. For the protocols 590 applied in the network, manageability is also requested. 592 The responsibility of each entity should be clarified. The control 593 of function and policy among different controllers should be 594 consistent via proper negotiation process. 596 9. Security Considerations 598 This document provides the interwork between the GMPLS and 599 controller hierarchies. The security requirements in both system 600 still applies respectively. Protocols referenced in this document 601 also have various security considerations, which is also expected to 602 be satisfied. 604 Other considerations on the interface between the controller and the 605 network element are also important. Such security includes the 606 functions to authenticate and authorize the control access to the 607 controller from multiple network elements. Security mechanisms on 608 the controller are also required to safeguard the underlying network 609 elements against attacks on the control plane and/or unauthorized 610 usage of data transport resources. 612 10. IANA Considerations 614 This document requires no IANA actions. 616 11. References 618 11.1. Normative References 620 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 621 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 622 Tunnels", RFC 3209, December 2001. 624 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 625 Switching (GMPLS) Signaling Resource ReserVation Protocol- 626 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 627 January 2003. 629 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 630 (TE) Extensions to OSPF Version 2", RFC 3630, September 631 2003. 633 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 634 Switching (GMPLS) Architecture", RFC 3945, October 2004. 636 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 637 Support of Generalized Multi-Protocol Label Switching 638 (GMPLS)", RFC 4203, October 2005. 640 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 641 Element (PCE)-Based Architecture", RFC 4655, August 2006. 643 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 644 Ed., "RSVP-TE Extensions in Support of End-to-End 645 Generalized Multi-Protocol Label Switching (GMPLS) 646 Recovery", RFC 4872, May 2007. 648 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 649 "GMPLS Segment Recovery", RFC 4873, May 2007. 651 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 652 Engineering", RFC 5305, October 2008. 654 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 655 in Support of Generalized Multi-Protocol Label Switching 656 (GMPLS)", RFC 5307, October 2008. 658 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 659 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 660 March 2009. 662 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., 663 "Network Configuration Protocol (NETCONF)", RFC 6241, June 664 2011. 666 [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS 667 Switching Capability and Type Fields", RFC 7074, November 668 2013. 670 [RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for 671 Application-Based Network Operations", RFC7491, March 672 2015. 674 [RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli, 675 D. and Zhang, X., "Problem Statement and Architecture for 676 Information Exchange between Interconnected Traffic- 677 Engineered Networks", RFC7926, July 2016. 679 [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF 680 Protocol", RFC 8040, January 2017. 682 [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 683 Control of Traffic Engineered Networks", RFC 8453, August 684 2018. 686 11.2. Informative References 688 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 689 Switching (GMPLS) Signaling Functional Description", RFC 690 3471, January 2003. 692 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 693 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 694 May 2005. 696 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 697 in Support of Generalized Multi-Protocol Label Switching 698 (GMPLS)", RFC 4202, October 2005. 700 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 701 October 2005. 703 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 704 Ed., "Generalized Multi-Protocol Label witching (GMPLS) 705 Recovery Functional Specification", RFC 4426, March 2006. 707 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, J.P., Farrel, A., 708 "Label Switched Path Stitching with Generalized 709 Multiprotocol Label Switching Traffic Engineering (GMPLS 710 TE)", RFC 5150, February, 2008. 712 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 713 J. Drake, "Traffic Engineering Extensions to OSPF for 714 GMPLS Control of Evolving G.709 Optical Transport 715 Networks", RFC 7138, March 2014. 717 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 718 and K. Pithewan, "GMPLS Signaling Extensions for Control 719 of Evolving G.709 Optical Transport Networks", RFC 7139, 720 March 2014. 722 [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF 723 Enhancement for Signal and Network Element Compatibility 724 for Wavelength Switched Optical Networks", RFC 7688, 725 November 2015. 727 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 728 and H. Harai, "Signaling Extensions for Wavelength 729 Switched Optical Networks", RFC 7689, November 2015. 731 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 732 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 733 Support of Flexi-Grid Dense Wavelength Division 734 Multiplexing (DWDM) Networks", RFC 7792, March 2016. 736 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 737 Computation Element Communication Protocol (PCEP) 738 Extensions for Stateful PCE", RFC 8231, September 2017. 740 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 741 Extensions for PCE-initiated LSP Setup in a Stateful PCE 742 Model", RFC 8281, October 2017. 744 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 745 Ananthakrishnan, H., Liu, X., "A YANG Data Model for 746 Network Topologies", RFC 8345, March 2018. 748 [RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D. 749 Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi- 750 grid DWDM networks", RFC8363, February 2017. 752 [TE-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., 753 Gonzalez De Dios, O., "YANG Data Model for Traffic 754 Engineering (TE) Topologies", draft-ietf-teas-yang-te- 755 topo-19, work in progress. 757 [PAT-COMP]Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O., 758 Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang 759 model for requesting Path Computation", draft-ietf-teas- 760 yang-path-computation-04, work in progress. 762 [PCEP-LS] Dhody, D., Lee, Y., Ceccarelli, D., "PCEP Extensions for 763 Distribution of Link-State and TE Information", draft- 764 dhodylee-pce-pcep-ls, work in progress. 766 [TE-Tunnel] Saad, T. et al., "A YANG Data Model for Traffic 767 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 768 te, work in progress. 770 [sPCE-ID] Dugeon, O. et al., "PCEP Extension for Stateful Inter- 771 Domain Tunnels", draft-dugeon-pce-stateful-interdomain, 772 work in progress. 774 12. Authors' Addresses 776 Haomian Zheng 777 Huawei Technologies 778 F3 R&D Center, Huawei Industrial Base, 779 Bantian, Longgang District, 780 Shenzhen 518129 P.R.China 781 Email: zhenghaomian@huawei.com 783 Xianlong Luo 784 Huawei Technologies 785 F3 R&D Center, Huawei Industrial Base, 786 Bantian, Longgang District, 787 Shenzhen 518129 P.R.China 788 Email: luoxianlong@huawei.com 790 Yunbin Xu 791 CAICT 792 Email: xuyunbin@caict.ac.cn 794 Yang Zhao 795 China Mobile 796 Email: zhaoyangyjy@chinamobile.com 798 Sergio Belotti 799 Nokia 800 Email: sergio.belotti@nokia.com 802 Dieter Beller 803 Nokia 804 Email: Dieter.Beller@nokia.com 806 Yi Lin 807 Huawei Technologies 808 F3 R&D Center, Huawei Industrial Base, 809 Bantian, Longgang District, 810 Shenzhen 518129 P.R.China 811 Email: yi.lin@huawei.com