idnits 2.17.1 draft-irtf-sdnrg-layered-sdn-00.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 (March 18, 2016) is 2960 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-11 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDN Research Group LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Standards Track CJ. Bernardos 5 Expires: September 19, 2016 UC3M 6 D. Lopez 7 Telefonica 8 M. Boucadair 9 France Telecom 10 P. Iovanna 11 Ericsson 12 March 18, 2016 14 Cooperating Layered Architecture for SDN 15 draft-irtf-sdnrg-layered-sdn-00 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 http://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 September 19, 2016. 54 Copyright Notice 56 Copyright (c) 2016 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 (http://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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 103 10.2. Informative References . . . . . . . . . . . . . . . . . 13 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 106 1. Introduction 108 Software Defined Networking (SDN) proposes the separation of the 109 control plane from the data plane in the network nodes and its 110 logical centralization on a control entity. A programmatic interface 111 is defined between such entity and the network nodes, which 112 functionality is supposed to perform traffic forwarding (only). 113 Through that interface, the control entity instructs the nodes 114 involved in the forwarding plane and modifies their traffic 115 forwarding behavior accordingly. 117 Most of the intelligence is moved to such functional entity. 118 Typically, such entity is seen as a compendium of interacting control 119 functions in a vertical, tight integrated fashion. 121 This approach presents a number of issues: 123 o Unclear responsibilities between actors involved in a service 124 provision and delivery. 126 o Complex reuse of functions for the provision of services. 128 o Closed, monolithic control architectures. 130 o Difficult interoperability and interchangeability of functional 131 components. 133 o Blurred business boundaries among providers. 135 o Complex service/network diagnosis and troubleshooting, 136 particularly to determine which segment is responsible for a 137 failure. 139 The relocation of the control functions from a number of distributed 140 network nodes to another entity conceptually places together a number 141 of control capabilities with different purposes. As a consequence, 142 the existing solutions do not provide a clear separation between 143 services and transport control. 145 This document describes a proposal named Cooperating Layered 146 Architecture for SDN (CLAS). The idea behind that is to 147 differentiate the control functions associated to transport from 148 those related to services, in such a way that they can be provided 149 and maintained independently, and can follow their own evolution 150 path. 152 Despite such differentiation it is required a close cooperation 153 between service and transport layers and associated components to 154 provide an efficient usage of the resources. 156 2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC2119 [RFC2119]. 162 This document makes use of the following terms: 164 o Transport: denotes the transfer capabilities offered by a 165 networking infrastructure. The transfer capabilities can rely 166 upon pure IP techniques, or other means such as MPLS or optics. 168 o Service: denote a logical construct that make use of transport 169 capabilities. This document does not make any assumption on the 170 functional perimeter of a service that can be built above a 171 transport infrastructure. As such, a service can be an offering 172 that is offered to customers or be invoked for the delivery of 173 another (added-value) service. 175 o SDN intelligence: refers to the decision-making process that is 176 hosted by a node or a set of nodes. The intelligence can be 177 centralized or distributed. Both schemes are within the scope of 178 this document. The SDN intelligence relies on inputs form various 179 functional blocks such as: network topology discovery, service 180 topology discovery, resource allocation, business guidelines, 181 customer profiles, service profiles, etc. The exact decomposition 182 of an SDN intelligence, apart from the layering discussed in this 183 document, is out of scope. 185 Additionally, the following acronyms are used in this document. 187 CLAS: Cooperating Layered Architecture for SDN 189 FCAPS: Fault, Configuration, Accounting, Performance and Security 191 SDN: Software Defined Networking 192 SLA: Service Level Agreement 194 3. Architecture overview 196 Current operator networks support multiple services (e.g., VoIP, 197 IPTV, mobile VoIP, critical mission applications, etc.) on a variety 198 of transport technologies. The provision and delivery of a service 199 independently of the underlying transport capabilities requires a 200 separation of the service related functionalities and an abstraction 201 of the transport network to hide the specificities of underlying 202 transfer techniques while offering a common set of capabilities. 204 Such separation can provide configuration flexibility and 205 adaptability from the point of view of either the services or the 206 transport network. Multiple services can be provided on top of a 207 common transport infrastructure, and similarly, different 208 technologies can accommodate the connectivity requirements of a 209 certain service. A close coordination among them is required for a 210 consistent service delivery (inter-layer cooperation). 212 This document focuses particularly on: 214 o Means to expose transport capabilities to external services. 216 o Means to capture service requirements of services. 218 o Means to notify service intelligence with underlying transport 219 events, for example to adjust service decision-making process with 220 underlying transport events. 222 o Means to instruct the underlying transport capabilities to 223 accommodate new requirements, etc. 225 An example is to guarantee some Quality of Service (QoS) levels. 226 Different QoS-based offerings could be present at both service and 227 transport layers. Vertical mechanisms for linking both service and 228 transport QoS mechanisms should be in place to provide the quality 229 guarantees to the end user. 231 CLAS architecture assumes that the logically centralized control 232 functions are separated in two functional blocks or layers. One of 233 the functional blocks comprises the service-related functions, 234 whereas the other one contains the transport-related functions. The 235 cooperation between the two layers is considered to be implemented 236 through standard interfaces. 238 Figure 1 shows the CLAS architecture. It is based on functional 239 separation in the NGN architecture defined by the ITU-T in [Y.2011]. 241 Two strata of functionality are defined, namely the Service Stratum, 242 comprising the service-related functions, and the Transport Stratum, 243 covering the transport ones. The functions on each of these layers 244 are further grouped on control, management and user (or data) planes. 246 North Bound Interface 248 /\ 249 || 250 +-------------------------------------||-------------+ 251 | Service Stratum || | 252 | \/ | 253 | ........................... | 254 | . SDN Controller . | 255 | . . | 256 | +--------------+ . +--------------+ . | 257 | | Resource Pl. | . | Mngmt. Pl. | . | 258 | | |<===>. +--------------+ | . | 259 | | | . | Control Pl. | | . | 260 | +--------------+ . | |-----+ . | 261 | . | | . | 262 | . +--------------+ . | 263 | ........................... | 264 | /\ | 265 | || | 266 +-------------------------------------||-------------+ 267 || 268 || 269 || 270 +-------------------------------------||-------------+ 271 | Transport Stratum || | 272 | \/ | 273 | ........................... | 274 | . SDN Controller . | 275 | . . | 276 | +--------------+ . +--------------+ . | 277 | | Resource Pl. | . | Mngmt. Pl. | . | 278 | | |<===>. +--------------+ | . | 279 | | | . | Control Pl. | | . | 280 | +--------------+ . | |-----+ . | 281 | . | | . | 282 | . +--------------+ . | 283 | ........................... | 284 | | 285 | | 286 +----------------------------------------------------+ 288 Figure 1: Cooperating Layered Architecture for SDN 290 In the CLAS architecture both the control and management functions 291 are the ones logically centralized in one or a set of SDN 292 controllers, in such a way that separated SDN controllers are present 293 in the Service and Transport strata. Furthermore, the generic user 294 or data plane functions included in the NGN architecture are referred 295 here as resource plane functions. The resource plane in each stratum 296 is controlled by the corresponding SDN controller through a standard 297 interface. 299 The SDN controllers cooperate for the provision and delivery of 300 services. There is a hierarchy in which the Service SDN controller 301 requests transport capabilities to the Transport SDN controller. 302 Furthermore, the Transport SDN controller interacts with the Service 303 SDN controller to inform it about events in the transport network 304 that can motivate actions in the service layer. 306 The Service SDN controller acts as a client of the Transport SDN 307 controller. 309 Despite it is not shown in the figure, the Resource planes of each 310 stratum could be connected. This will depend on the kind of service 311 provided. Furthermore, the Service stratum could offer an interface 312 towards external applications to expose network service capabilities 313 to those applications or customers. 315 This document does assume that SDN techniques can be enabled jointly 316 with other distributed means (e.g., IGP). 318 3.1. Functional strata 320 As described before, the functional split separates transport-related 321 functions from service-related functions. Both strata cooperate for 322 a consistent service delivery. 324 Consistecy is determined and characterized by the service layer. 326 Communication between these two components could be implemented using 327 a variety of means (such as 328 [I-D.boucadair-connectivity-provisioning-protocol], Intermediate- 329 Controller Plane Interface (I-CPI) [ONFArch], etc). 331 3.1.1. Transport stratum 333 The Transport stratum comprises the functions focused on the transfer 334 of data between the communication end points (e.g., between end-user 335 devices, between two service gateways, etc.). The data forwarding 336 nodes are controlled and managed by the Transport SDN component. The 337 Control plane in the SDN controller is in charge of instructing the 338 forwarding devices to build the end to end data path for each 339 communication or to make sure forwarding service is appropriately 340 setup. Forwarding may not be rely on the sole pre-configured 341 entries; dynamic means can be enabled so that involved nodes can 342 build dynamically routing and forwarding paths. Finally, the 343 Management plane performs management functions (i.e., FCAPS) on those 344 devices, like fault or performance management, as part of the 345 Transport stratum capabilities. 347 3.1.2. Service stratum 349 The Service stratum contains the functions related to the provision 350 of services and the capabilities offered to external applications. 351 The Resource plane consists of the resources involved in the service 352 delivery, such as computing resources, registries, databases, etc. 353 The Control plane is in charge of controlling and configuring those 354 resources, as well as interacting with the Control plane of the 355 Transport stratum in client mode for requesting transport 356 capabilities for a given service. In the same way, the Management 357 plane implements management actions on the service-related resources 358 and interacts with the Management plane in the Transport stratum for 359 a cooperating management between layers. 361 3.1.3. Recursiveness 363 Recursive layering can happen in some usage scenarios in which the 364 Transport Stratum is itself structured in Service and Transport 365 Stratum. This could be the case of the provision of a transport 366 services complemented with advanced capabilities additional to the 367 pure data transport (e.g., maintenance of a given SLA [RFC7297]). 369 3.2. Plane separation 371 The CLAS architecture leverages on the SDN proposition of plane 372 separation. As mentioned before, three different planes are 373 considered for each stratum. The communication among these three 374 planes (and with the corresponding plane in other strata) is based on 375 open, standard interfaces. 377 3.2.1. Control Plane 379 The Control plane logically centralizes the control functions of each 380 stratum and directly controls the corresponding resources. [RFC7426] 381 introduces the role of the control plane in a SDN architecture. This 382 plane is part of an SDN controller, and can interact with other 383 control planes in the same or different strata for accomplishing 384 control functions. 386 3.2.2. Management Plane 388 The Management plane logically centralizes the management functions 389 for each stratum, including the management of the Control and 390 Resource planes. [RFC7426] describes the functions of the management 391 plane in a SDN environment. This plane is also part of the SDN 392 controller, and can interact with the corresponding management planes 393 residing in SDN controllers of the same or different strata. 395 3.2.3. Resource Plane 397 The Resource plane comprises the resources for either the transport 398 or the service functions. In some cases the service resources can be 399 connected to the transport ones (e.g., being the terminating points 400 of a transport function) whereas in other cases it can be decoupled 401 from the transport resources (e.g., one database keeping some 402 register for the end user). Both forwarding and operational planes 403 proposed in [RFC7426] would be part of the Resource plane in this 404 architecture. 406 4. Required features 408 A number of features are required to be supported by the CLAS 409 architecture. 411 o Abstraction: the mapping of physical resources into the 412 corresponding abstracted resources. 414 o Service parameter translation: translation of service parameters 415 (e.g., in the form of SLAs) to transport parameters (or 416 capabilities) according to different policies. 418 o Monitoring: mechanisms (e.g. event notifications) available in 419 order to dynamically update the (abstracted) resources' status 420 taking in to account e.g. the traffic load. 422 o Resource computation: functions able to decide which resources 423 will be used for a given service request. As an example, 424 functions like PCE could be used to compute/select/decide a 425 certain path. 427 o Orchestration: ability to combine diverse resources (e.g., IT and 428 network resources) in an optimal way. 430 o Accounting: record of resource usage. 432 o Security: secure communication among components, preventing e.g. 433 DoS attacks. 435 5. Communication between SDN Controllers 437 The SDN Controller residing respectively in the Service and the 438 Transport Stratum need to establish a tight coordination. Mechanisms 439 for transfer relevant information for each stratum should be defined. 441 From the Service perspective, the Service SDN controller needs to 442 easily access transport resources through well defined APIs to access 443 the capabilities offered by the Transport Stratum. There could be 444 different ways of obtainign such transport-aware information, i.e., 445 by discovering or publishing mechanisms. In the former case the 446 Service SDN Controller could be able of handling complete information 447 about the transport capabilities (including resources) offered by the 448 Transport Stratum. In the latter case, the Transport Stratum exposes 449 available capabilities e.g. through a catalog, reducing the amount of 450 detail of the underlying network. 452 On the other hand, the Transport Stratum requires to properly capture 453 Service requirements. These can include SLA requirements with 454 specific metrics (such as delay), level of protection to be provided, 455 max/min capacity, applicable resource constraints, etc. 457 The communication between controllers should be also secure, 458 preventing denial of service. 460 6. Deployment scenarios 462 Different situations can be found depending on the characteristics of 463 the networks involved in a given deployment. 465 6.1. Full SDN environments 467 This case considers the fact that the networks involved in the 468 provision and delivery of a given service have SDN capabilities. 470 6.1.1. Multiple Service strata associated to a single Transport stratum 472 A single Transport stratum can provide transfer functions to more 473 than one Service strata. The Transport stratum offers a standard 474 interface to each of the Service strata. The Service strata are the 475 clients of the Transport stratum. Some of the capabilities offered 476 by the Transport stratum can be isolation of the transport resources 477 (slicing), independent routing, etc. 479 6.1.2. Single service stratum associated to multiple Transport strata 481 A single Service stratum can make use of different Transport strata 482 for the provision of a certain service. The Service stratum 483 interfaces each of the Transport strata with standard protocols, and 484 orchestrates the provided transfer capabilities for building the end 485 to end transport needs. 487 6.2. Hybrid environments 489 This case considers scenarios where one of the strata is legacy 490 totally or in part. 492 6.2.1. SDN Service stratum associated to a legacy Transport stratum 494 An SDN service stratum can interact with a legacy Transport stratum 495 through some interworking function able to adapt SDN-based control 496 and management service-related commands to legacy transport-related 497 protocols, as expected by the legacy Transport stratum. The SDN 498 controller in the Service stratum is not aware of the legacy nature 499 of the underlying Transport stratum. 501 6.2.2. Legacy Service stratum associated to an SDN Transport stratum 503 A legacy Service stratum can work with an SDN-enabled Transport 504 stratum through the mediation of and interworking function capable to 505 interpret commands from the legacy service functions and translate 506 them into SDN protocols for operating with the SDN-enabled Transport 507 stratum. 509 6.3. Multi-domain scenarios in Transport Stratum 511 The Transport Stratum can be composed by transport resources being 512 part of different administrative, topological or technological 513 domains. The Service Stratum can yet interact with a single entity 514 in the Transport Stratum in case some abstraction capabilities are 515 provided in the transport part to emulate a single stratum. 517 Those abstraction capabilities constitute a service itself offered by 518 the Transport Stratum to the services making use of it. This service 519 is focused on the provision of transport capabilities, then different 520 of the final communication service using such capabilities. 522 In this particular case this recursion allows multi-domain scenarios 523 at transport level. 525 Multi-domain situations can happen in both single-operator and multi- 526 operator scenarios. Multi-operator scenarios will be addressed in 527 future versions of the document. 529 In single operator scenarios a multi-domain or end-to-end abstraction 530 component can provide an homogeneous abstract view of the underlying 531 heterogeneous transport capabilities for all the domains. 533 7. Use cases 535 This section presents a number of use cases as examples of 536 applicability of this proposal 538 7.1. Network Function Virtualization 540 To be completed 542 7.2. Abstraction and Control of Transport Networks 544 To be completed. 546 8. IANA Considerations 548 TBD. 550 9. Security Considerations 552 TBD. Security in the communication between strata to be addressed. 554 10. References 556 10.1. Normative References 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 560 RFC2119, March 1997, 561 . 563 [Y.2011] "General principles and general reference model for Next 564 Generation Networks", ITU-T Recommendation Y.2011 , 565 October 2004. 567 10.2. Informative References 569 [I-D.boucadair-connectivity-provisioning-protocol] 570 Boucadair, M., Jacquenet, C., Zhang, D., and P. 571 Georgatsos, "Connectivity Provisioning Negotiation 572 Protocol (CPNP)", draft-boucadair-connectivity- 573 provisioning-protocol-11 (work in progress), March 2016. 575 [ONFArch] Open Networking Foundation, "SDN Architecture, Issue 1", 576 June 2014, 577 . 581 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 582 Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 583 10.17487/RFC7297, July 2014, 584 . 586 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 587 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 588 Defined Networking (SDN): Layers and Architecture 589 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 590 2015, . 592 Authors' Addresses 594 Luis M. Contreras 595 Telefonica 596 Ronda de la Comunicacion, s/n 597 Sur-3 building, 3rd floor 598 Madrid 28050 599 Spain 601 Email: luismiguel.contrerasmurillo@telefonica.com 602 URI: http://people.tid.es/LuisM.Contreras/ 604 Carlos J. Bernardos 605 Universidad Carlos III de Madrid 606 Av. Universidad, 30 607 Leganes, Madrid 28911 608 Spain 610 Phone: +34 91624 6236 611 Email: cjbc@it.uc3m.es 612 URI: http://www.it.uc3m.es/cjbc/ 613 Diego R. Lopez 614 Telefonica 615 Ronda de la Comunicacion, s/n 616 Sur-3 building, 3rd floor 617 Madrid 28050 618 Spain 620 Email: diego.r.lopez@telefonica.com 622 Mohamed Boucadair 623 France Telecom 624 Rennes 35000 625 France 627 Email: mohamed.boucadair@orange.com 629 Paola Iovanna 630 Ericsson 631 Pisa 632 Italy 634 Email: paola.iovanna@ericsson.com