idnits 2.17.1 draft-contreras-layered-sdn-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2017) is 2369 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-14 == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-11 Summary: 0 errors (**), 0 flaws (~~), 4 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: May 3, 2018 UC3M 6 D. Lopez 7 Telefonica 8 M. Boucadair 9 Orange 10 P. Iovanna 11 Ericsson 12 October 30, 2017 14 Cooperating Layered Architecture for SDN 15 draft-contreras-layered-sdn-01 17 Abstract 19 Software Defined Networking proposes the separation of the control 20 plane from the data plane in the network nodes and its logical 21 centralization on a control entity. Most of the network intelligence 22 is moved to this functional entity. Typically, such entity is seen 23 as a compendium of interacting control functions in a vertical, tight 24 integrated fashion. The relocation of the control functions from a 25 number of distributed network nodes to a logical central entity 26 conceptually places together a number of control capabilities with 27 different purposes. As a consequence, the existing solutions do not 28 provide a clear separation between transport control and services 29 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 May 3, 2018. 54 Copyright Notice 56 Copyright (c) 2017 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. Connectivity 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 Connectivity stratum . . . . . . . . . . . . . . . . 11 88 6.1.2. Single service stratum associated to multiple 89 Connectivity strata . . . . . . . . . . . . . . . . . 12 90 6.2. Hybrid environments . . . . . . . . . . . . . . . . . . . 12 91 6.2.1. SDN Service stratum associated to a legacy 92 Connectivity stratum . . . . . . . . . . . . . . . . 12 93 6.2.2. Legacy Service stratum associated to an SDN 94 Connectivity stratum . . . . . . . . . . . . . . . . 12 95 6.3. Multi-domain scenarios in Connectivity 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 connectivity strata . . . . . . . . . . . . . . . . . . . . . 14 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 103 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 106 12.2. Informative References . . . . . . . . . . . . . . . . . 15 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 109 1. Introduction 111 Network softwarization advances are facilitating the introduction of 112 programmability in services and infrastructures of telco operators. 113 This is achieved generically through the introduction of Software 114 Defined Networking (SDN) capabilities in the network, including 115 controllers and orchestrators. 117 However, there are concerns of different nature that these SDN 118 capabilities have to resolve. In one hand there is a need for 119 actions focused on programming the network for handle the 120 connectivity or forwarding of digital data between distant nodes. On 121 the other hand, there is a need for actions devoted to program the 122 functions or services that process (or manipulate) such digital data. 124 Software Defined Networking (SDN) proposes the separation of the 125 control plane from the data plane in the network nodes and its 126 logical centralization on a control entity. A programmatic interface 127 is defined between such entity and the network nodes, which 128 functionality is supposed to perform traffic forwarding. Through 129 that interface, the control entity instructs the nodes involved in 130 the forwarding plane and modifies their traffic forwarding behavior 131 accordingly. 133 Most of the intelligence is moved to such functional entity. 134 Typically, such entity is seen as a compendium of interacting control 135 functions in a vertical, tight integrated fashion. 137 This approach presents a number of issues: 139 o Unclear responsibilities between actors involved in a service 140 provision and delivery. 142 o Complex reuse of functions for the provision of services. 144 o Closed, monolithic control architectures. 146 o Difficult interoperability and interchangeability of functional 147 components. 149 o Blurred business boundaries among providers. 151 o Complex service/network diagnosis and troubleshooting, 152 particularly to determine which segment is responsible for a 153 failure. 155 The relocation of the control functions from a number of distributed 156 network nodes to another entity conceptually places together a number 157 of control capabilities with different purposes. As a consequence, 158 the existing solutions do not provide a clear separation between 159 services and transport control. 161 This document describes a proposal named Cooperating Layered 162 Architecture for SDN (CLAS). The idea behind that is to 163 differentiate the control functions associated to transport from 164 those related to services, in such a way that they can be provided 165 and maintained independently, and can follow their own evolution 166 path. 168 Despite such differentiation it is required a close cooperation 169 between service and transport layers and associated components to 170 provide an efficient usage of the resources. 172 2. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC2119 [RFC2119]. 178 This document makes use of the following terms: 180 o Transport: denotes the transfer capabilities offered by a 181 networking infrastructure. The transfer capabilities can rely 182 upon pure IP techniques, or other means such as MPLS or optics. 184 o Service: denote a logical construct that make use of transport 185 capabilities. This document does not make any assumption on the 186 functional perimeter of a service that can be built above a 187 transport infrastructure. As such, a service can be an offering 188 that is offered to customers or be invoked for the delivery of 189 another (added-value) service. 191 o SDN intelligence: refers to the decision-making process that is 192 hosted by a node or a set of nodes. The intelligence can be 193 centralized or distributed. Both schemes are within the scope of 194 this document. The SDN intelligence relies on inputs form various 195 functional blocks such as: network topology discovery, service 196 topology discovery, resource allocation, business guidelines, 197 customer profiles, service profiles, etc. The exact decomposition 198 of an SDN intelligence, apart from the layering discussed in this 199 document, is out of scope. 201 Additionally, the following acronyms are used in this document. 203 CLAS: Cooperating Layered Architecture for SDN 205 FCAPS: Fault, Configuration, Accounting, Performance and Security 207 SDN: Software Defined Networking 209 SLA: Service Level Agreement 211 3. Architecture overview 213 Current operator networks support multiple services (e.g., VoIP, 214 IPTV, mobile VoIP, critical mission applications, etc.) on a variety 215 of transport technologies. The provision and delivery of a service 216 independently of the underlying transport capabilities requires a 217 separation of the service related functionalities and an abstraction 218 of the transport network to hide the specificities of underlying 219 transfer techniques while offering a common set of capabilities. 221 Such separation can provide configuration flexibility and 222 adaptability from the point of view of either the services or the 223 transport network. Multiple services can be provided on top of a 224 common transport infrastructure, and similarly, different 225 technologies can accommodate the connectivity requirements of a 226 certain service. A close coordination among them is required for a 227 consistent service delivery (inter-layer cooperation). 229 This document focuses particularly on: 231 o Means to expose transport capabilities to services. 233 o Means to capture service requirements of services. 235 o Means to notify service intelligence with underlying transport 236 events, for example to adjust service decision-making process with 237 underlying transport events. 239 o Means to instruct the underlying transport capabilities to 240 accommodate new requirements, etc. 242 An example is to guarantee some Quality of Service (QoS) levels. 243 Different QoS-based offerings could be present at both service and 244 transport layers. Vertical mechanisms for linking both service and 245 transport QoS mechanisms should be in place to provide the quality 246 guarantees to the end user. 248 CLAS architecture assumes that the logically centralized control 249 functions are separated in two functional layers. One of the 250 functional layers comprises the service-related functions, whereas 251 the other one contains the transport-related functions. The 252 cooperation between the two layers is considered to be implemented 253 through standard interfaces. 255 Figure 1 shows the CLAS architecture. It is based on functional 256 separation in the NGN architecture defined by the ITU-T in [Y.2011], 257 where two strata of functionality are defined, namely the Service 258 Stratum, comprising the service-related functions, and the 259 Connectivity Stratum, covering the transport ones. The functions on 260 each of these layers are further grouped on control, management and 261 user (or data) planes. 263 CLAS adopts the same structured model described in [Y.2011] but 264 applying it to the objectives of programmability through SDN. To 265 this respect, CLAS proposes to address services and connectivity in a 266 separated manner because of their differentiated concerns. 268 Applications 269 /\ 270 || 271 || 272 +-------------------------------------||-------------+ 273 | Service Stratum || | 274 | \/ | 275 | ........................... | 276 | . SDN Controller . | 277 | . . | 278 | +--------------+ . +--------------+ . | 279 | | Resource Pl. | . | Mngmt. Pl. | . | 280 | | |<===>. +--------------+ | . | 281 | | | . | Control Pl. | | . | 282 | +--------------+ . | |-----+ . | 283 | . | | . | 284 | . +--------------+ . | 285 | ........................... | 286 | /\ | 287 | || | 288 +-------------------------------------||-------------+ 289 || Standard 290 -- || -- API 291 || 292 +-------------------------------------||-------------+ 293 | Transport Stratum || | 294 | \/ | 295 | ........................... | 296 | . SDN Controller . | 297 | . . | 298 | +--------------+ . +--------------+ . | 299 | | Resource Pl. | . | Mngmt. Pl. | . | 300 | | |<===>. +--------------+ | . | 301 | | | . | Control Pl. | | . | 302 | +--------------+ . | |-----+ . | 303 | . | | . | 304 | . +--------------+ . | 305 | ........................... | 306 | | 307 | | 308 +----------------------------------------------------+ 310 Figure 1: Cooperating Layered Architecture for SDN 312 In the CLAS architecture both the control and management functions 313 are the ones logically centralized in one or a set of SDN 314 controllers, in such a way that separated SDN controllers are present 315 in the Service and Connectivity strata. Furthermore, the generic 316 user or data plane functions included in the NGN architecture are 317 referred here as resource plane functions. The resource plane in 318 each stratum is controlled by the corresponding SDN controller 319 through a standard interface. 321 The SDN controllers cooperate for the provision and delivery of 322 services. There is a hierarchy in which the Service SDN controller 323 requests transport capabilities to the Transport SDN controller. 324 Furthermore, the Transport SDN controller interacts with the Service 325 SDN controller to inform it about events in the transport network 326 that can motivate actions in the service layer. 328 The Service SDN controller acts as a client of the Transport SDN 329 controller. 331 Despite it is not shown in the figure, the Resource planes of each 332 stratum could be connected. This will depend on the kind of service 333 provided. Furthermore, the Service stratum could offer an interface 334 towards applications to expose network service capabilities to those 335 applications or customers. 337 3.1. Functional strata 339 As described before, the functional split separates transport-related 340 functions from service-related functions. Both strata cooperate for 341 a consistent service delivery. 343 Consistecy is determined and characterized by the service layer. 345 Communication between these two components could be implemented using 346 a variety of means (such as 347 [I-D.boucadair-connectivity-provisioning-protocol], Intermediate- 348 Controller Plane Interface (I-CPI) [ONFArch], etc). 350 3.1.1. Connectivity stratum 352 The Connectivity stratum comprises the functions focused on the 353 transfer of data between the communication end points (e.g., between 354 end-user devices, between two service gateways, etc.). The data 355 forwarding nodes are controlled and managed by the Transport SDN 356 component. The Control plane in the SDN controller is in charge of 357 instructing the forwarding devices to build the end to end data path 358 for each communication or to make sure forwarding service is 359 appropriately setup. Forwarding may not be rely on the sole pre- 360 configured entries; dynamic means can be enabled so that involved 361 nodes can build dynamically routing and forwarding paths. Finally, 362 the Management plane performs management functions (i.e., FCAPS) on 363 those devices, like fault or performance management, as part of the 364 Connectivity stratum capabilities. 366 3.1.2. Service stratum 368 The Service stratum contains the functions related to the provision 369 of services and the capabilities offered to external applications. 370 The Resource plane consists of the resources involved in the service 371 delivery, such as computing resources, registries, databases, etc. 372 The Control plane is in charge of controlling and configuring those 373 resources, as well as interacting with the Control plane of the 374 Transport stratum in client mode for requesting transport 375 capabilities for a given service. In the same way, the Management 376 plane implements management actions on the service-related resources 377 and interacts with the Management plane in the Connectivity stratum 378 for a cooperating management between layers. 380 3.1.3. Recursiveness 382 Recursive layering can happen in some usage scenarios in which the 383 Connectivity Stratum is itself structured in Service and Connectivity 384 Stratum. This could be the case of the provision of a transport 385 services complemented with advanced capabilities additional to the 386 pure data transport (e.g., maintenance of a given SLA [RFC7297]). 388 Recursiveness has been also discussed in [ONFArch] as a manner of a 389 way of reaching scalability and modularity, when each higher level 390 can provide greater abstraction capabilities. Additionally, 391 recursiveness can allow some scenarios for multi-domain where single 392 or multiple administrative domains are involved, as the ones 393 described in section 6.3. 395 3.2. Plane separation 397 The CLAS architecture leverages on the SDN proposition of plane 398 separation. As mentioned before, three different planes are 399 considered for each stratum. The communication among these three 400 planes (and with the corresponding plane in other strata) is based on 401 open, standard interfaces. 403 3.2.1. Control Plane 405 The Control plane logically centralizes the control functions of each 406 stratum and directly controls the corresponding resources. [RFC7426] 407 introduces the role of the control plane in a SDN architecture. This 408 plane is part of an SDN controller, and can interact with other 409 control planes in the same or different strata for accomplishing 410 control functions. 412 3.2.2. Management Plane 414 The Management plane logically centralizes the management functions 415 for each stratum, including the management of the Control and 416 Resource planes. [RFC7426] describes the functions of the management 417 plane in a SDN environment. This plane is also part of the SDN 418 controller, and can interact with the corresponding management planes 419 residing in SDN controllers of the same or different strata. 421 3.2.3. Resource Plane 423 The Resource plane comprises the resources for either the transport 424 or the service functions. In some cases the service resources can be 425 connected to the transport ones (e.g., being the terminating points 426 of a transport function) whereas in other cases it can be decoupled 427 from the transport resources (e.g., one database keeping some 428 register for the end user). Both forwarding and operational planes 429 proposed in [RFC7426] would be part of the Resource plane in this 430 architecture. 432 4. Required features 434 A number of features are required to be supported by the CLAS 435 architecture. 437 o Abstraction: the mapping of physical resources into the 438 corresponding abstracted resources. 440 o Service parameter translation: translation of service parameters 441 (e.g., in the form of SLAs) to transport parameters (or 442 capabilities) according to different policies. 444 o Monitoring: mechanisms (e.g. event notifications) available in 445 order to dynamically update the (abstracted) resources' status 446 taking in to account e.g. the traffic load. 448 o Resource computation: functions able to decide which resources 449 will be used for a given service request. As an example, 450 functions like PCE could be used to compute/select/decide a 451 certain path. 453 o Orchestration: ability to combine diverse resources (e.g., IT and 454 network resources) in an optimal way. 456 o Accounting: record of resource usage. 458 o Security: secure communication among components, preventing e.g. 459 DoS attacks. 461 5. Communication between SDN Controllers 463 The SDN Controller residing respectively in the Service and the 464 Connectivity Stratum need to establish a tight coordination. 465 Mechanisms for transfer relevant information for each stratum should 466 be defined. 468 From the Service perspective, the Service SDN controller needs to 469 easily access transport resources through well defined APIs to access 470 the capabilities offered by the Connectivity Stratum. There could be 471 different ways of obtainign such transport-aware information, i.e., 472 by discovering or publishing mechanisms. In the former case the 473 Service SDN Controller could be able of handling complete information 474 about the transport capabilities (including resources) offered by the 475 Connectivity Stratum. In the latter case, the Connectivity Stratum 476 exposes available capabilities e.g. through a catalog, reducing the 477 amount of detail of the underlying network. 479 On the other hand, the Connectivity Stratum requires to properly 480 capture Service requirements. These can include SLA requirements 481 with specific metrics (such as delay), level of protection to be 482 provided, max/min capacity, applicable resource constraints, etc. 484 The communication between controllers should be also secure, e.g. by 485 preventing denial of service or any other kind of threats. 487 6. Deployment scenarios 489 Different situations can be found depending on the characteristics of 490 the networks involved in a given deployment. 492 6.1. Full SDN environments 494 This case considers the fact that the networks involved in the 495 provision and delivery of a given service have SDN capabilities. 497 6.1.1. Multiple Service strata associated to a single Connectivity 498 stratum 500 A single Connectivity stratum can provide transfer functions to more 501 than one Service strata. The Connectivity stratum offers a standard 502 interface to each of the Service strata. The Service strata are the 503 clients of the Connectivity stratum. Some of the capabilities 504 offered by the Connectivity stratum can be isolation of the transport 505 resources (slicing), independent routing, etc. 507 6.1.2. Single service stratum associated to multiple Connectivity 508 strata 510 A single Service stratum can make use of different Connectivity 511 strata for the provision of a certain service. The Service stratum 512 interfaces each of the Connectivity strata with standard protocols, 513 and orchestrates the provided transfer capabilities for building the 514 end to end transport needs. 516 6.2. Hybrid environments 518 This case considers scenarios where one of the strata is legacy 519 totally or in part. 521 6.2.1. SDN Service stratum associated to a legacy Connectivity stratum 523 An SDN service stratum can interact with a legacy Connectivity 524 stratum through some interworking function able to adapt SDN-based 525 control and management service-related commands to legacy transport- 526 related protocols, as expected by the legacy Connectivity stratum. 527 The SDN controller in the Service stratum is not aware of the legacy 528 nature of the underlying Connectivity stratum. 530 6.2.2. Legacy Service stratum associated to an SDN Connectivity stratum 532 A legacy Service stratum can work with an SDN-enabled Connectivity 533 stratum through the mediation of and interworking function capable to 534 interpret commands from the legacy service functions and translate 535 them into SDN protocols for operating with the SDN-enabled 536 Connectivity stratum. 538 6.3. Multi-domain scenarios in Connectivity Stratum 540 The Connectivity Stratum can be composed by transport resources being 541 part of different administrative, topological or technological 542 domains. The Service Stratum can yet interact with a single entity 543 in the Connectivity Stratum in case some abstraction capabilities are 544 provided in the transport part to emulate a single stratum. 546 Those abstraction capabilities constitute a service itself offered by 547 the Connectivity Stratum to the services making use of it. This 548 service is focused on the provision of transport capabilities, then 549 different of the final communication service using such capabilities. 551 In this particular case this recursion allows multi-domain scenarios 552 at transport level. 554 Multi-domain situations can happen in both single-operator and multi- 555 operator scenarios. 557 In single operator scenarios a multi-domain or end-to-end abstraction 558 component can provide an homogeneous abstract view of the underlying 559 heterogeneous transport capabilities for all the domains. 561 Multi-operator scenarios, at the connectivity stratum, should support 562 the establishment of end-to-end paths in a programmatic manner across 563 the involved networks. This can be accomplished by the exchange of 564 traffic-engineered information of each of the administrative domains 565 [RFC7926]. 567 7. Use cases 569 This section presents a number of use cases as examples of 570 applicability of this proposal 572 7.1. Network Function Virtualization 574 NFV environments offer two possible levels of SDN control 575 [ETSI_NFV_EVE005]. One level is the need for controlling the NFVI to 576 provide connectivity end-to- end among VNFs (Virtual Network 577 Functions) or among VNFs and PNFs (Physical Network Functions). A 578 second level is the control and configuration of the VNFs themselves 579 (in other words, the configuration of the network service implemented 580 by those VNFs), taking profit of the programmability brought by SDN. 581 Both control concerns are separated in nature. However, interaction 582 between both could be expected in order to optimize, scale or 583 influence each other. 585 7.2. Abstraction and Control of Transport Networks 587 Abstraction and Control of Transport Networks (ACTN) 588 [I-D.ietf-teas-actn-framework] presents a framework to allow the 589 creation of virtual networks to be offered to customers. The concept 590 of provider in ACTN is limited to the offering of virtual network 591 services. These services are essentially transport services, and 592 would correspond to the Connectivity Stratum in CLAS. On the other 593 hand, the Service Stratum in CLAS can be assimilated as a customer in 594 the context of ACTN. 596 ACTN propose a hierarchy of controllers for facilitating the creation 597 and operation of the virtual networks. An interface is proposed for 598 the relation of the customers requesting these virtual networks 599 services with the controller in charge of orchestrating and serving 600 such request. Such interface is equivalent to the one defined in 601 Figure 1 of this document between Service and Connectivity Strata. 603 8. Challenges for implementing actions between service and connectivity 604 strata 606 The distinction of service and connectivity concerns raise a number 607 of challenges in the communication between both strata. The 608 following is a work-in-progress list reflecting some of the 609 identified challenges: 611 o Standard mechanisms for interaction between layers. Nowadays 612 there are a number of proposals that could accommodate requests 613 from the service stratum to the transport stratum. Some of them 614 were refered before like the Connectivity Provisioning Protocol 615 [I-D.boucadair-connectivity-provisioning-protocol] or the 616 Intermediate-Controller Plane Interface (I-CPI) [ONFArch]. Other 617 potential candidates could be the Transport API [TAPI] or the 618 Transport NBI [I-D.tnbidt-ccamp-transport-nbi-use-cases]. Each of 619 these options has a different status of maturity and scope. 621 o Multi-provider awareness. In multi-domain scenarios involving 622 more than one provider at connectivity level, the service stratum 623 could have or not awareness of such multiplicity of domains. If 624 the service stratum is unaware of the multi-domain situation, then 625 the connectivity stratum acting as entry point of the service 626 stratum request should be responsible of managing the multi-domain 627 issue. On the contrary, if the service stratum is aware of the 628 multi-domain situation, it should be in charge of orchestrating 629 the requests to the different underlying connectivity strata for 630 composing the final end-to-end path among service end-points 631 (i.e., functions). 633 o SLA mapping. Both strata will handle SLAs but the nature of those 634 SLAs could differ. Then it is required for the entities in each 635 stratum to map service SLAs to connectivity SLAs in order to 636 ensure proper service delivery. 638 o Association between strata. The association between strata could 639 be configured beforehand, or could be dynamic following mechanisms 640 of discovery, that could be required to be supported by both 641 strata with this purpose. 643 o Security. As reflected before, the communication between strata 644 must be secure preventing attacks and threats. Additionally, 645 privacy should be enforced, especially when addressing multi- 646 provider scenarios at connectivity level. 648 o Accounting. The control and accountancy of resources used and 649 consumed by services should be supported in the communication 650 among strata. 652 9. IANA Considerations 654 No IANA action is requested 656 10. Security Considerations 658 This is an informational document, which therefore does not introduce 659 any additional security threat. 661 Security in the communication between the strata here described 662 should apply on the APIs (and/or protocols) to be defined among them. 663 In consequence, security concerns will correspond to the specific 664 solution. 666 11. Acknowledgements 668 This document was previously discussed and adopted in the IRTF SDN RG 669 as [I-D.irtf-sdnrg-layered-sdn]. After the closure of the IRTF SDN 670 RG this document is being progressed as Individual Submission to 671 record (some of) that group's disucussions. 673 The authors would like to thank (in alphabetical order) Bartosz 674 Belter, Gino Carrozzo, Ramon Casellas, Gert Grammel, Ali Haider, 675 Evangelos Haleplidis, Zheng Haomian, Gabriel Lopez, Maria Rita 676 Palatella, Christian Esteve Rothenberg and Jacek Wytrebowicz for 677 their comments and suggestions. 679 12. References 681 12.1. Normative References 683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 684 Requirement Levels", BCP 14, RFC 2119, 685 DOI 10.17487/RFC2119, March 1997, 686 . 688 [Y.2011] "General principles and general reference model for Next 689 Generation Networks", ITU-T Recommendation Y.2011 , 690 October 2004. 692 12.2. Informative References 694 [ETSI_NFV_EVE005] 695 "Report on SDN Usage in NFV Architectural Framework", 696 December 2015. 698 [I-D.boucadair-connectivity-provisioning-protocol] 699 Boucadair, M., Jacquenet, C., Zhang, D., and P. 700 Georgatsos, "Connectivity Provisioning Negotiation 701 Protocol (CPNP)", draft-boucadair-connectivity- 702 provisioning-protocol-14 (work in progress), May 2017. 704 [I-D.ietf-teas-actn-framework] 705 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 706 Control of Traffic Engineered Networks", draft-ietf-teas- 707 actn-framework-11 (work in progress), October 2017. 709 [I-D.irtf-sdnrg-layered-sdn] 710 Contreras, L., Bernardos, C., Lopez, D., Boucadair, M., 711 and P. Iovanna, "Cooperating Layered Architecture for 712 SDN", draft-irtf-sdnrg-layered-sdn-01 (work in progress), 713 October 2016. 715 [I-D.tnbidt-ccamp-transport-nbi-use-cases] 716 Busi, I. and D. King, "Transport Northbound Interface 717 Applicability Statement and Use Cases", draft-tnbidt- 718 ccamp-transport-nbi-use-cases-03 (work in progress), 719 September 2017. 721 [ONFArch] Open Networking Foundation, "SDN Architecture, Issue 1", 722 June 2014, 723 . 727 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 728 Connectivity Provisioning Profile (CPP)", RFC 7297, 729 DOI 10.17487/RFC7297, July 2014, 730 . 732 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 733 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 734 Defined Networking (SDN): Layers and Architecture 735 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 736 2015, . 738 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 739 Ceccarelli, D., and X. Zhang, "Problem Statement and 740 Architecture for Information Exchange between 741 Interconnected Traffic-Engineered Networks", BCP 206, 742 RFC 7926, DOI 10.17487/RFC7926, July 2016, 743 . 745 [TAPI] "Functional Requirements for Transport API", June 2016. 747 Authors' Addresses 749 Luis M. Contreras 750 Telefonica 751 Ronda de la Comunicacion, s/n 752 Sur-3 building, 3rd floor 753 Madrid 28050 754 Spain 756 Email: luismiguel.contrerasmurillo@telefonica.com 757 URI: http://lmcontreras.com 759 Carlos J. Bernardos 760 Universidad Carlos III de Madrid 761 Av. Universidad, 30 762 Leganes, Madrid 28911 763 Spain 765 Phone: +34 91624 6236 766 Email: cjbc@it.uc3m.es 767 URI: http://www.it.uc3m.es/cjbc/ 769 Diego R. Lopez 770 Telefonica 771 Ronda de la Comunicacion, s/n 772 Sur-3 building, 3rd floor 773 Madrid 28050 774 Spain 776 Email: diego.r.lopez@telefonica.com 778 Mohamed Boucadair 779 Orange 780 Rennes 35000 781 France 783 Email: mohamed.boucadair@orange.com 785 Paola Iovanna 786 Ericsson 787 Pisa 788 Italy 790 Email: paola.iovanna@ericsson.com