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