idnits 2.17.1 draft-ietf-teas-gmpls-controller-inter-work-03.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 (March 9, 2020) is 1509 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PAT-COMP' is mentioned on line 318, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-19 Summary: 0 errors (**), 0 flaws (~~), 3 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: September 9, 2020 March 9, 2020 14 Interworking of GMPLS Control and Centralized Controller System 16 draft-ietf-teas-gmpls-controller-inter-work-03 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 September 9, 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 .. 5 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.3.1. Multi-layer Path Computation ....................... 13 100 7.3.2. Cross-layer Path Creation .......................... 15 101 7.3.3. Link Discovery ..................................... 16 102 7.4. Recovery ................................................ 16 103 7.5. Controller Reliability .................................. 17 104 8. Manageability Considerations ................................. 17 105 9. Security Considerations ...................................... 17 106 10. IANA Considerations.......................................... 17 107 11. References .................................................. 17 108 11.1. Normative References ................................... 17 109 11.2. Informative References ................................. 19 110 12. Authors' Addresses .......................................... 21 112 1. Introduction 114 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 115 MPLS to support different classes of interfaces and switching 116 capabilities such as Time-Division Multiplex Capable (TDM), Lambda 117 Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network 118 element (NE) running a GMPLS control plane collects network 119 information from other NEs and supports service provisioning through 120 signaling in a distributed manner. More generic description for 121 Traffic-engineering networking information exchange can be found in 122 [RFC7926]. 124 On the other hand, Software-Defined Networking (SDN) technologies 125 have been introduced to control the transport network in a 126 centralized manner. Central controllers can collect network 127 information from each node and provision services to corresponding 128 nodes. One of the examples is the Abstraction and Control of Traffic 129 Engineered Networks (ACTN) [RFC8453], which defines a hierarchical 130 architecture with Provisioning Network Controller (PNC), Multi- 131 domain Service Coordinator (MDSC) and Customer Network Controller 132 (CNC) as central controllers for different network abstraction 133 levels. A Path Computation Element (PCE) based approach has been 134 proposed as Application-Based Network Operations (ABNO) in 135 [RFC7491]. 137 In such centralized controller architectures, GMPLS can be applied 138 for the NE-level control. A central controller may support GMPLS 139 enabled domains and may interact with a GMPLS enabled domain where 140 the GMPLS control plane does the service provisioning from ingress 141 to egress. In this case the centralized controller sends the request 142 to the ingress node and does not have to configure all NEs along the 143 path through the domain from ingress to egress thus leveraging the 144 GMPLS control plane. This document describes how GMPLS control 145 interworks with centralized controller system in transport network. 147 2. Overview 149 In this section, overviews of GMPLS control plane and centralized 150 controller system are discussed as well as the interactions between 151 the GMPLS control plane and centralized controllers. 153 2.1. Overview of GMPLS Control Plane 155 GMPLS separates the control plane and the data plane to support 156 time-division, wavelength, and spatial switching, which are 157 significant in transport networks. For the NE level control in 158 GMPLS, each node runs a GMPLS control plane instance. 159 Functionalities such as service provisioning, protection, and 160 restoration can be performed via GMPLS communication among multiple 161 NEs. At the same time, the controller can also collect node and 162 link resources in the network to construct the network topology and 163 compute routing paths for serving service requests. 165 Several protocols have been designed for GMPLS control [RFC3945] 166 including link management [RFC4204], signaling [RFC3471], and 167 routing [RFC4202] protocols. The controllers applying these 168 protocols communicate with each other to exchange resource 169 information and establish Label Switched Paths (LSPs). In this way, 170 controllers in different nodes in the network have the same view of 171 the network topology and provision services based on local policies. 173 2.2. Overview of Centralized Controller System 175 With the development of SDN technologies, a centralized controller 176 architecture has been introduced to transport networks. One example 177 architecture can be found in ACTN [RFC8453]. In such systems, a 178 controller is aware of the network topology and is responsible for 179 provisioning incoming service requests. 181 Multiple hierarchies of controllers are designed at different levels 182 implementing different functions. This kind of architecture enables 183 multi-vendor, multi-domain, and multi-technology control. For 184 example, a higher-level controller coordinates several lower-level 185 controllers controlling different domains, for topology collection 186 and service provisioning. Vendor-specific features can be abstracted 187 between controllers, and standard API (e.g., generated from 188 RESTconf/YANG) is used. 190 2.3. GMPLS Control Interwork with Centralized Controller System 192 Besides the GMPLS and the interactions among the controller 193 hierarchies, it is also necessary for the controllers to communicate 194 with the network elements. Within each domain, GMPLS control can be 195 applied to each NE. The bottom-level central controller can act as a 196 NE to collect network information and initiate LSP. Figure 1 shows 197 an example of GMPLS interworking with centralized controllers (ACTN 198 terminologies are used in the figure). 200 +--------------------+ 201 | Orchestrator | 202 +--------------------+ 203 ^ ^ ^ 204 | | | 205 +-------------+ | +------------+ 206 | | RESTConf/YANG models | 207 V V V 208 +----------+ +----------+ +----------+ 209 |Controller| |Controller| |Controller| 210 +----------+ +----------+ +----------+ 211 ^ ^ ^ ^ ^ 212 | | | | | 213 Netconf| |PCEP Netconf| |PCEP | IF* 214 /YANG | | /YANG | | | 215 V V V V V 216 .------------. Inter- .-----------. Inter- .-----------. 217 / \ domain / \ domain / \ 218 | | link | LMP | link | LMP | 219 | |======| OSPF-TE |=======| OSPF-TE | 220 | | | RSVP-TE | | RSVP-TE | 221 \ / \ / \ / 222 `-----------` `------------` `----------` 223 non-GMPLS domain 1 GMPLS domain 2 GMPLS domain 3 225 Figure 1: Example of GMPLS/non-GMPLS interworks with Controllers 227 Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS 228 domain. This system supports the interworking among non-GMPLS 229 domain, GMPLS domain and the controller hierarchies. For domain 1, 230 the network element were not enabled with GMPLS so the control can 231 be purely from the controller, via Netconf/YANG and/or PCEP. For 232 domain 2 and 3, each domain has the GMPLS control plane enabled at 233 the physical network level. The PNC can exploit GMPLS capability 234 implemented in the domain to listen to the IGP routing protocol 235 messages (OSPF LSAs for example) that the GMPLS control plane 236 instances are disseminating into the network and thus learn the 237 network topology. For path computation in the domain with PNC 238 implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP 239 to ask the PNC for a path and get replies. The MDSC communicates 240 with PNCs using for example REST/RESTConf based on YANG data models. 241 As a PNC has learned its domain topology, it can report the topology 242 to the MDSC. When a service arrives, the MDSC computes the path and 243 coordinates PNCs to establish the corresponding LSP segment. 245 Alternatively, the NETCONF protocol can be used to retrieve topology 246 information utilizing the e.g. [TE-topo] Yang model and the 247 technology-specific YANG model augmentations required for the 248 specific network technology. The PNC can retrieve topology 249 information from any NE (the GMPLS control plane instance of each NE 250 in the domain has the same topological view), construct the topology 251 of the domain and export an abstracted view to the MDSC. Based on 252 the topology retrieved from multiple PNCs, the MDSC can create 253 topology graph of the multi-domain network, and can use it for path 254 computation. To setup a service, the MDSC can exploit e.g. [TE- 255 Tunnel] Yang model together with the technology-specific YANG model 256 augmentations. 258 3. Discovery Options 260 In GMPLS control, the link connectivity need to be verified between 261 each pair of nodes. In this way, link resources, which are 262 fundamental resources in the network, are discovered by both ends of 263 the link. 265 3.1. LMP 267 Link management protocol (LMP) [RFC4204] runs between a pair of 268 nodes and is used to manage TE links. In addition to the setup and 269 maintenance of control channels, LMP can be used to verify the data 270 link connectivity and correlate the link property. 272 4. Routing Options 274 In GMPLS control, link state information is flooded within the 275 network as defined in [RFC4202]. Each node in the network can build 276 the network topology according to the flooded link state 277 information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE 278 [RFC5307] have been extended to support different interfaces in 279 GMPLS. 281 In centralized controller system, central controller can be placed 282 at the GMPLS network and passively receive the information flooded 283 in the network. In this way, the central controller can construct 284 and update the network topology. 286 4.1. OSPF-TE 288 OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions 289 have been defined in [RFC4203] to enable the capability of link 290 state information for GMPLS network. Based on this work, OSPF 291 protocol has been extended to support technology-specific routing. 292 The routing protocol for OTN, WSON and optical flexi-grid network 293 are defined in [RFC7138], [RFC7688] and [RFC8363], respectively. 295 4.2. ISIS-TE 297 ISIS-TE is introduced for TE networks in [RFC5305] and is extended 298 to support GMPLS routing functions [RFC5307], and has been updated 299 to [RFC7074] to support the latest GMPLS switching capability and 300 Types fields. 302 4.3. Netconf/RESTconf 304 Netconf [RFC6241] and RESTconf [RFC8040] protocols are originally 305 used for network configuration. Besides, these protocols can also be 306 used for topology retrieval by using topology-related YANG models, 307 such as [RFC8345] and [TE-topo]. These protocols provide a powerful 308 mechanism for notification that permits to notify the client about 309 topology changes. 311 5. Path Computation 313 Once a controller learns the network topology, it can utilize the 314 available resources to serve service requests by performing path 315 computation. Due to abstraction, the controllers may not have 316 sufficient information to compute the optimal path. In this case, 317 the controller can interact with other controllers by sending Yang 318 Path Computation requests [PAT-COMP] to compute a set of potential 319 optimal paths and then, based on its own constraints, policy and 320 specific knowledge (e.g. cost of access link) can choose the more 321 feasible path for service e2e path setup. 323 Path computation is one of the key objectives in various types of 324 controllers. In the given architecture, it is possible for different 325 components that have the capability to compute the path. 327 5.1. Constraint-based Path Computing in GMPLS Control 329 In GMPLS control, a routing path is computed by the ingress node 330 [RFC3473] and is based on the ingress node TED. Constraint-based 331 path computation is performed according to the local policy of the 332 ingress node. 334 5.2. Path Computation Element (PCE) 336 PCE has been introduced in [RFC4655] as a functional component that 337 provides services to compute path in a network. In [RFC5440], the 338 path computation is accomplished by using the Traffic Engineering 339 Database (TED), which maintains the link resources in the network. 340 The emergence of PCE efficiently improve the quality of network 341 planning and offline computation, but there is a risk that the 342 computed path may be infeasible if there is a diversity requirement, 343 because stateless PCE has no knowledge about the former computed 344 paths. 346 To address this issue, stateful PCE has been proposed in [RFC8231]. 347 Besides the TED, an additional LSP Database (LSP-DB) is introduced 348 to archive each LSP computed by the PCE. In this way, PCE can easily 349 figure out the relationship between the computing path and former 350 computed paths. In this approach, PCE provides computed paths to 351 PCC, and then PCC decides which path is deployed and when to be 352 established. 354 In PCE Initiation [RFC8281], PCE is allowed to trigger the PCC to 355 setup, maintenance, and teardown of the PCE-initiated LSP under the 356 stateful PCE model. This would allow a dynamic network that is 357 centrally controlled and deployed. 359 In centralized controller system, the PCE can be implemented in a 360 central controller, and the central controller performs path 361 computation according to its local policies. On the other hand, the 362 PCE can also be placed outside of the central controller. In this 363 case, the central controller acts as a PCC to request path 364 computation to the PCE through PCEP. One of the reference 365 architecture can be found at [RFC7491]. 367 6. Signaling Options 369 Signaling mechanisms are used to setup LSPs in GMPLS control. 370 Messages are sent hop by hop between the ingress node and the egress 371 node of the LSP to allocate labels. Once the labels are allocated 372 along the path, the LSP setup is accomplished. Signaling protocols 373 such as RSVP-TE [RFC3473] have been extended to support different 374 interfaces in GMPLS. 376 6.1. RSVP-TE 378 RSVP-TE is introduced in [RFC3209] and extended to support GMPLS 379 signaling in [RFC3473]. Several label formats are defined for a 380 generalized label request, a generalized label, suggested label and 381 label sets. Based on [RFC3473], RSVP-TE has been extended to support 382 technology-specific signaling. The RSVP-TE extensions for OTN, WSON, 383 optical flexi-grid network are defined in [RFC7139], [RFC7689], and 384 [RFC7792], respectively. 386 7. Interworking Scenarios 388 7.1. Topology Collection & Synchronization 390 Topology information is necessary on both network elements and 391 controllers. The topology on network element is usually raw 392 information, while the topology on the controller can be either raw 393 or abstracted. Three different abstraction methods have been 394 described in [RFC8453], and different controllers can select the 395 corresponding method depending on application. 397 When there are changes in the network topology, the impacted network 398 element(s) need to report changes to all the other network elements, 399 together with the controller, to sync up the topology information. 400 The inter-NE synchronization can be achieved via protocols mentioned 401 in section 3 and 4. The topology synchronization between NEs and 402 controllers can either be achieved by routing protocols OSPF- 403 TE/PCEP-LS in [PCEP-LS] or Netconf protocol notifications with YANG 404 model. 406 7.2. Multi-domain Service Provisioning 408 Based on the topology information on controllers and network 409 elements, service provisioning can be deployed. Plenty of methods 410 have been specified for single domain service provisioning, such as 411 using PCEP and RSVP-TE. 413 Multi-domain service provisioning would request coordination among 414 the controller hierarchies. Given the service request, the end-to- 415 end delivery procedure may include interactions at any level (i.e. 416 interface) in the hierachy of the controllers (e.g. MPI and SBI for 417 ACTN). The computation for a cross-domain path is usually completed 418 by controllers who have a global view of the topologies. Then the 419 configuration is decomposed into lower layer controllers, to 420 configure the network elements to set up the path. 422 A combination of the centralized and distributed protocols may be 423 necessary for the interaction between network elements and 424 controller. Several methods can be used to create the inter-domain 425 path: 427 1) With end-to-end RSVP-TE session: 429 In this method, the SDN controller of the source domain triggers the 430 source node to create the end-to-end RSVP-TE session, and the 431 assignment and distribution of the labels on the inter-domain links 432 are done by the boarder nodes of each domain, using RSVP-TE 433 protocol. Therefore, this method requires the interworking of RSVP- 434 TE protocols between different domains. 436 There are two possible methods: 438 1.1) One single end-to-end RSVP-TE session 440 In this method, an end-to-end RSVP-TE session from the source NE to 441 the destination NE will be used to create the inter-domain path. A 442 typical example would be the PCE Initiation scenario, in which a PCE 443 message (PCInitiate) is sent from the controller to the first-end 444 node, and then trigger a RSVP procedure along the path. Similarly, 445 the interaction between the controller and the ingress node of a 446 domain can be achieved by Netconf protocol with corresponding YANG 447 models, and then completed by running RSVP among the network 448 elements. 450 1.2) LSP Stitching 452 The LSP stitching method defined in [RFC5150] can also be used to 453 create the end-to-end LSP. I.e., when the source node receives an 454 end-to-end path creation request (e.g., using PCEP or Netconf 455 protocol), the source node starts an end-to-end RSVP-TE session 456 along the end points of each LSP segment (refers to S-LSP in 457 [RFC5150]) of each domain, to assign the labels on the inter-domain 458 links between each pair of neighbor S-LSPs, and stitch the end-to- 459 end LSP to each S-LSP. See Figure 2 as an example. Note that the S- 460 LSP in each domain can be either created by each domain controller 461 in advance, or created dynamically triggered by the end-to-end RSVP- 462 TE session. 464 +-----------------+ +----------------+ +-----------------+ 465 |Client | | | | Client| 466 |Signal Domain 1| | Domain 2 | |Domain 3 Signal| 467 | | | | | | | | 468 |+-+-+ | | | | +-+-+| 469 || | | +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ | | || 470 || | | | | | || || | | | | || || | | | | | || 471 || ******************************************************** || 472 || | | | | || || | | | | || || | | | | || 473 |+---+ +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ +---+| 474 +-----------------+ +----------------+ +-----------------+ 475 | . . . . . . | 476 | .<-S-LSP 1->. .<- S-LSP 2 -->. .<-S-LSP 3->. | 477 | . . . . | 478 |-------------->.---->.------------->.---->.-------------->| 479 |<--------------.<----.<-------------.<----.<--------------| 480 | End-to-end RSVP-TE session for LSP stitching | 482 Figure 2: LSP stitching 483 2) Without end-to-end RSVP-TE session: 485 In this method, each SDN controller is responsible to create the 486 path segment within its domain. The boarder node does not need to 487 communicate with other boarder nodes in other domains for the 488 distribution of labels on inter-domain links, so end-to-end RSVP-TE 489 session through multiple domains is not required, and the 490 interworking of RSVP-TE protocol between different domains is not 491 needed. 493 Note that path segments in the source domain and the destination 494 domain are "asymmetrical" segments, because the configuration of 495 client signal mapping into server layer tunnel is needed at only one 496 end of the segment, while configuration of server layer cross- 497 connect is needed at the other end of the segment. For example, the 498 path segment 1 and 3 in Figure 3 are asymmetrical segments, because 499 one end of the segment requires mapping GE into ODU0, while the 500 other end of the segment requires setting up ODU0 cross-connect. 502 +-----------------+ +----------------+ +-----------------+ 503 |Client | | | | Client| 504 |Signal Domain 1| | Domain 2 | |Domain 3 Signal| 505 |(GE) | | | | (GE) | 506 | | ODU0 tunnel| | | | | | 507 |+-+-+ ^ | | | | +-+-+| 508 || | | +--+ |+--+| |+--+ +--+ +--+| |+--+ +--+ | | || 509 || | | | | || || || | | | | || || | | | | | || 510 || ******************************************************** || 511 || | | | | || . || | | | | || . || | | | | || 512 |+---+ +--+ +--+| . |+--+ +--+ +--+| . |+--+ +--+ +---+| 513 +-----------------+ . +----------------+ . +-----------------+ 514 . . . . 515 .<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->. 516 . . . . 518 Figure 3: Example of asymmetrical path segment 520 The PCEP / GMPLS protocols should support creation of such 521 asymmetrical segment. 523 Note also that mechanisms to assign the labels in the inter-domain 524 links are also needed to be considered. There are two possible 525 methods: 527 2.1) Inter-domain labels assigned by NEs: 529 The concept of Stitching Label that allows stitching local path 530 segments was introduced in [RFC5150] and [sPCE-ID], in order to form 531 the inter-domain path crossing several different domains. It also 532 describes the BRPC and H-PCE PCInitiate procedure, i.e., the ingress 533 boarder node of each downstream domain assigns the stitching label 534 for the inter-domain link between the downstream domain and its 535 upstream neighbor domain, and this stitching label will be passed to 536 the upstream neighbor domain by PCE protocol, which will be used for 537 the path segment creation in the upstream neighbor domain. 539 2.2) Inter-domain labels assigned by SDN controller: 541 If the resource of inter-domain links are managed by the multi- 542 domain SDN controller, each single-domain SDN controller can provide 543 to the multi-domain SDN controller the list of available labels 544 (e.g. timeslots if OTN is the scenario) using IETF Topology model 545 and related technology specific extension. Once that multi-domain 546 SDN controller has computed e2e path RSVP-TE or PCEP can be used in 547 the different domains to setup related segment tunnel consisting 548 with label inter-domain information, e.g. for PCEP the label ERO can 549 be included in the PCInitiate message to indicate the inter-domain 550 labels, so that each boarder node of each domain can configure the 551 correct cross-connect within itself. 553 7.3. Multi-layer Service Provisioning 555 GMPLS can interwork with centralized controller system in multi- 556 layer networks. 558 +--------------+ 559 | Multi-layer | 560 |SDN Controller| 561 +-----+--+-----+ 562 | | Higher-layer Network 563 | | .--------------------. 564 | | +--------------+ / \ 565 | | | Higher-layer | | +--+ Link +--+ | 566 | +-->|SDN Controller+----->| | |**********| | | 567 | +--------------+ | +--+ +--+ | 568 | \ . . / 569 | `--.------------.---` 570 | . . 571 | .---.------------.---. 572 | +--------------+ / . . \ 573 | | Lower-layer | | +--+ +--+ +--+ | 574 +----->|SDN Controller+----->| | ============== | | 575 +--------------+ | +--+ +--+ +--+ | 576 \ H-LSP / 577 `-------------------` 578 Lower-layer Network 580 Figure 4: Example of GMPLS-SDN interworking in multi-layer network 581 An example with two layers of network is shown in Figure 4. In this 582 example, the GMPLS control plane is enabled in each layer network, 583 and interworks with the SDN controller of its domain (higher-layer 584 SDN controller and lower-layer SDN controller, respectively). The 585 multi-layer SDN controller, which acts as the Orchestrator, is used 586 to coordinate the control of the multi-layer network. 588 7.3.1. Multi-layer Path Computation 590 [RFC5623] describes three inter-layer path computation models and 591 four inter-layer path control models: 593 - 3 Path computation: 595 o Single PCE path computation model 597 o Multiple PCE path computation with inter-PCE communication 598 model 600 o Multiple PCE path computation without inter-PCE communication 601 model 603 - 4 Path control: 605 o PCE-VNTM cooperation model 607 o Higher-layer signaling trigger model 609 o NMS-VNTM cooperation model (integrated flavor) 611 o NMS-VNTM cooperation model (separate flavor) 613 Section 4.2.4 of [RFC5623] also provides all the possible 614 combinations of inter-layer path computation and inter-layer path 615 control models. 617 To apply [RFC5623] in multi-layer network with GMPLS-SDN 618 interworking, the higher-layer SDN controller and the lower-layer 619 SDN controller can act as the PCE Hi and PCE Lo respectively, and 620 typically, the multi-layer SDN controller can act as a VNTM because 621 it has the abstracted view of both the higher-layer and lower-layer 622 networks. 624 The table below shows all possible combinations of path computation 625 and path control models in multi-layer network with GMPLS-SDN 626 interworking: 628 --------------------------------------------------------- 629 | Path computation |Single PCE | Multiple | Multiple | 630 | \ | (Not | PCE with | PCE w/o | 631 | Path control |applicable)| inter-PCE | inter-PCE | 632 |---------------------+-----------+-----------+-----------| 633 | PCE-VNTM | ...... | | | 634 | cooperation | . -- . | Yes | Yes | 635 | | . . | | | 636 |---------------------+--.----.---+-----------+-----------| 637 | Higher-layer | . . | | | 638 | signaling trigger | . -- . | Yes | Yes | 639 | | . . | | | 640 |---------------------+--.----.---+-----------+-----------| 641 | NMS-VNTM | . . | .........|....... | 642 | cooperation | . -- . | .Yes | No . | 643 | (integrated flavor) | . . | . | . | 644 |---------------------+--.----.---+--.--------+------.----| 645 | NMS-VNTM | . . | . | . | 646 | cooperation | . -- . | .No | Yes. | 647 | (separate flavor) | ...... | .........|....... | 648 ---------------------+----|------+--------|--+----------- 649 V V 650 Not applicable because Typical models to be used 651 there are multiple PCEs 653 Note that: 655 - Since there is one PCE in each layer network, the path computation 656 model "Single PCE path computation" is not applicable. 658 - For the other two path computation models "Multiple PCE with 659 inter-PCE" and "Multiple PCE w/o inter-PCE", the possible 660 combinations are the same as defined in [RFC5623]. More 661 specifically: 663 o The path control models "NMS-VNTM cooperation (integrated 664 flavor)" and "NMS-VNTM cooperation (separate flavor)" are the 665 typical models to be used in multi-layer network with GMPLS-SDN 666 interworking. This is because in these two models, the path 667 computation is triggered by the NMS or VNTM. And in SDN 668 centralized control system, the path computation requests are 669 typically from the multi-layer SDN controller (acts as VNTM). 671 o For the other two path control models "PCE-VNTM cooperation" 672 and "Higher-layer signaling trigger", the path computation is 673 triggered by the NEs, i.e., NE performs PCC functions. These 674 two models are still possible to be used, although they are not 675 the main methods. 677 7.3.2. Cross-layer Path Creation 679 In a multi-layer network, a lower-layer LSP in the lower-layer 680 network can be created, which will construct a new link in the 681 higher-layer network. Such lower-layer LSP is called Hierarchical 682 LSP, or H-LSP for short, see [RFC6107]. 684 The new link constructed by the H-LSP then can be used by the 685 higher-layer network to create new LSPs. 687 As described in [RFC5212], two methods are introduced to create the 688 H-LSP: the static (pre-provisioned) method and the dynamic 689 (triggered) method. 691 1) Static (pre-provisioned) method 693 In this method, the H-LSP in the lower layer network is created in 694 advance. After that, the higher layer network can create LSPs using 695 the resource of the link constructed by the H-LSP. 697 The multi-layer SDN controller is responsible to decide the creation 698 of H-LSP in the lower layer network if it acts as a VNTM. It then 699 requests the lower-layer SDN controller to create the H-LSP via, for 700 example, MPI interface under the ACTN architecture. See Section 701 3.3.2 of [TE-Tunnel]. 703 The lower-layer SDN controller can trigger the GMPLS control plane 704 to create the H-LSP. As a typical example, the PCInitiate message 705 can be used for the communication between the lower-layer SDN 706 controller and the source node of the H-LSP. 708 And the source node of the H-LSP can trigger the RSVP-TE signaling 709 procedure to create the H-LSP, as described in [RFC6107]. 711 2) Dynamic (triggered) method 713 In this method, the signaling of LSP creation in the higher layer 714 network will trigger the creation of H-LSP in the lower layer 715 network dynamically, if it is necessary. 717 In this case, after the cross-layer path is computed, the multi- 718 layer SDN controller requests the higher-layer SDN controller for 719 the cross-layer LSP creation. As a typical example, the MPI 720 interface under the ACTN architecture could be used. 722 The higher-layer SDN controller can trigger the GMPLS control plane 723 to create the LSP in the higher-layer network. As a typical example, 724 the PCInitiate message can be used for the communication between the 725 higher-layer SDN controller and the source node of the Higher-layer 726 LSP, as described in Section 4.3 of [RFC8282]. At least two sets of 727 ERO information should be included to indicate the routes of higher- 728 layer LSP and lower-layer H-LSP. 730 The source node of the Higher-layer LSP follows the procedure 731 defined in Section 4 of [RFC6001], to trigger the GMPLS control 732 plane in both higher-layer network and lower-layer network to create 733 the higher-layer LSP and the lower-layer H-LSP. 735 On success, the source node of the H-LSP should report the 736 information of the H-LSP to the lower-layer SDN controller via, for 737 example, PCRpt message. 739 7.3.3. Link Discovery 741 If the higher-layer network and the lower-layer network are under 742 the same GMPLS control plane instance, the H-LSP can be an FA-LSP. 743 Then the information of the link constructed by this FA-LSP, called 744 FA, can be advertised in the routing instance, so that the higher- 745 layer SDN controller can be aware of this new FA. [RFC4206] and the 746 following updates to it (including [RFC6001] and [RFC6107]) describe 747 the detail extensions to support advertisement of an FA. 749 If the higher-layer network and the lower-layer network are under 750 separated GMPLS control plane instances, after an H-LSP is created 751 in the lower-layer network, the link discovery procedure defined in 752 LMP protocol ([RFC4204]) will be triggered in the higher-layer 753 network to discover the information of the link constructed by the 754 H-LSP. The information of this new link will be advertised to the 755 higher-layer SDN controller. 757 7.4. Recovery 759 The GMPLS recovery functions are described in [RFC4426]. Two models, 760 span protection and end-to-end protection and restoration, are 761 discussed with different protection schemes and message exchange 762 requirements. Related RSVP-TE extensions to support end-to-end 763 recovery is described in [RFC4872]. The extensions in [RFC4872] 764 include protection, restoration, preemption, and rerouting 765 mechanisms for an end-to-end LSP. Besides end-to-end recovery, a 766 GMPLS segment recovery mechanism is defined in [RFC4873]. By 767 introducing secondary record route objects, LSP segment can be 768 switched to another path like fast reroute [RFC4090]. 770 For the recovery with controllers, timely interaction between 771 controller and network elements are required. Usually the re-routing 772 can be decomposed into path computation and delivery, the controller 773 can take some advantage in the path computation due to the global 774 topology view. And the delivery can be achieved by the procedure 775 described in section 7.2. 777 7.5. Controller Reliability 779 Given the important role in the network, the reliability of 780 controller is critical. Once a controller is shut down, the network 781 should operate as well. It can be either achieved by controller back 782 up or functionality back up. There are several of controller backup 783 or federation mechanisms in the literature. It is also more reliable 784 to have some function back up in the network element, to guarantee 785 the performance in the network. 787 8. Manageability Considerations 789 Each entity in the network, including both controllers and network 790 elements, should be managed properly as it will interact with other 791 entities. The manageability considerations in controller hierarchies 792 and network elements still apply respectively. For the protocols 793 applied in the network, manageability is also requested. 795 The responsibility of each entity should be clarified. The control 796 of function and policy among different controllers should be 797 consistent via proper negotiation process. 799 9. Security Considerations 801 This document provides the interwork between the GMPLS and 802 controller hierarchies. The security requirements in both system 803 still applies respectively. Protocols referenced in this document 804 also have various security considerations, which is also expected to 805 be satisfied. 807 Other considerations on the interface between the controller and the 808 network element are also important. Such security includes the 809 functions to authenticate and authorize the control access to the 810 controller from multiple network elements. Security mechanisms on 811 the controller are also required to safeguard the underlying network 812 elements against attacks on the control plane and/or unauthorized 813 usage of data transport resources. 815 10. IANA Considerations 817 This document requires no IANA actions. 819 11. References 821 11.1. Normative References 823 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 824 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 825 Tunnels", RFC 3209, December 2001. 827 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 828 Switching (GMPLS) Signaling Resource ReserVation Protocol- 829 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 830 January 2003. 832 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 833 (TE) Extensions to OSPF Version 2", RFC 3630, September 834 2003. 836 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 837 Switching (GMPLS) Architecture", RFC 3945, October 2004. 839 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 840 Support of Generalized Multi-Protocol Label Switching 841 (GMPLS)", RFC 4203, October 2005. 843 [RFC4206] Kompella, K. and Rekhter Y., "Label Switched Paths (LSP) 844 Hierarchy with Generalized Multi-Protocol Label Switching 845 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 847 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 848 Element (PCE)-Based Architecture", RFC 4655, August 2006. 850 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 851 Ed., "RSVP-TE Extensions in Support of End-to-End 852 Generalized Multi-Protocol Label Switching (GMPLS) 853 Recovery", RFC 4872, May 2007. 855 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 856 "GMPLS Segment Recovery", RFC 4873, May 2007. 858 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 859 Engineering", RFC 5305, October 2008. 861 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 862 in Support of Generalized Multi-Protocol Label Switching 863 (GMPLS)", RFC 5307, October 2008. 865 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 866 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 867 March 2009. 869 [RFC6001] Papadimitriou D., Vigoureux M., Shiomoto K., Brungard D. 870 and Le Roux JL., "Generalized MPLS (GMPLS) Protocol 871 Extensions for Multi-Layer and Multi-Region Networks 872 (MLN/MRN)", RFC 6001, October 2010. 874 [RFC6107] Shiomoto K. and Farrel A., "Procedures for Dynamically 875 Signaled Hierarchical Label Switched Paths", RFC 6107, 876 February 2011. 878 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., 879 "Network Configuration Protocol (NETCONF)", RFC 6241, June 880 2011. 882 [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS 883 Switching Capability and Type Fields", RFC 7074, November 884 2013. 886 [RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for 887 Application-Based Network Operations", RFC7491, March 888 2015. 890 [RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli, 891 D. and Zhang, X., "Problem Statement and Architecture for 892 Information Exchange between Interconnected Traffic- 893 Engineered Networks", RFC7926, July 2016. 895 [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF 896 Protocol", RFC 8040, January 2017. 898 [RFC8282] Oki E., Takeda T., Farrel A. and Zhang F., "Extensions to 899 the Path Computation Element Communication Protocol (PCEP) 900 for Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 901 8282, December 2017. 903 [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 904 Control of Traffic Engineered Networks", RFC 8453, August 905 2018. 907 11.2. Informative References 909 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 910 Switching (GMPLS) Signaling Functional Description", RFC 911 3471, January 2003. 913 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 914 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 915 May 2005. 917 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 918 in Support of Generalized Multi-Protocol Label Switching 919 (GMPLS)", RFC 4202, October 2005. 921 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 922 October 2005. 924 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 925 Ed., "Generalized Multi-Protocol Label witching (GMPLS) 926 Recovery Functional Specification", RFC 4426, March 2006. 928 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, J.P., Farrel, A., 929 "Label Switched Path Stitching with Generalized 930 Multiprotocol Label Switching Traffic Engineering (GMPLS 931 TE)", RFC 5150, February, 2008. 933 [RFC5212] Shiomoto K., Papadimitriou D., Le Roux JL., Vigoureux M. 934 and Brungard D., "Requirements for GMPLS-Based Multi- 935 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 936 2008. 938 [RFC5623] Oki E., Takeda T., Le Roux JL. and Farrel A., "Framework 939 for PCE-Based Inter-Layer MPLS and GMPLS Traffic 940 Engineering", RFC 5623, September 2009. 942 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 943 J. Drake, "Traffic Engineering Extensions to OSPF for 944 GMPLS Control of Evolving G.709 Optical Transport 945 Networks", RFC 7138, March 2014. 947 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 948 and K. Pithewan, "GMPLS Signaling Extensions for Control 949 of Evolving G.709 Optical Transport Networks", RFC 7139, 950 March 2014. 952 [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF 953 Enhancement for Signal and Network Element Compatibility 954 for Wavelength Switched Optical Networks", RFC 7688, 955 November 2015. 957 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 958 and H. Harai, "Signaling Extensions for Wavelength 959 Switched Optical Networks", RFC 7689, November 2015. 961 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 962 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 963 Support of Flexi-Grid Dense Wavelength Division 964 Multiplexing (DWDM) Networks", RFC 7792, March 2016. 966 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 967 Computation Element Communication Protocol (PCEP) 968 Extensions for Stateful PCE", RFC 8231, September 2017. 970 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 971 Extensions for PCE-initiated LSP Setup in a Stateful PCE 972 Model", RFC 8281, October 2017. 974 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 975 Ananthakrishnan, H., Liu, X., "A YANG Data Model for 976 Network Topologies", RFC 8345, March 2018. 978 [RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D. 979 Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi- 980 grid DWDM networks", RFC8363, February 2017. 982 [TE-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., 983 Gonzalez De Dios, O., "YANG Data Model for Traffic 984 Engineering (TE) Topologies", draft-ietf-teas-yang-te- 985 topo-19, work in progress. 987 [PAT-COMP]Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O., 988 Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang 989 model for requesting Path Computation", draft-ietf-teas- 990 yang-path-computation-04, work in progress. 992 [PCEP-LS] Dhody, D., Lee, Y., Ceccarelli, D., "PCEP Extensions for 993 Distribution of Link-State and TE Information", draft- 994 dhodylee-pce-pcep-ls, work in progress. 996 [TE-Tunnel] Saad, T. et al., "A YANG Data Model for Traffic 997 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 998 te, work in progress. 1000 [sPCE-ID] Dugeon, O. et al., "PCEP Extension for Stateful Inter- 1001 Domain Tunnels", draft-dugeon-pce-stateful-interdomain, 1002 work in progress. 1004 12. Authors' Addresses 1006 Haomian Zheng 1007 Huawei Technologies 1008 H1, Huawei Xiliu Beipo Village, Songshan Lake 1009 Dongguan 1010 Guangdong, 523808 China 1011 Email: zhenghaomian@huawei.com 1013 Xianlong Luo 1014 Huawei Technologies 1015 G1, Huawei Xiliu Beipo Village, Songshan Lake 1016 Dongguan 1017 Guangdong, 523808 China 1018 Email: luoxianlong@huawei.com 1020 Yunbin Xu 1021 CAICT 1022 Email: xuyunbin@caict.ac.cn 1023 Yang Zhao 1024 China Mobile 1025 Email: zhaoyangyjy@chinamobile.com 1027 Sergio Belotti 1028 Nokia 1029 Email: sergio.belotti@nokia.com 1031 Dieter Beller 1032 Nokia 1033 Email: Dieter.Beller@nokia.com 1035 Yi Lin 1036 Huawei Technologies 1037 H1, Huawei Xiliu Beipo Village, Songshan Lake 1038 Dongguan 1039 Guangdong, 523808 China 1040 Email: yi.lin@huawei.com