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