idnits 2.17.1 draft-ietf-teas-gmpls-controller-inter-work-05.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 (February 21, 2021) is 1152 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: August 25, 2021 February 21, 2021 14 Interworking of GMPLS Control and Centralized Controller System 16 draft-ietf-teas-gmpls-controller-inter-work-05 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 August 25, 2021. 60 Copyright Notice 62 Copyright (c) 2021 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 96 7. Interworking Scenarios ........................................ 9 97 7.1. Topology Collection & Synchronization .................... 9 98 7.2. Multi-domain Service Provisioning ........................ 9 99 7.3. Multi-layer Service Provisioning ........................ 12 100 7.3.1. Multi-layer Path Computation ....................... 13 101 7.3.2. Cross-layer Path Creation .......................... 15 102 7.3.3. Link Discovery ..................................... 16 103 7.4. Recovery ................................................ 16 104 7.4.1. Span Protection .................................... 16 105 7.4.2. LSP Protection .................................... 17 106 7.4.3. LSP Restoration .................................... 17 107 7.5. Controller Reliability .................................. 18 108 8. Manageability Considerations ................................. 18 109 9. Security Considerations ...................................... 18 110 10. IANA Considerations.......................................... 19 111 11. References .................................................. 19 112 11.1. Normative References ................................... 19 113 11.2. Informative References ................................. 21 114 12. Authors' Addresses .......................................... 23 116 1. Introduction 118 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 119 MPLS to support different classes of interfaces and switching 120 capabilities such as Time-Division Multiplex Capable (TDM), Lambda 121 Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network 122 element (NE) running a GMPLS control plane collects network 123 information from other NEs and supports service provisioning through 124 signaling in a distributed manner. More generic description for 125 Traffic-engineering networking information exchange can be found in 126 [RFC7926]. 128 On the other hand, Software-Defined Networking (SDN) technologies 129 have been introduced to control the transport network in a 130 centralized manner. Central controllers can collect network 131 information from each node and provision services to corresponding 132 nodes. One of the examples is the Abstraction and Control of Traffic 133 Engineered Networks (ACTN) [RFC8453], which defines a hierarchical 134 architecture with Provisioning Network Controller (PNC), Multi- 135 domain Service Coordinator (MDSC) and Customer Network Controller 136 (CNC) as central controllers for different network abstraction 137 levels. A Path Computation Element (PCE) based approach has been 138 proposed as Application-Based Network Operations (ABNO) in 139 [RFC7491]. 141 In such centralized controller architectures, GMPLS can be applied 142 for the NE-level control. A central controller may support GMPLS 143 enabled domains and may interact with a GMPLS enabled domain where 144 the GMPLS control plane does the service provisioning from ingress 145 to egress. In this case the centralized controller sends the request 146 to the ingress node and does not have to configure all NEs along the 147 path through the domain from ingress to egress thus leveraging the 148 GMPLS control plane. This document describes how GMPLS control 149 interworks with centralized controller system in transport network. 151 2. Overview 153 In this section, overviews of GMPLS control plane and centralized 154 controller system are discussed as well as the interactions between 155 the GMPLS control plane and centralized controllers. 157 2.1. Overview of GMPLS Control Plane 159 GMPLS separates the control plane and the data plane to support 160 time-division, wavelength, and spatial switching, which are 161 significant in transport networks. For the NE level control in 162 GMPLS, each node runs a GMPLS control plane instance. 163 Functionalities such as service provisioning, protection, and 164 restoration can be performed via GMPLS communication among multiple 165 NEs. At the same time, the controller can also collect node and 166 link resources in the network to construct the network topology and 167 compute routing paths for serving service requests. 169 Several protocols have been designed for GMPLS control [RFC3945] 170 including link management [RFC4204], signaling [RFC3471], and 171 routing [RFC4202] protocols. The controllers applying these 172 protocols communicate with each other to exchange resource 173 information and establish Label Switched Paths (LSPs). In this way, 174 controllers in different nodes in the network have the same view of 175 the network topology and provision services based on local policies. 177 2.2. Overview of Centralized Controller System 179 With the development of SDN technologies, a centralized controller 180 architecture has been introduced to transport networks. One example 181 architecture can be found in ACTN [RFC8453]. In such systems, a 182 controller is aware of the network topology and is responsible for 183 provisioning incoming service requests. 185 Multiple hierarchies of controllers are designed at different levels 186 implementing different functions. This kind of architecture enables 187 multi-vendor, multi-domain, and multi-technology control. For 188 example, a higher-level controller coordinates several lower-level 189 controllers controlling different domains, for topology collection 190 and service provisioning. Vendor-specific features can be abstracted 191 between controllers, and standard API (e.g., generated from 192 RESTconf/YANG) is used. 194 2.3. GMPLS Control Interwork with Centralized Controller System 196 Besides the GMPLS and the interactions among the controller 197 hierarchies, it is also necessary for the controllers to communicate 198 with the network elements. Within each domain, GMPLS control can be 199 applied to each NE. The bottom-level central controller can act as a 200 NE to collect network information and initiate LSP. Figure 1 shows 201 an example of GMPLS interworking with centralized controllers (ACTN 202 terminologies are used in the figure). 204 +-------------------+ 205 | Orchestrator | 206 +-------------------+ 207 ^ ^ ^ 208 | | | 209 +-------------+ | +-------------+ 210 | |RESTConf/YANG models | 211 V V V 212 +----------+ +----------+ +----------+ 213 |Controller| |Controller| |Controller| 214 +----------+ +----------+ +----------+ 215 ^ ^ ^ ^ ^ 216 | | | | | 217 Netconf| |PCEP Netconf| |PCEP | IF* 218 /YANG | | /YANG | | | 219 V V V V V 220 .----------. Inter- .----------. Inter- .----------. 221 / \ domain / \ domain / \ 222 | | link | LMP | link | LMP | 223 | |======| OSPF-TE |======| OSPF-TE | 224 | | | RSVP-TE | | RSVP-TE | 225 \ / \ / \ / 226 `----------` `----------` `----------` 227 Non-GMPLS domain 1 GMPLS domain 2 GMPLS domain 3 229 Figure 1: Example of GMPLS/non-GMPLS interworks with Controllers 231 Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS 232 domain. This system supports the interworking among non-GMPLS 233 domain, GMPLS domain and the controller hierarchies. For domain 1, 234 the network element were not enabled with GMPLS so the control can 235 be purely from the controller, via Netconf/YANG and/or PCEP. For 236 domain 2 and 3, each domain has the GMPLS control plane enabled at 237 the physical network level. The PNC can exploit GMPLS capability 238 implemented in the domain to listen to the IGP routing protocol 239 messages (OSPF LSAs for example) that the GMPLS control plane 240 instances are disseminating into the network and thus learn the 241 network topology. For path computation in the domain with PNC 242 implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP 243 to ask the PNC for a path and get replies. The MDSC communicates 244 with PNCs using for example REST/RESTConf based on YANG data models. 245 As a PNC has learned its domain topology, it can report the topology 246 to the MDSC. When a service arrives, the MDSC computes the path and 247 coordinates PNCs to establish the corresponding LSP segment. 249 Alternatively, the NETCONF protocol can be used to retrieve topology 250 information utilizing the e.g. [RFC8795] Yang model and the 251 technology-specific YANG model augmentations required for the 252 specific network technology. The PNC can retrieve topology 253 information from any NE (the GMPLS control plane instance of each NE 254 in the domain has the same topological view), construct the topology 255 of the domain and export an abstracted view to the MDSC. Based on 256 the topology retrieved from multiple PNCs, the MDSC can create 257 topology graph of the multi-domain network, and can use it for path 258 computation. To setup a service, the MDSC can exploit e.g. [TE- 259 Tunnel] Yang model together with the technology-specific YANG model 260 augmentations. 262 3. Discovery Options 264 In GMPLS control, the link connectivity need to be verified between 265 each pair of nodes. In this way, link resources, which are 266 fundamental resources in the network, are discovered by both ends of 267 the link. 269 3.1. LMP 271 Link management protocol (LMP) [RFC4204] runs between a pair of 272 nodes and is used to manage TE links. In addition to the setup and 273 maintenance of control channels, LMP can be used to verify the data 274 link connectivity and correlate the link property. 276 4. Routing Options 278 In GMPLS control, link state information is flooded within the 279 network as defined in [RFC4202]. Each node in the network can build 280 the network topology according to the flooded link state 281 information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE 282 [RFC5307] have been extended to support different interfaces in 283 GMPLS. 285 In centralized controller system, central controller can be placed 286 at the GMPLS network and passively receive the information flooded 287 in the network. In this way, the central controller can construct 288 and update the network topology. 290 4.1. OSPF-TE 292 OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions 293 have been defined in [RFC4203] to enable the capability of link 294 state information for GMPLS network. Based on this work, OSPF 295 protocol has been extended to support technology-specific routing. 296 The routing protocol for OTN, WSON and optical flexi-grid network 297 are defined in [RFC7138], [RFC7688] and [RFC8363], respectively. 299 4.2. ISIS-TE 301 ISIS-TE is introduced for TE networks in [RFC5305] and is extended 302 to support GMPLS routing functions [RFC5307], and has been updated 303 to [RFC7074] to support the latest GMPLS switching capability and 304 Types fields. 306 4.3. Netconf/RESTconf 308 Netconf [RFC6241] and RESTconf [RFC8040] protocols are originally 309 used for network configuration. Besides, these protocols can also be 310 used for topology retrieval by using topology-related YANG models, 311 such as [RFC8345] and [RFC8795]. These protocols provide a powerful 312 mechanism for notification that permits to notify the client about 313 topology changes. 315 5. Path Computation 317 Once a controller learns the network topology, it can utilize the 318 available resources to serve service requests by performing path 319 computation. Due to abstraction, the controllers may not have 320 sufficient information to compute the optimal path. In this case, 321 the controller can interact with other controllers by sending Yang 322 Path Computation requests [PAT-COMP] to compute a set of potential 323 optimal paths and then, based on its own constraints, policy and 324 specific knowledge (e.g. cost of access link) can choose the more 325 feasible path for service e2e path setup. 327 Path computation is one of the key objectives in various types of 328 controllers. In the given architecture, it is possible for different 329 components that have the capability to compute the path. 331 5.1. Constraint-based Path Computing in GMPLS Control 333 In GMPLS control, a routing path is computed by the ingress node 334 [RFC3473] and is based on the ingress node TED. Constraint-based 335 path computation is performed according to the local policy of the 336 ingress node. 338 5.2. Path Computation Element (PCE) 340 PCE has been introduced in [RFC4655] as a functional component that 341 provides services to compute path in a network. In [RFC5440], the 342 path computation is accomplished by using the Traffic Engineering 343 Database (TED), which maintains the link resources in the network. 344 The emergence of PCE efficiently improve the quality of network 345 planning and offline computation, but there is a risk that the 346 computed path may be infeasible if there is a diversity requirement, 347 because stateless PCE has no knowledge about the former computed 348 paths. 350 To address this issue, stateful PCE has been proposed in [RFC8231]. 351 Besides the TED, an additional LSP Database (LSP-DB) is introduced 352 to archive each LSP computed by the PCE. In this way, PCE can easily 353 figure out the relationship between the computing path and former 354 computed paths. In this approach, PCE provides computed paths to 355 PCC, and then PCC decides which path is deployed and when to be 356 established. 358 In PCE Initiation [RFC8281], PCE is allowed to trigger the PCC to 359 setup, maintenance, and teardown of the PCE-initiated LSP under the 360 stateful PCE model. This would allow a dynamic network that is 361 centrally controlled and deployed. 363 In centralized controller system, the PCE can be implemented in a 364 central controller, and the central controller performs path 365 computation according to its local policies. On the other hand, the 366 PCE can also be placed outside of the central controller. In this 367 case, the central controller acts as a PCC to request path 368 computation to the PCE through PCEP. One of the reference 369 architecture can be found at [RFC7491]. 371 6. Signaling Options 373 Signaling mechanisms are used to setup LSPs in GMPLS control. 374 Messages are sent hop by hop between the ingress node and the egress 375 node of the LSP to allocate labels. Once the labels are allocated 376 along the path, the LSP setup is accomplished. Signaling protocols 377 such as RSVP-TE [RFC3473] have been extended to support different 378 interfaces in GMPLS. 380 6.1. RSVP-TE 382 RSVP-TE is introduced in [RFC3209] and extended to support GMPLS 383 signaling in [RFC3473]. Several label formats are defined for a 384 generalized label request, a generalized label, suggested label and 385 label sets. Based on [RFC3473], RSVP-TE has been extended to support 386 technology-specific signaling. The RSVP-TE extensions for OTN, WSON, 387 optical flexi-grid network are defined in [RFC7139], [RFC7689], and 388 [RFC7792], respectively. 390 7. Interworking Scenarios 392 7.1. Topology Collection & Synchronization 394 Topology information is necessary on both network elements and 395 controllers. The topology on network element is usually raw 396 information, while the topology on the controller can be either raw 397 or abstracted. Three different abstraction methods have been 398 described in [RFC8453], and different controllers can select the 399 corresponding method depending on application. 401 When there are changes in the network topology, the impacted network 402 element(s) need to report changes to all the other network elements, 403 together with the controller, to sync up the topology information. 404 The inter-NE synchronization can be achieved via protocols mentioned 405 in section 3 and 4. The topology synchronization between NEs and 406 controllers can either be achieved by routing protocols OSPF- 407 TE/PCEP-LS in [PCEP-LS] or Netconf protocol notifications with YANG 408 model. 410 7.2. Multi-domain Service Provisioning 412 Based on the topology information on controllers and network 413 elements, service provisioning can be deployed. Plenty of methods 414 have been specified for single domain service provisioning, such as 415 using PCEP and RSVP-TE. 417 Multi-domain service provisioning would request coordination among 418 the controller hierarchies. Given the service request, the end-to- 419 end delivery procedure may include interactions at any level (i.e. 420 interface) in the hierachy of the controllers (e.g. MPI and SBI for 421 ACTN). The computation for a cross-domain path is usually completed 422 by controllers who have a global view of the topologies. Then the 423 configuration is decomposed into lower layer controllers, to 424 configure the network elements to set up the path. 426 A combination of the centralized and distributed protocols may be 427 necessary for the interaction between network elements and 428 controller. Several methods can be used to create the inter-domain 429 path: 431 1) With end-to-end RSVP-TE session: 433 In this method, the SDN controller of the source domain triggers the 434 source node to create the end-to-end RSVP-TE session, and the 435 assignment and distribution of the labels on the inter-domain links 436 are done by the boarder nodes of each domain, using RSVP-TE 437 protocol. Therefore, this method requires the interworking of RSVP- 438 TE protocols between different domains. 440 There are two possible methods: 442 1.1) One single end-to-end RSVP-TE session 444 In this method, an end-to-end RSVP-TE session from the source NE to 445 the destination NE will be used to create the inter-domain path. A 446 typical example would be the PCE Initiation scenario, in which a PCE 447 message (PCInitiate) is sent from the controller to the first-end 448 node, and then trigger a RSVP procedure along the path. Similarly, 449 the interaction between the controller and the ingress node of a 450 domain can be achieved by Netconf protocol with corresponding YANG 451 models, and then completed by running RSVP among the network 452 elements. 454 1.2) LSP Stitching 456 The LSP stitching method defined in [RFC5150] can also be used to 457 create the end-to-end LSP. I.e., when the source node receives an 458 end-to-end path creation request (e.g., using PCEP or Netconf 459 protocol), the source node starts an end-to-end RSVP-TE session 460 along the end points of each LSP segment (refers to S-LSP in 461 [RFC5150]) of each domain, to assign the labels on the inter-domain 462 links between each pair of neighbor S-LSPs, and stitch the end-to- 463 end LSP to each S-LSP. See Figure 2 as an example. Note that the S- 464 LSP in each domain can be either created by each domain controller 465 in advance, or created dynamically triggered by the end-to-end RSVP- 466 TE session. 468 +-----------------+ +----------------+ +-----------------+ 469 |Client | | | | Client| 470 |Signal Domain 1| | Domain 2 | |Domain 3 Signal| 471 | | | | | | | | 472 |+-+-+ | | | | +-+-+| 473 || | | +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ | | || 474 || | | | | | || || | | | | || || | | | | | || 475 || ******************************************************** || 476 || | | | | || || | | | | || || | | | | || 477 |+---+ +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ +---+| 478 +-----------------+ +----------------+ +-----------------+ 479 | . . . . . . | 480 | .<-S-LSP 1->. .<- S-LSP 2 -->. .<-S-LSP 3->. | 481 | . . . . | 482 |-------------->.---->.------------->.---->.-------------->| 483 |<--------------.<----.<-------------.<----.<--------------| 484 | End-to-end RSVP-TE session for LSP stitching | 486 Figure 2: LSP stitching 488 2) Without end-to-end RSVP-TE session: 490 In this method, each SDN controller is responsible to create the 491 path segment within its domain. The boarder node does not need to 492 communicate with other boarder nodes in other domains for the 493 distribution of labels on inter-domain links, so end-to-end RSVP-TE 494 session through multiple domains is not required, and the 495 interworking of RSVP-TE protocol between different domains is not 496 needed. 498 Note that path segments in the source domain and the destination 499 domain are "asymmetrical" segments, because the configuration of 500 client signal mapping into server layer tunnel is needed at only one 501 end of the segment, while configuration of server layer cross- 502 connect is needed at the other end of the segment. For example, the 503 path segment 1 and 3 in Figure 3 are asymmetrical segments, because 504 one end of the segment requires mapping GE into ODU0, while the 505 other end of the segment requires setting up ODU0 cross-connect. 507 +-----------------+ +----------------+ +-----------------+ 508 |Client | | | | Client| 509 |Signal Domain 1| | Domain 2 | |Domain 3 Signal| 510 |(GE) | | | | (GE) | 511 | | ODU0 tunnel| | | | | | 512 |+-+-+ ^ | | | | +-+-+| 513 || | | +--+ |+--+| |+--+ +--+ +--+| |+--+ +--+ | | || 514 || | | | | || || || | | | | || || | | | | | || 515 || ******************************************************** || 516 || | | | | || . || | | | | || . || | | | | || 517 |+---+ +--+ +--+| . |+--+ +--+ +--+| . |+--+ +--+ +---+| 518 +-----------------+ . +----------------+ . +-----------------+ 519 . . . . 520 .<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->. 521 . . . . 523 Figure 3: Example of asymmetrical path segment 525 The PCEP / GMPLS protocols should support creation of such 526 asymmetrical segment. 528 Note also that mechanisms to assign the labels in the inter-domain 529 links are also needed to be considered. There are two possible 530 methods: 532 2.1) Inter-domain labels assigned by NEs: 534 The concept of Stitching Label that allows stitching local path 535 segments was introduced in [RFC5150] and [sPCE-ID], in order to form 536 the inter-domain path crossing several different domains. It also 537 describes the BRPC and H-PCE PCInitiate procedure, i.e., the ingress 538 boarder node of each downstream domain assigns the stitching label 539 for the inter-domain link between the downstream domain and its 540 upstream neighbor domain, and this stitching label will be passed to 541 the upstream neighbor domain by PCE protocol, which will be used for 542 the path segment creation in the upstream neighbor domain. 544 2.2) Inter-domain labels assigned by SDN controller: 546 If the resource of inter-domain links are managed by the multi- 547 domain SDN controller, each single-domain SDN controller can provide 548 to the multi-domain SDN controller the list of available labels 549 (e.g. timeslots if OTN is the scenario) using IETF Topology model 550 and related technology specific extension. Once that multi-domain 551 SDN controller has computed e2e path RSVP-TE or PCEP can be used in 552 the different domains to setup related segment tunnel consisting 553 with label inter-domain information, e.g. for PCEP the label ERO can 554 be included in the PCInitiate message to indicate the inter-domain 555 labels, so that each boarder node of each domain can configure the 556 correct cross-connect within itself. 558 7.3. Multi-layer Service Provisioning 560 GMPLS can interwork with centralized controller system in multi- 561 layer networks. 563 +--------------+ 564 | Multi-layer | 565 |SDN Controller| 566 +-----+--+-----+ 567 | | Higher-layer Network 568 | | .--------------------. 569 | | +--------------+ / \ 570 | | | Higher-layer | | +--+ Link +--+ | 571 | +-->|SDN Controller+----->| | |**********| | | 572 | +--------------+ | +--+ +--+ | 573 | \ . . / 574 | `--.------------.---` 575 | . . 576 | .---.------------.---. 577 | +--------------+ / . . \ 578 | | Lower-layer | | +--+ +--+ +--+ | 579 +----->|SDN Controller+----->| | ============== | | 580 +--------------+ | +--+ +--+ +--+ | 581 \ H-LSP / 582 `-------------------` 583 Lower-layer Network 585 Figure 4: Example of GMPLS-SDN interworking in multi-layer network 587 An example with two layers of network is shown in Figure 4. In this 588 example, the GMPLS control plane is enabled in each layer network, 589 and interworks with the SDN controller of its domain (higher-layer 590 SDN controller and lower-layer SDN controller, respectively). The 591 multi-layer SDN controller, which acts as the Orchestrator, is used 592 to coordinate the control of the multi-layer network. 594 7.3.1. Multi-layer Path Computation 596 [RFC5623] describes three inter-layer path computation models and 597 four inter-layer path control models: 599 - 3 Path computation: 601 o Single PCE path computation model 603 o Multiple PCE path computation with inter-PCE communication 604 model 606 o Multiple PCE path computation without inter-PCE communication 607 model 609 - 4 Path control: 611 o PCE-VNTM cooperation model 613 o Higher-layer signaling trigger model 615 o NMS-VNTM cooperation model (integrated flavor) 617 o NMS-VNTM cooperation model (separate flavor) 619 Section 4.2.4 of [RFC5623] also provides all the possible 620 combinations of inter-layer path computation and inter-layer path 621 control models. 623 To apply [RFC5623] in multi-layer network with GMPLS-SDN 624 interworking, the higher-layer SDN controller and the lower-layer 625 SDN controller can act as the PCE Hi and PCE Lo respectively, and 626 typically, the multi-layer SDN controller can act as a VNTM because 627 it has the abstracted view of both the higher-layer and lower-layer 628 networks. 630 Table 1 shows all possible combinations of path computation and path 631 control models in multi-layer network with GMPLS-SDN interworking: 633 Table 1: Combinations of path computation and path control models 634 --------------------------------------------------------- 635 | Path computation |Single PCE | Multiple | Multiple | 636 | \ | (Not | PCE with | PCE w/o | 637 | Path control |applicable)| inter-PCE | inter-PCE | 638 |---------------------+-----------+-----------+-----------| 639 | PCE-VNTM | ...... | | | 640 | cooperation | . -- . | Yes | Yes | 641 | | . . | | | 642 |---------------------+--.----.---+-----------+-----------| 643 | Higher-layer | . . | | | 644 | signaling trigger | . -- . | Yes | Yes | 645 | | . . | | | 646 |---------------------+--.----.---+-----------+-----------| 647 | NMS-VNTM | . . | .........|....... | 648 | cooperation | . -- . | .Yes | No . | 649 | (integrated flavor) | . . | . | . | 650 |---------------------+--.----.---+--.--------+------.----| 651 | NMS-VNTM | . . | . | . | 652 | cooperation | . -- . | .No | Yes. | 653 | (separate flavor) | ...... | .........|....... | 654 ---------------------+----|------+--------|--+----------- 655 V V 656 Not applicable because Typical models to be used 657 there are multiple PCEs 659 Note that: 661 - Since there is one PCE in each layer network, the path computation 662 model "Single PCE path computation" is not applicable. 664 - For the other two path computation models "Multiple PCE with 665 inter-PCE" and "Multiple PCE w/o inter-PCE", the possible 666 combinations are the same as defined in [RFC5623]. More 667 specifically: 669 o The path control models "NMS-VNTM cooperation (integrated 670 flavor)" and "NMS-VNTM cooperation (separate flavor)" are the 671 typical models to be used in multi-layer network with GMPLS-SDN 672 interworking. This is because in these two models, the path 673 computation is triggered by the NMS or VNTM. And in SDN 674 centralized control system, the path computation requests are 675 typically from the multi-layer SDN controller (acts as VNTM). 677 o For the other two path control models "PCE-VNTM cooperation" 678 and "Higher-layer signaling trigger", the path computation is 679 triggered by the NEs, i.e., NE performs PCC functions. These 680 two models are still possible to be used, although they are not 681 the main methods. 683 7.3.2. Cross-layer Path Creation 685 In a multi-layer network, a lower-layer LSP in the lower-layer 686 network can be created, which will construct a new link in the 687 higher-layer network. Such lower-layer LSP is called Hierarchical 688 LSP, or H-LSP for short, see [RFC6107]. 690 The new link constructed by the H-LSP then can be used by the 691 higher-layer network to create new LSPs. 693 As described in [RFC5212], two methods are introduced to create the 694 H-LSP: the static (pre-provisioned) method and the dynamic 695 (triggered) method. 697 1) Static (pre-provisioned) method 699 In this method, the H-LSP in the lower layer network is created in 700 advance. After that, the higher layer network can create LSPs using 701 the resource of the link constructed by the H-LSP. 703 The multi-layer SDN controller is responsible to decide the creation 704 of H-LSP in the lower layer network if it acts as a VNTM. It then 705 requests the lower-layer SDN controller to create the H-LSP via, for 706 example, MPI interface under the ACTN architecture. See Section 707 3.3.2 of [TE-Tunnel]. 709 The lower-layer SDN controller can trigger the GMPLS control plane 710 to create the H-LSP. As a typical example, the PCInitiate message 711 can be used for the communication between the lower-layer SDN 712 controller and the source node of the H-LSP. 714 And the source node of the H-LSP can trigger the RSVP-TE signaling 715 procedure to create the H-LSP, as described in [RFC6107]. 717 2) Dynamic (triggered) method 719 In this method, the signaling of LSP creation in the higher layer 720 network will trigger the creation of H-LSP in the lower layer 721 network dynamically, if it is necessary. 723 In this case, after the cross-layer path is computed, the multi- 724 layer SDN controller requests the higher-layer SDN controller for 725 the cross-layer LSP creation. As a typical example, the MPI 726 interface under the ACTN architecture could be used. 728 The higher-layer SDN controller can trigger the GMPLS control plane 729 to create the LSP in the higher-layer network. As a typical example, 730 the PCInitiate message can be used for the communication between the 731 higher-layer SDN controller and the source node of the Higher-layer 732 LSP, as described in Section 4.3 of [RFC8282]. At least two sets of 733 ERO information should be included to indicate the routes of higher- 734 layer LSP and lower-layer H-LSP. 736 The source node of the Higher-layer LSP follows the procedure 737 defined in Section 4 of [RFC6001], to trigger the GMPLS control 738 plane in both higher-layer network and lower-layer network to create 739 the higher-layer LSP and the lower-layer H-LSP. 741 On success, the source node of the H-LSP should report the 742 information of the H-LSP to the lower-layer SDN controller via, for 743 example, PCRpt message. 745 7.3.3. Link Discovery 747 If the higher-layer network and the lower-layer network are under 748 the same GMPLS control plane instance, the H-LSP can be an FA-LSP. 749 Then the information of the link constructed by this FA-LSP, called 750 FA, can be advertised in the routing instance, so that the higher- 751 layer SDN controller can be aware of this new FA. [RFC4206] and the 752 following updates to it (including [RFC6001] and [RFC6107]) describe 753 the detail extensions to support advertisement of an FA. 755 If the higher-layer network and the lower-layer network are under 756 separated GMPLS control plane instances, after an H-LSP is created 757 in the lower-layer network, the link discovery procedure defined in 758 LMP protocol ([RFC4204]) will be triggered in the higher-layer 759 network to discover the information of the link constructed by the 760 H-LSP. The information of this new link will be advertised to the 761 higher-layer SDN controller. 763 7.4. Recovery 765 The GMPLS recovery functions are described in [RFC4426]. Two models, 766 span protection and end-to-end protection and restoration, are 767 discussed with different protection schemes and message exchange 768 requirements. Related RSVP-TE extensions to support end-to-end 769 recovery is described in [RFC4872]. The extensions in [RFC4872] 770 include protection, restoration, preemption, and rerouting 771 mechanisms for an end-to-end LSP. Besides end-to-end recovery, a 772 GMPLS segment recovery mechanism is defined in [RFC4873]. By 773 introducing secondary record route objects, LSP segment can be 774 switched to another path like fast reroute [RFC4090]. 776 7.4.1. Span Protection 778 Span protection refers to the protection of the link between two 779 neighboring switches. The main protocol requirements include: 781 - Link management: Link property correlation on the link protection 782 type; 784 - Routing: announcement of the link protection type; 786 - Signaling: indication of link protection requirement for that LSP. 788 GMPLS already supports the above requirements, and there are no new 789 requirements in the scenario of interworking between GMPLS and 790 centralized controller system. 792 7.4.2. LSP Protection 794 The LSP protection includes end-to-end and segment LSP protection. 795 For both cases: 797 - In the provisioning phase: 799 The disjoint path computation can be done by the centralized 800 controller system, as it has the global topology and resource 801 view. And the path creation can be done by the procedure described 802 in Section 7.2. 804 - In the protection switchover phase: 806 The existing standards provide the distributed way to trigger the 807 protection switchover. For example, data plane Automatic 808 Protection Switching (APS) mechanism, or GMPLS Notify mechanism 809 described in [RFC4872] and [RFC4873]. In the scenario of 810 interworking between GMPLS and centralized controller system, it 811 is recommended to still use these distributed mechanisms rather 812 than centralized mechanism (i.e., the controller triggers the 813 protection switchover) in the scenario of interworking between 814 GMPLS and centralized controller system. This can significantly 815 shorten the protection switching time. 817 7.4.3. LSP Restoration 819 - Pre-planned LSP rerouting (including shared-mesh restoration): 821 In pre-planned protecting, the protecting LSP is established only 822 in the control plane in the provisioning phase, and will be 823 activated in the data plane once failure occurs. 825 In the scenario of interworking between GMPLS and centralized 826 controller system, the route of protecting LSP can be computed by 827 the centralized controller system. This takes the advantage of 828 making better use of network resource, especially for the resource 829 sharing in shared-mesh restoration. 831 - Full LSP rerouting: 833 In full LSP rerouting, the normal traffic will be switched to an 834 alternate LSP that is fully established only after failure 835 occurrence. 837 As described in [RFC4872] and [RFC4873], the alternate route can 838 be computed on demand when failure occurrence, or pre-computed and 839 stored before failure occurrence. 841 In a fully distributed scenario, the pre-computation method offers 842 faster restoration time, but has the risk that the pre-computed 843 alternate route may become out of date due to the changes of the 844 network. 846 In the scenario of interworking between GMPLS and centralized 847 controller system, the pre-computation of the alternate route 848 could be taken place in the centralized controller (and may be 849 stored in the controller or the head-end node of the LSP). In this 850 way, any changes in the network can trigger the refreshment of the 851 alternate route by the centralized controller. This makes sure 852 that the alternate route will not become out of date. 854 7.5. Controller Reliability 856 Given the important role in the network, the reliability of 857 controller is critical. Once a controller is shut down, the network 858 should operate as well. It can be either achieved by controller back 859 up or functionality back up. There are several of controller backup 860 or federation mechanisms in the literature. It is also more reliable 861 to have some function back up in the network element, to guarantee 862 the performance in the network. 864 8. Manageability Considerations 866 Each entity in the network, including both controllers and network 867 elements, should be managed properly as it will interact with other 868 entities. The manageability considerations in controller hierarchies 869 and network elements still apply respectively. For the protocols 870 applied in the network, manageability is also requested. 872 The responsibility of each entity should be clarified. The control 873 of function and policy among different controllers should be 874 consistent via proper negotiation process. 876 9. Security Considerations 878 This document provides the interwork between the GMPLS and 879 controller hierarchies. The security requirements in both system 880 still applies respectively. Protocols referenced in this document 881 also have various security considerations, which is also expected to 882 be satisfied. 884 Other considerations on the interface between the controller and the 885 network element are also important. Such security includes the 886 functions to authenticate and authorize the control access to the 887 controller from multiple network elements. Security mechanisms on 888 the controller are also required to safeguard the underlying network 889 elements against attacks on the control plane and/or unauthorized 890 usage of data transport resources. 892 10. IANA Considerations 894 This document requires no IANA actions. 896 11. References 898 11.1. Normative References 900 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 901 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 902 Tunnels", RFC 3209, December 2001. 904 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 905 Switching (GMPLS) Signaling Resource ReserVation Protocol- 906 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 907 January 2003. 909 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 910 (TE) Extensions to OSPF Version 2", RFC 3630, September 911 2003. 913 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 914 Switching (GMPLS) Architecture", RFC 3945, October 2004. 916 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 917 Support of Generalized Multi-Protocol Label Switching 918 (GMPLS)", RFC 4203, October 2005. 920 [RFC4206] Kompella, K. and Rekhter Y., "Label Switched Paths (LSP) 921 Hierarchy with Generalized Multi-Protocol Label Switching 922 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 924 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 925 Element (PCE)-Based Architecture", RFC 4655, August 2006. 927 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 928 Ed., "RSVP-TE Extensions in Support of End-to-End 929 Generalized Multi-Protocol Label Switching (GMPLS) 930 Recovery", RFC 4872, May 2007. 932 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 933 "GMPLS Segment Recovery", RFC 4873, May 2007. 935 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 936 Engineering", RFC 5305, October 2008. 938 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 939 in Support of Generalized Multi-Protocol Label Switching 940 (GMPLS)", RFC 5307, October 2008. 942 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 943 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 944 March 2009. 946 [RFC6001] Papadimitriou D., Vigoureux M., Shiomoto K., Brungard D. 947 and Le Roux JL., "Generalized MPLS (GMPLS) Protocol 948 Extensions for Multi-Layer and Multi-Region Networks 949 (MLN/MRN)", RFC 6001, October 2010. 951 [RFC6107] Shiomoto K. and Farrel A., "Procedures for Dynamically 952 Signaled Hierarchical Label Switched Paths", RFC 6107, 953 February 2011. 955 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., 956 "Network Configuration Protocol (NETCONF)", RFC 6241, June 957 2011. 959 [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS 960 Switching Capability and Type Fields", RFC 7074, November 961 2013. 963 [RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for 964 Application-Based Network Operations", RFC7491, March 965 2015. 967 [RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli, 968 D. and Zhang, X., "Problem Statement and Architecture for 969 Information Exchange between Interconnected Traffic- 970 Engineered Networks", RFC7926, July 2016. 972 [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF 973 Protocol", RFC 8040, January 2017. 975 [RFC8282] Oki E., Takeda T., Farrel A. and Zhang F., "Extensions to 976 the Path Computation Element Communication Protocol (PCEP) 977 for Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 978 8282, December 2017. 980 [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 981 Control of Traffic Engineered Networks", RFC 8453, August 982 2018. 984 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., 985 Gonzalez De Dios, O., "YANG Data Model for Traffic 986 Engineering (TE) Topologies", RFC8795, August 2020. 988 11.2. Informative References 990 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 991 Switching (GMPLS) Signaling Functional Description", RFC 992 3471, January 2003. 994 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 995 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 996 May 2005. 998 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 999 in Support of Generalized Multi-Protocol Label Switching 1000 (GMPLS)", RFC 4202, October 2005. 1002 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 1003 October 2005. 1005 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 1006 Ed., "Generalized Multi-Protocol Label witching (GMPLS) 1007 Recovery Functional Specification", RFC 4426, March 2006. 1009 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, J.P., Farrel, A., 1010 "Label Switched Path Stitching with Generalized 1011 Multiprotocol Label Switching Traffic Engineering (GMPLS 1012 TE)", RFC 5150, February, 2008. 1014 [RFC5212] Shiomoto K., Papadimitriou D., Le Roux JL., Vigoureux M. 1015 and Brungard D., "Requirements for GMPLS-Based Multi- 1016 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 1017 2008. 1019 [RFC5623] Oki E., Takeda T., Le Roux JL. and Farrel A., "Framework 1020 for PCE-Based Inter-Layer MPLS and GMPLS Traffic 1021 Engineering", RFC 5623, September 2009. 1023 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 1024 J. Drake, "Traffic Engineering Extensions to OSPF for 1025 GMPLS Control of Evolving G.709 Optical Transport 1026 Networks", RFC 7138, March 2014. 1028 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 1029 and K. Pithewan, "GMPLS Signaling Extensions for Control 1030 of Evolving G.709 Optical Transport Networks", RFC 7139, 1031 March 2014. 1033 [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF 1034 Enhancement for Signal and Network Element Compatibility 1035 for Wavelength Switched Optical Networks", RFC 7688, 1036 November 2015. 1038 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 1039 and H. Harai, "Signaling Extensions for Wavelength 1040 Switched Optical Networks", RFC 7689, November 2015. 1042 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 1043 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 1044 Support of Flexi-Grid Dense Wavelength Division 1045 Multiplexing (DWDM) Networks", RFC 7792, March 2016. 1047 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1048 Computation Element Communication Protocol (PCEP) 1049 Extensions for Stateful PCE", RFC 8231, September 2017. 1051 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1052 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1053 Model", RFC 8281, October 2017. 1055 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1056 Ananthakrishnan, H., Liu, X., "A YANG Data Model for 1057 Network Topologies", RFC 8345, March 2018. 1059 [RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D. 1060 Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi- 1061 grid DWDM networks", RFC8363, February 2017. 1063 [PAT-COMP] Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O., 1064 Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang 1065 model for requesting Path Computation", draft-ietf-teas- 1066 yang-path-computation, work in progress. 1068 [PCEP-LS] Dhody, D., Lee, Y., Ceccarelli, D., "PCEP Extensions for 1069 Distribution of Link-State and TE Information", draft- 1070 dhodylee-pce-pcep-ls, work in progress. 1072 [TE-Tunnel] Saad, T. et al., "A YANG Data Model for Traffic 1073 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1074 te, work in progress. 1076 [sPCE-ID] Dugeon, O. et al., "PCEP Extension for Stateful Inter- 1077 Domain Tunnels", draft-ietf-pce-stateful-interdomain, work 1078 in progress. 1080 12. Authors' Addresses 1082 Haomian Zheng 1083 Huawei Technologies 1084 H1, Huawei Xiliu Beipo Village, Songshan Lake 1085 Dongguan 1086 Guangdong, 523808 China 1087 Email: zhenghaomian@huawei.com 1089 Xianlong Luo 1090 Huawei Technologies 1091 G1, Huawei Xiliu Beipo Village, Songshan Lake 1092 Dongguan 1093 Guangdong, 523808 China 1094 Email: luoxianlong@huawei.com 1096 Yunbin Xu 1097 CAICT 1098 Email: xuyunbin@caict.ac.cn 1100 Yang Zhao 1101 China Mobile 1102 Email: zhaoyangyjy@chinamobile.com 1104 Sergio Belotti 1105 Nokia 1106 Email: sergio.belotti@nokia.com 1108 Dieter Beller 1109 Nokia 1110 Email: Dieter.Beller@nokia.com 1112 Yi Lin 1113 Huawei Technologies 1114 H1, Huawei Xiliu Beipo Village, Songshan Lake 1115 Dongguan 1116 Guangdong, 523808 China 1117 Email: yi.lin@huawei.com