idnits 2.17.1 draft-contreras-layered-sdn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 21, 2018) is 1983 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-15 == Outdated reference: A later version (-17) exists of draft-ietf-ccamp-transport-nbi-app-statement-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Informational CJ. Bernardos 5 Expires: May 25, 2019 UC3M 6 D. Lopez 7 Telefonica 8 M. Boucadair 9 Orange 10 P. Iovanna 11 Ericsson 12 November 21, 2018 14 Cooperating Layered Architecture for Software Defined Networking (CLAS) 15 draft-contreras-layered-sdn-03 17 Abstract 19 Software Defined Networking adheres to the separation of the control 20 plane from the data plane in the network nodes and its logical 21 centralization on one or a set of control entities. Most of the 22 network and/or sevice intelligence is moved to these control 23 entities. Typically, such entity is seen as a compendium of 24 interacting control functions in a vertical, tight integrated 25 fashion. The relocation of the control functions from a number of 26 distributed network nodes to a logical central entity conceptually 27 places together a number of control capabilities with different 28 purposes. As a consequence, the existing solutions do not provide a 29 clear separation between transport control and services that relies 30 upon transport capabilities. 32 This document describes an approach named Cooperating Layered 33 Architecture for Software Defined Networking. The idea behind that 34 is to differentiate the control functions associated to transport 35 from those related to services, in such a way that they can be 36 provided and maintained independently, and can follow their own 37 evolution path. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 25, 2019. 56 Copyright Notice 58 Copyright (c) 2018 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 76 3.1. Functional Strata . . . . . . . . . . . . . . . . . . . . 9 77 3.1.1. Transport Stratum . . . . . . . . . . . . . . . . . . 9 78 3.1.2. Service Stratum . . . . . . . . . . . . . . . . . . . 10 79 3.1.3. Recursiveness . . . . . . . . . . . . . . . . . . . . 10 80 3.2. Plane Separation . . . . . . . . . . . . . . . . . . . . 10 81 3.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 11 82 3.2.2. Management Plane . . . . . . . . . . . . . . . . . . 11 83 3.2.3. Resource Plane . . . . . . . . . . . . . . . . . . . 11 84 4. Required Features . . . . . . . . . . . . . . . . . . . . . . 11 85 5. Communication Between SDN Controllers . . . . . . . . . . . . 12 86 6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 12 87 6.1. Full SDN Environments . . . . . . . . . . . . . . . . . . 12 88 6.1.1. Multiple Service Strata Associated to a Single 89 Transport Stratum . . . . . . . . . . . . . . . . . . 13 90 6.1.2. Single Service Stratum associated to multiple 91 Transport Strata . . . . . . . . . . . . . . . . . . 13 92 6.2. Hybrid Environments . . . . . . . . . . . . . . . . . . . 13 93 6.2.1. SDN Service Stratum associated to a Legacy Transport 94 Stratum . . . . . . . . . . . . . . . . . . . . . . . 13 95 6.2.2. Legacy Service Stratum Associated to an SDN Transport 96 Stratum . . . . . . . . . . . . . . . . . . . . . . . 13 98 6.3. Multi-domain Scenarios in Transport Stratum . . . . . . . 13 99 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 100 7.1. Network Function Virtualization (NFV) . . . . . . . . . . 14 101 7.2. Abstraction and Control of Transport Networks . . . . . . 14 102 8. Challenges for Implementing Actions Between Service and 103 Transport Strata . . . . . . . . . . . . . . . . . . . . . . 15 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 106 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 109 12.2. Informative References . . . . . . . . . . . . . . . . . 17 110 Appendix A. Relationship with RFC7426 . . . . . . . . . . . . . 18 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 113 1. Introduction 115 Network softwarization advances are facilitating the introduction of 116 programmability in services and infrastructures of telco operators. 117 This is achieved generically through the introduction of Software 118 Defined Networking (SDN, [RFC7149][RFC7426]) capabilities in the 119 network, including controllers and orchestrators. 121 However, there are concerns of different nature that these SDN 122 capabilities have to resolve. In one hand there is a need for 123 actions focused on programming the network for handle the 124 connectivity or forwarding of digital data between distant nodes. On 125 the other hand, there is a need for actions devoted to program the 126 functions or services that process (or manipulate) such digital data. 128 SDN adheres to the separation of the control plane from the data 129 plane in the network nodes by introducing abstraction among both 130 planes, allowing to centralize the control logic on a functional 131 entity which is commonly referred as SDN Controller; one or multiple 132 controllers may be deployed. A programmatic interface is then 133 defined between a forwarding entity (at the network node) and a 134 control entity. Through that interface, a control entity instructs 135 the nodes involved in the forwarding plane and modifies their traffic 136 forwarding behavior accordingly. Additional capabilities (e.g., 137 performance monitoring, fault management, etc.) could be expected to 138 be supported through such kind of programmatic interface [RFC7149]. 140 Most of the intelligence is moved to such functional entity. 141 Typically, such entity is seen as a compendium of interacting control 142 functions in a vertical, tight integrated fashion. 144 The approach of considering an omnipotent control entity governing 145 the overall aspects of a network, especially both the transport 146 network and the services to be supported on top of it, presents a 147 number of issues: 149 o From a provider perspective, where usually different departments 150 are responsible of handling service and connectivity (i.e., 151 transport capabilities for the service on top), the mentioned 152 approach offers unclear responsibilities for complete service 153 provision and delivery. 155 o Complex reuse of functions for the provision of services. 157 o Closed, monolithic control architectures. 159 o Difficult interoperability and interchangeability of functional 160 components. 162 o Blurred business boundaries among providers, especially in 163 situations where a provider provides just connectivity while 164 another provider offers a more sophisticated service on top of 165 that connectivity. 167 o Complex service/network diagnosis and troubleshooting, 168 particularly to determine which segment is responsible for a 169 failure. 171 The relocation of the control functions from a number of distributed 172 network nodes to another entity conceptually places together a number 173 of control capabilities with different purposes. As a consequence, 174 the existing SDN solutions do not provide a clear separation between 175 services and transport control. Here, the separation between service 176 and transport follows the distinction provided by [Y.2011], and also 177 defined in Section 2 of this document. 179 This document describes an approach named Cooperating Layered 180 Architecture for SDN (CLAS). The idea behind that is to 181 differentiate the control functions associated to transport from 182 those related to services, in such a way that they can be provided 183 and maintained independently, and can follow their own evolution 184 path. 186 Despite such differentiation it is required a close cooperation 187 between service and transport layers (or strata in [Y.2011]) and 188 associated components to provide an efficient usage of the resources. 190 2. Terminology 192 This document makes use of the following terms: 194 o Transport: denotes the transfer capabilities offered by a 195 networking infrastructure. The transfer capabilities can rely 196 upon pure IP techniques, or other means such as MPLS or optics. 198 o Service: denotes a logical construct that makes use of transport 199 capabilities. 201 This document does not make any assumption on the functional 202 perimeter of a service that can be built above a transport 203 infrastructure. As such, a service can be an offering that is 204 offered to customers or be invoked for the delivery of another 205 (added-value) service. 207 o Layer: refers to the set of elements comprised for enabling either 208 transport or service capabilities as defined before. In [Y.2011], 209 this is referred to as stratum, and both are used interchangeably. 211 o Domain: is a set of elements which share a common property or 212 characteristic. In this document this applies to administrative 213 domain (i.e., elements pertaining to the same organization), 214 technological domain (elements implementing the same kind of 215 technology, as for example optical nodes), etc. 217 o SDN Intelligence: refers to the decision-making process that is 218 hosted by a node or a set of nodes. These nodes are called SDN 219 controllers. 221 The intelligence can be centralized or distributed. Both schemes 222 are within the scope of this document. 224 The SDN intelligence relies on inputs form various functional 225 blocks such as: network topology discovery, service topology 226 discovery, resource allocation, business guidelines, customer 227 profiles, service profiles, etc. 229 The exact decomposition of an SDN intelligence, apart from the 230 layering discussed in this document, is out of scope. 232 Additionally, the following acronyms are used in this document: 234 CLAS: Cooperating Layered Architecture for SDN 236 FCAPS: Fault, Configuration, Accounting, Performance and Security 237 SDN: Software Defined Networking 239 SLA: Service Level Agreement 241 3. Architecture Overview 243 Current operator networks support multiple services (e.g., VoIP, 244 IPTV, mobile VoIP, critical mission applications, etc.) on a variety 245 of transport technologies. The provision and delivery of a service 246 independently of the underlying transport capabilities require a 247 separation of the service related functionalities and an abstraction 248 of the transport network to hide the specificities of underlying 249 transfer techniques while offering a common set of capabilities. 251 Such separation can provide configuration flexibility and 252 adaptability from the point of view of either the services or the 253 transport network. Multiple services can be provided on top of a 254 common transport infrastructure, and similarly, different 255 technologies can accommodate the connectivity requirements of a 256 certain service. A close coordination among them is required for a 257 consistent service delivery (inter-layer cooperation). 259 This document focuses particularly on: 261 o Means to expose transport capabilities to services. 263 o Means to capture service requirements of services. 265 o Means to notify service intelligence with underlying transport 266 events, for example to adjust service decision-making process with 267 underlying transport events. 269 o Means to instruct the underlying transport capabilities to 270 accommodate new requirements, etc. 272 An example is to guarantee some Quality of Service (QoS) levels. 273 Different QoS-based offerings could be present at both service and 274 transport layers. Vertical mechanisms for linking both service and 275 transport QoS mechanisms should be in place to provide the quality 276 guarantees to the end user. 278 CLAS architecture assumes that the logically centralized control 279 functions are separated in two functional layers. One of the 280 functional layers comprises the service-related functions, whereas 281 the other one contains the transport-related functions. The 282 cooperation between the two layers is expected to be implemented 283 through standard interfaces. 285 Figure 1 shows the CLAS architecture. It is based on functional 286 separation in the NGN architecture defined by the ITU-T in [Y.2011], 287 where two strata of functionality are defined, namely the Service 288 Stratum, comprising the service-related functions, and the 289 Connectivity Stratum, covering the transport ones. The functions on 290 each of these layers are further grouped on control, management and 291 user (or data) planes. 293 CLAS adopts the same structured model described in [Y.2011] but 294 applying it to the objectives of programmability through SDN 295 [RFC7149]. To this respect, CLAS advocates for addressing services 296 and transport in a separated manner because of their differentiated 297 concerns. 299 Applications 300 /\ 301 || 302 || 303 +-------------------------------------||-------------+ 304 | Service Stratum || | 305 | \/ | 306 | ........................... | 307 | . SDN Intelligence . | 308 | . . | 309 | +--------------+ . +--------------+ . | 310 | | Resource Pl. | . | Mngmt. Pl. | . | 311 | | |<===>. +--------------+ | . | 312 | | | . | Control Pl. | | . | 313 | +--------------+ . | |-----+ . | 314 | . | | . | 315 | . +--------------+ . | 316 | ........................... | 317 | /\ | 318 | || | 319 +-------------------------------------||-------------+ 320 || Standard 321 -- || -- API 322 || 323 +-------------------------------------||-------------+ 324 | Transport Stratum || | 325 | \/ | 326 | ........................... | 327 | . SDN Intelligence . | 328 | . . | 329 | +--------------+ . +--------------+ . | 330 | | Resource Pl. | . | Mngmt. Pl. | . | 331 | | |<===>. +--------------+ | . | 332 | | | . | Control Pl. | | . | 333 | +--------------+ . | |-----+ . | 334 | . | | . | 335 | . +--------------+ . | 336 | ........................... | 337 | | 338 | | 339 +----------------------------------------------------+ 341 Figure 1: Cooperating Layered Architecture for SDN 343 In the CLAS architecture both the control and management functions 344 are considered to be performed by one or a set of SDN controllers 345 (due to, e.g., scalability, reliability) providing the SDN 346 Intelligence, in such a way that separated SDN controllers are 347 present in the Service and Transport strata. Management functions 348 are considered to be part of the SDN Intelligence to allow the 349 effective operation in a service provider ecosystem [RFC7149] despite 350 some initial propositions did not consider such management as part of 351 the SDN environment [ONFArch]. 353 Furthermore, the generic user or data plane functions included in the 354 NGN architecture are referred here as resource plane functions. The 355 resource plane in each stratum is controlled by the corresponding SDN 356 Intelligence through a standard interface. 358 The SDN controllers cooperate for the provision and delivery of 359 services. There is a hierarchy in which the Service SDN Intelligence 360 requests transport capabilities to the Transport SDN Intelligence. 362 The Service SDN Intelligence acts as a client of the Transport SDN 363 Intelligence. 365 Furthermore, the Transport SDN Intelligence interacts with the 366 Service SDN Intelligence to inform it about events in the transport 367 network that can motivate actions in the service layer. 369 Despite it is not shown in Figure 1, the resource planes of each 370 stratum could be connected. This will depend on the kind of service 371 provided. Furthermore, the Service stratum could offer an interface 372 towards applications to expose network service capabilities to those 373 applications or customers. 375 3.1. Functional Strata 377 As described before, the functional split separates transport-related 378 functions from service-related functions. Both strata cooperate for 379 a consistent service delivery. 381 Consistency is determined and characterized by the service layer. 383 3.1.1. Transport Stratum 385 The Transport Stratum comprises the functions focused on the transfer 386 of data between the communication end points (e.g., between end-user 387 devices, between two service gateways, etc.). The data forwarding 388 nodes are controlled and managed by the Transport SDN component. 390 The Control plane in the SDN Intelligence is in charge of instructing 391 the forwarding devices to build the end to end data path for each 392 communication or to make sure forwarding service is appropriately 393 setup. Forwarding may not be rely on the sole pre-configured 394 entries; dynamic means can be enabled so that involved nodes can 395 build dynamically routing and forwarding paths (this would require 396 that the nodes retain some of the control and management capabilities 397 for enabling this). Finally, the Management plane performs 398 management functions (i.e., FCAPS) on those devices, like fault or 399 performance management, as part of the Transport Stratum 400 capabilities. 402 3.1.2. Service Stratum 404 The Service stratum contains the functions related to the provision 405 of services and the capabilities offered to external applications. 406 The Resource plane consists of the resources involved in the service 407 delivery, such as computing resources, registries, databases, etc. 409 The Control plane is in charge of controlling and configuring those 410 resources, as well as interacting with the Control plane of the 411 Transport stratum in client mode for requesting transport 412 capabilities for a given service. In the same way, the Management 413 plane implements management actions on the service-related resources 414 and interacts with the Management plane in the Transport Stratum for 415 a cooperating management between layers. 417 3.1.3. Recursiveness 419 Recursive layering can happen in some usage scenarios in which the 420 Transport Stratum is itself structured in Service and Transport 421 Stratum. This could be the case of the provision of a transport 422 service complemented with advanced capabilities additional to the 423 pure data transport (e.g., maintenance of a given SLA [RFC7297]). 425 Recursiveness has been also discussed in [ONFArch] as a way of 426 reaching scalability and modularity, when each higher level can 427 provide greater abstraction capabilities. Additionally, 428 recursiveness can allow some scenarios for multi-domain where single 429 or multiple administrative domains are involved, as the ones 430 described in Section 6.3. 432 3.2. Plane Separation 434 The CLAS architecture leverages on plane separation. As mentioned 435 before, three different planes are considered for each stratum. The 436 communication among these three planes (and with the corresponding 437 plane in other strata) is based on open, standard interfaces. 439 3.2.1. Control Plane 441 The Control plane logically centralizes the control functions of each 442 stratum and directly controls the corresponding resources. [RFC7426] 443 introduces the role of the control plane in a SDN architecture. This 444 plane is part of an SDN Intelligence, and can interact with other 445 control planes in the same or different strata for accomplishing 446 control functions. 448 3.2.2. Management Plane 450 The Management plane logically centralizes the management functions 451 for each stratum, including the management of the Control and 452 Resource planes. [RFC7426] describes the functions of the management 453 plane in a SDN environment. This plane is also part of the SDN 454 Intelligence, and can interact with the corresponding management 455 planes residing in SDN controllers of the same or different strata. 457 3.2.3. Resource Plane 459 The Resource plane comprises the resources for either the transport 460 or the service functions. In some cases the service resources can be 461 connected to the transport ones (e.g., being the terminating points 462 of a transport function) whereas in other cases it can be decoupled 463 from the transport resources (e.g., one database keeping some 464 register for the end user). Both forwarding and operational planes 465 proposed in [RFC7426] would be part of the Resource plane in this 466 architecture. 468 4. Required Features 470 Since the CLAS architecture implies the interaction of different 471 layers with different purposes and responsibilities, a number of 472 features are required to be supported: 474 o Abstraction: the mapping of physical resources into the 475 corresponding abstracted resources. 477 o Service parameter translation: translation of service parameters 478 (e.g., in the form of SLAs) to transport parameters (or 479 capabilities) according to different policies. 481 o Monitoring: mechanisms (e.g., event notifications) available in 482 order to dynamically update the (abstracted) resources' status 483 taking in to account, e.g., the traffic load. 485 o Resource computation: functions able to decide which resources 486 will be used for a given service request. As an example, 487 functions like PCE could be used to compute/select/decide a 488 certain path. 490 o Orchestration: ability to combine diverse resources (e.g., IT and 491 network resources) in an optimal way. 493 o Accounting: record of resource usage. 495 o Security: secure communication among components, preventing, e.g., 496 DoS attacks. 498 5. Communication Between SDN Controllers 500 The SDN controllers residing respectively in the Service and the 501 Transport Stratum need to establish a tight coordination. Mechanisms 502 for transfer relevant information for each stratum should be defined. 504 From the service perspective, the Service SDN Intelligence needs to 505 easily access transport resources through well-defined APIs to 506 retrieve the capabilities offered by the Transport Stratum. There 507 could be different ways of obtaining such transport-aware 508 information, i.e., by discovering or publishing mechanisms. In the 509 former case the Service SDN Intelligence could be able of handling 510 complete information about the transport capabilities (including 511 resources) offered by the Transport Stratum. In the latter case, the 512 Transport Stratum exposes available capabilities, e.g., through a 513 catalog, reducing the amount of detail of the underlying network. 515 On the other hand, the Transport Stratum requires to properly capture 516 Service requirements. These can include SLA requirements with 517 specific metrics (such as delay), level of protection to be provided, 518 max/min capacity, applicable resource constraints, etc. 520 The communication between controllers must be also secure, e.g., by 521 preventing denial of service or any other kind of threats (similarly, 522 the communications with the network nodes must be secure). 524 6. Deployment Scenarios 526 Different situations can be found depending on the characteristics of 527 the networks involved in a given deployment. 529 6.1. Full SDN Environments 531 This case considers that the networks involved in the provision and 532 delivery of a given service have SDN capabilities. 534 6.1.1. Multiple Service Strata Associated to a Single Transport Stratum 536 A single Transport Stratum can provide transfer functions to more 537 than one Service strata. The Transport Stratum offers a standard 538 interface(s) to each of the Service strata. The Service strata are 539 the clients of the Transport Stratum. Some of the capabilities 540 offered by the Transport stratum can be isolation of the transport 541 resources (slicing), independent routing, etc. 543 6.1.2. Single Service Stratum associated to multiple Transport Strata 545 A single Service stratum can make use of different Transport Strata 546 for the provision of a certain service. The Service stratum 547 interfaces each of the Transport Strata with standard protocols, and 548 orchestrates the provided transfer capabilities for building the end 549 to end transport needs. 551 6.2. Hybrid Environments 553 This case considers scenarios where one of the strata is legacy 554 totally or in part. 556 6.2.1. SDN Service Stratum associated to a Legacy Transport Stratum 558 An SDN service stratum can interact with a legacy Transport Stratum 559 through some interworking function able to adapt SDN-based control 560 and management service-related commands to legacy transport-related 561 protocols, as expected by the legacy Transport Stratum. 563 The SDN Intelligence in the Service stratum is not aware of the 564 legacy nature of the underlying Transport Stratum. 566 6.2.2. Legacy Service Stratum Associated to an SDN Transport Stratum 568 A legacy Service stratum can work with an SDN-enabled Transport 569 Stratum through the mediation of and interworking function capable to 570 interpret commands from the legacy service functions and translate 571 them into SDN protocols for operating with the SDN-enabled Transport 572 Stratum. 574 6.3. Multi-domain Scenarios in Transport Stratum 576 The Transport Stratum can be composed by transport resources being 577 part of different administrative, topological or technological 578 domains. The Service Stratum can yet interact with a single entity 579 in the Transport Stratum in case some abstraction capabilities are 580 provided in the transport part to emulate a single stratum. 582 Those abstraction capabilities constitute a service itself offered by 583 the Transport Stratum to the services making use of it. This service 584 is focused on the provision of transport capabilities, then different 585 of the final communication service using such capabilities. 587 In this particular case this recursion allows multi-domain scenarios 588 at transport level. 590 Multi-domain situations can happen in both single-operator and multi- 591 operator scenarios. 593 In single operator scenarios a multi-domain or end-to-end abstraction 594 component can provide an homogeneous abstract view of the underlying 595 heterogeneous transport capabilities for all the domains. 597 Multi-operator scenarios, at the Transport Stratum, should support 598 the establishment of end-to-end paths in a programmatic manner across 599 the involved networks. This could be accomplished, for example, by 600 the exchange of traffic-engineered information of each of the 601 administrative domains [RFC7926]. 603 7. Use Cases 605 This section presents a number of use cases as examples of 606 applicability of the CLAS approach. 608 7.1. Network Function Virtualization (NFV) 610 NFV environments offer two possible levels of SDN control 611 [ETSI_NFV_EVE005]. One level is the need for controlling the NFV 612 Infrastructure (NFVI) to provide connectivity end-to- end among VNFs 613 (Virtual Network Functions) or among VNFs and PNFs (Physical Network 614 Functions). A second level is the control and configuration of the 615 VNFs themselves (in other words, the configuration of the network 616 service implemented by those VNFs), taking profit of the 617 programmability brought by SDN. Both control concerns are separated 618 in nature. However, interaction between both could be expected in 619 order to optimize, scale or influence each other. 621 7.2. Abstraction and Control of Transport Networks 623 Abstraction and Control of Transport Networks (ACTN) [RFC8453] 624 presents a framework to allow the creation of virtual networks to be 625 offered to customers. The concept of provider in ACTN is limited to 626 the offering of virtual network services. These services are 627 essentially transport services, and would correspond to the Transport 628 Stratum in CLAS. On the other hand, the Service Stratum in CLAS can 629 be assimilated as a customer in the context of ACTN. 631 ACTN defines a hierarchy of controllers for facilitating the creation 632 and operation of the virtual networks. An interface is defined for 633 the relation of the customers requesting these virtual networks 634 services with the controller in charge of orchestrating and serving 635 such request. Such interface is equivalent to the one defined in 636 Figure 1 (Section 3) between Service and Transport Strata. 638 8. Challenges for Implementing Actions Between Service and Transport 639 Strata 641 The distinction of service and transport concerns raises a number of 642 challenges in the communication between both strata. The following 643 is a work-in-progress list reflecting some of the identified 644 challenges: 646 o Standard mechanisms for interaction between layers: Nowadays there 647 are a number of proposals that could accommodate requests from the 648 service stratum to the transport stratum. 650 Some of them could be solutions like the Connectivity Provisioning 651 Protocol [I-D.boucadair-connectivity-provisioning-protocol] or the 652 Intermediate-Controller Plane Interface (I-CPI) [ONFArch]. 654 Other potential candidates could be the Transport API [TAPI] or 655 the Transport Transport Northbound Interface 656 [I-D.ietf-ccamp-transport-nbi-app-statement]. Each of these 657 options has a different status of maturity and scope. 659 o Multi-provider awareness: In multi-domain scenarios involving more 660 than one provider at transport level, the service stratum could 661 have or not awareness of such multiplicity of domains. 663 If the service stratum is unaware of the multi-domain situation, 664 then the Transport Stratum acting as entry point of the service 665 stratum request should be responsible of managing the multi-domain 666 issue. 668 On the contrary, if the service stratum is aware of the multi- 669 domain situation, it should be in charge of orchestrating the 670 requests to the different underlying Transport Strata for 671 composing the final end-to-end path among service end-points 672 (i.e., service functions). 674 o SLA mapping: Both strata will handle SLAs but the nature of those 675 SLAs could differ. Then it is required for the entities in each 676 stratum to map service SLAs to connectivity SLAs in order to 677 ensure proper service delivery. 679 o Association between strata: The association between strata could 680 be configured beforehand, or could be dynamic following mechanisms 681 of discovery, that could be required to be supported by both 682 strata with this purpose. 684 o Security: As reflected before, the communication between strata 685 must be secure preventing attacks and threats. Additionally, 686 privacy should be enforced, especially when addressing multi- 687 provider scenarios at transport level. 689 o Accounting: The control and accountancy of resources used and 690 consumed by services should be supported in the communication 691 among strata. 693 9. IANA Considerations 695 This document does not request any action from IANA. 697 10. Security Considerations 699 The CLAS architecture relies upon the functional entities that are 700 introduced in [RFC7149] and [RFC7426]. As such security 701 considerations discussed in Section 5 of [RFC7149], in particular, 702 must be taken into account. 704 The communication between the service and transport SDN controllers 705 must rely on secure means which achieve the following: 707 o Mutual authentication must be enabled before taking any action. 709 o Message integrity protection. 711 Each of the controllers must be provided with instructions about the 712 set of information (and granularity) that can be disclosed to a peer 713 controller. Means to prevent leaking privacy data (e.g., from the 714 service stratum to the transport stratum) must be enabled. The exact 715 set of information to be shared is deployment-specific. 717 A corrupted controller may induce some disruption on another 718 controller. Guards against such attacks should be enabled. 720 Security in the communication between the strata here described 721 should apply on the APIs (and/or protocols) to be defined among them. 722 In consequence, security concerns will correspond to the specific 723 solution. 725 11. Acknowledgements 727 This document was previously discussed and adopted in the IRTF SDN RG 728 as [I-D.irtf-sdnrg-layered-sdn]. After the closure of the IRTF SDN 729 RG this document is being progressed as Individual Submission to 730 record (some of) that group's disucussions. 732 The authors would like to thank (in alphabetical order) Bartosz 733 Belter, Gino Carrozzo, Ramon Casellas, Gert Grammel, Ali Haider, 734 Evangelos Haleplidis, Zheng Haomian, Giorgios Karagianis, Gabriel 735 Lopez, Maria Rita Palatella, Christian Esteve Rothenberg, and Jacek 736 Wytrebowicz for their comments and suggestions. 738 Thanks to Adrian Farrel for the review. 740 12. References 742 12.1. Normative References 744 [Y.2011] "General principles and general reference model for Next 745 Generation Networks", ITU-T Recommendation Y.2011 , 746 October 2004. 748 12.2. Informative References 750 [ETSI_NFV_EVE005] 751 "Report on SDN Usage in NFV Architectural Framework", 752 December 2015. 754 [I-D.boucadair-connectivity-provisioning-protocol] 755 Boucadair, M., Jacquenet, C., Zhang, D., and P. 756 Georgatsos, "Connectivity Provisioning Negotiation 757 Protocol (CPNP)", draft-boucadair-connectivity- 758 provisioning-protocol-15 (work in progress), December 759 2017. 761 [I-D.ietf-ccamp-transport-nbi-app-statement] 762 Busi, I., King, D., Zheng, H., and Y. Xu, "Transport 763 Northbound Interface Applicability Statement", draft-ietf- 764 ccamp-transport-nbi-app-statement-04 (work in progress), 765 November 2018. 767 [I-D.irtf-sdnrg-layered-sdn] 768 Contreras, L., Bernardos, C., Lopez, D., Boucadair, M., 769 and P. Iovanna, "Cooperating Layered Architecture for 770 SDN", draft-irtf-sdnrg-layered-sdn-01 (work in progress), 771 October 2016. 773 [ONFArch] Open Networking Foundation, "SDN Architecture, Issue 1", 774 June 2014, 775 . 779 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 780 Networking: A Perspective from within a Service Provider 781 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 782 . 784 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 785 Connectivity Provisioning Profile (CPP)", RFC 7297, 786 DOI 10.17487/RFC7297, July 2014, 787 . 789 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 790 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 791 Defined Networking (SDN): Layers and Architecture 792 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 793 2015, . 795 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 796 Ceccarelli, D., and X. Zhang, "Problem Statement and 797 Architecture for Information Exchange between 798 Interconnected Traffic-Engineered Networks", BCP 206, 799 RFC 7926, DOI 10.17487/RFC7926, July 2016, 800 . 802 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 803 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 804 DOI 10.17487/RFC8453, August 2018, 805 . 807 [TAPI] "Functional Requirements for Transport API", June 2016. 809 Appendix A. Relationship with RFC7426 811 [RFC7426] introduces an SDN taxonomy by defining a number of planes, 812 abstraction layers, and interfaces or APIs among them, as a means of 813 clarifying how the different parts constituent of SDN (network 814 devices, control and management) relate among them. A number of 815 planes are defined, namely: 817 o Forwarding Plane: focused on delivering packets in the data path 818 based on the instructions received from the control plane. 820 o Operational Plane: centered on managing the operational state of 821 the network device. 823 o Control Plane: devoted to instruct the device on how packets 824 should be forwarded. 826 o Management Plane: in charge of monitoring and maintaining network 827 devices. 829 o Application Plane: enabling the usage for different purposes (as 830 determined by each application) of all the devices controlled in 831 this manner. 833 Apart from that, [RFC7426] proposes a number of abstraction layers 834 that permit the integration of the different planes through common 835 interfaces. CLAS focuses on Control, Management and Resource planes 836 as the basic pieces of its architecture. Essentially, the control 837 plane modifies the behavior and actions of the controlled resources. 838 The management plane monitors and retrieves the status of those 839 resources. And finally, the resource plane groups all the resources 840 related to the concerns of each strata. 842 From this point of view, CLAS planes can be seen as a superset of 843 [RFC7426], even though in some cases not all the planes as considered 844 in [RFC7426] could not be totally present in CLAS representation 845 (e.g., forwarding plane in Service Stratum). 847 Being said that, internal structure of CLAS strata could follow the 848 taxonomy defined in [RFC7426]. Which is differential is the 849 specialization of the SDN environments, through the distinction 850 between service and transport. 852 Authors' Addresses 854 Luis M. Contreras 855 Telefonica 856 Ronda de la Comunicacion, s/n 857 Sur-3 building, 3rd floor 858 Madrid 28050 859 Spain 861 Email: luismiguel.contrerasmurillo@telefonica.com 862 URI: http://lmcontreras.com 863 Carlos J. Bernardos 864 Universidad Carlos III de Madrid 865 Av. Universidad, 30 866 Leganes, Madrid 28911 867 Spain 869 Phone: +34 91624 6236 870 Email: cjbc@it.uc3m.es 871 URI: http://www.it.uc3m.es/cjbc/ 873 Diego R. Lopez 874 Telefonica 875 Ronda de la Comunicacion, s/n 876 Sur-3 building, 3rd floor 877 Madrid 28050 878 Spain 880 Email: diego.r.lopez@telefonica.com 882 Mohamed Boucadair 883 Orange 884 Rennes 35000 885 France 887 Email: mohamed.boucadair@orange.com 889 Paola Iovanna 890 Ericsson 891 Pisa 892 Italy 894 Email: paola.iovanna@ericsson.com