| Network Working Group | LM. Contreras |
| Internet-Draft | Telefonica |
| Intended status: Informational | CJ. Bernardos |
| Expires: May 25, 2019 | UC3M |
| D. Lopez | |
| Telefonica | |
| M. Boucadair | |
| Orange | |
| P. Iovanna | |
| Ericsson | |
| November 21, 2018 |
Cooperating Layered Architecture for Software Defined Networking (CLAS)
draft-contreras-layered-sdn-03
Software Defined Networking adheres to the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or sevice intelligence is moved to these control entities. Typically, such entity is seen as a compendium of interacting control functions in a vertical, tight integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that relies upon transport capabilities.
This document describes an approach named Cooperating Layered Architecture for Software Defined Networking. The idea behind that is to differentiate the control functions associated to transport from those related to services, in such a way that they can be provided and maintained independently, and can follow their own evolution path.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 25, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Network softwarization advances are facilitating the introduction of programmability in services and infrastructures of telco operators. This is achieved generically through the introduction of Software Defined Networking (SDN, [RFC7149][RFC7426]) capabilities in the network, including controllers and orchestrators.
However, there are concerns of different nature that these SDN capabilities have to resolve. In one hand there is a need for actions focused on programming the network for handle the connectivity or forwarding of digital data between distant nodes. On the other hand, there is a need for actions devoted to program the functions or services that process (or manipulate) such digital data.
SDN adheres to the separation of the control plane from the data plane in the network nodes by introducing abstraction among both planes, allowing to centralize the control logic on a functional entity which is commonly referred as SDN Controller; one or multiple controllers may be deployed. A programmatic interface is then defined between a forwarding entity (at the network node) and a control entity. Through that interface, a control entity instructs the nodes involved in the forwarding plane and modifies their traffic forwarding behavior accordingly. Additional capabilities (e.g., performance monitoring, fault management, etc.) could be expected to be supported through such kind of programmatic interface [RFC7149].
Most of the intelligence is moved to such functional entity. Typically, such entity is seen as a compendium of interacting control functions in a vertical, tight integrated fashion.
The approach of considering an omnipotent control entity governing the overall aspects of a network, especially both the transport network and the services to be supported on top of it, presents a number of issues:
The relocation of the control functions from a number of distributed network nodes to another entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing SDN solutions do not provide a clear separation between services and transport control. Here, the separation between service and transport follows the distinction provided by [Y.2011], and also defined in Section 2 of this document.
This document describes an approach named Cooperating Layered Architecture for SDN (CLAS). The idea behind that is to differentiate the control functions associated to transport from those related to services, in such a way that they can be provided and maintained independently, and can follow their own evolution path.
Despite such differentiation it is required a close cooperation between service and transport layers (or strata in [Y.2011]) and associated components to provide an efficient usage of the resources.
This document makes use of the following terms:
Additionally, the following acronyms are used in this document:
Current operator networks support multiple services (e.g., VoIP, IPTV, mobile VoIP, critical mission applications, etc.) on a variety of transport technologies. The provision and delivery of a service independently of the underlying transport capabilities require a separation of the service related functionalities and an abstraction of the transport network to hide the specificities of underlying transfer techniques while offering a common set of capabilities.
Such separation can provide configuration flexibility and adaptability from the point of view of either the services or the transport network. Multiple services can be provided on top of a common transport infrastructure, and similarly, different technologies can accommodate the connectivity requirements of a certain service. A close coordination among them is required for a consistent service delivery (inter-layer cooperation).
This document focuses particularly on:
An example is to guarantee some Quality of Service (QoS) levels. Different QoS-based offerings could be present at both service and transport layers. Vertical mechanisms for linking both service and transport QoS mechanisms should be in place to provide the quality guarantees to the end user.
CLAS architecture assumes that the logically centralized control functions are separated in two functional layers. One of the functional layers comprises the service-related functions, whereas the other one contains the transport-related functions. The cooperation between the two layers is expected to be implemented through standard interfaces.
Figure 1 shows the CLAS architecture. It is based on functional separation in the NGN architecture defined by the ITU-T in [Y.2011], where two strata of functionality are defined, namely the Service Stratum, comprising the service-related functions, and the Connectivity Stratum, covering the transport ones. The functions on each of these layers are further grouped on control, management and user (or data) planes.
CLAS adopts the same structured model described in [Y.2011] but applying it to the objectives of programmability through SDN [RFC7149]. To this respect, CLAS advocates for addressing services and transport in a separated manner because of their differentiated concerns.
Applications
/\
||
||
+-------------------------------------||-------------+
| Service Stratum || |
| \/ |
| ........................... |
| . SDN Intelligence . |
| . . |
| +--------------+ . +--------------+ . |
| | Resource Pl. | . | Mngmt. Pl. | . |
| | |<===>. +--------------+ | . |
| | | . | Control Pl. | | . |
| +--------------+ . | |-----+ . |
| . | | . |
| . +--------------+ . |
| ........................... |
| /\ |
| || |
+-------------------------------------||-------------+
|| Standard
-- || -- API
||
+-------------------------------------||-------------+
| Transport Stratum || |
| \/ |
| ........................... |
| . SDN Intelligence . |
| . . |
| +--------------+ . +--------------+ . |
| | Resource Pl. | . | Mngmt. Pl. | . |
| | |<===>. +--------------+ | . |
| | | . | Control Pl. | | . |
| +--------------+ . | |-----+ . |
| . | | . |
| . +--------------+ . |
| ........................... |
| |
| |
+----------------------------------------------------+
Figure 1: Cooperating Layered Architecture for SDN
In the CLAS architecture both the control and management functions are considered to be performed by one or a set of SDN controllers (due to, e.g., scalability, reliability) providing the SDN Intelligence, in such a way that separated SDN controllers are present in the Service and Transport strata. Management functions are considered to be part of the SDN Intelligence to allow the effective operation in a service provider ecosystem [RFC7149] despite some initial propositions did not consider such management as part of the SDN environment [ONFArch].
Furthermore, the generic user or data plane functions included in the NGN architecture are referred here as resource plane functions. The resource plane in each stratum is controlled by the corresponding SDN Intelligence through a standard interface.
The SDN controllers cooperate for the provision and delivery of services. There is a hierarchy in which the Service SDN Intelligence requests transport capabilities to the Transport SDN Intelligence.
The Service SDN Intelligence acts as a client of the Transport SDN Intelligence.
Furthermore, the Transport SDN Intelligence interacts with the Service SDN Intelligence to inform it about events in the transport network that can motivate actions in the service layer.
Despite it is not shown in Figure 1, the resource planes of each stratum could be connected. This will depend on the kind of service provided. Furthermore, the Service stratum could offer an interface towards applications to expose network service capabilities to those applications or customers.
As described before, the functional split separates transport-related functions from service-related functions. Both strata cooperate for a consistent service delivery.
Consistency is determined and characterized by the service layer.
The Transport Stratum comprises the functions focused on the transfer of data between the communication end points (e.g., between end-user devices, between two service gateways, etc.). The data forwarding nodes are controlled and managed by the Transport SDN component.
The Control plane in the SDN Intelligence is in charge of instructing the forwarding devices to build the end to end data path for each communication or to make sure forwarding service is appropriately setup. Forwarding may not be rely on the sole pre-configured entries; dynamic means can be enabled so that involved nodes can build dynamically routing and forwarding paths (this would require that the nodes retain some of the control and management capabilities for enabling this). Finally, the Management plane performs management functions (i.e., FCAPS) on those devices, like fault or performance management, as part of the Transport Stratum capabilities.
The Service stratum contains the functions related to the provision of services and the capabilities offered to external applications. The Resource plane consists of the resources involved in the service delivery, such as computing resources, registries, databases, etc.
The Control plane is in charge of controlling and configuring those resources, as well as interacting with the Control plane of the Transport stratum in client mode for requesting transport capabilities for a given service. In the same way, the Management plane implements management actions on the service-related resources and interacts with the Management plane in the Transport Stratum for a cooperating management between layers.
Recursive layering can happen in some usage scenarios in which the Transport Stratum is itself structured in Service and Transport Stratum. This could be the case of the provision of a transport service complemented with advanced capabilities additional to the pure data transport (e.g., maintenance of a given SLA [RFC7297]).
Recursiveness has been also discussed in [ONFArch] as a way of reaching scalability and modularity, when each higher level can provide greater abstraction capabilities. Additionally, recursiveness can allow some scenarios for multi-domain where single or multiple administrative domains are involved, as the ones described in Section 6.3.
The CLAS architecture leverages on plane separation. As mentioned before, three different planes are considered for each stratum. The communication among these three planes (and with the corresponding plane in other strata) is based on open, standard interfaces.
The Control plane logically centralizes the control functions of each stratum and directly controls the corresponding resources. [RFC7426] introduces the role of the control plane in a SDN architecture. This plane is part of an SDN Intelligence, and can interact with other control planes in the same or different strata for accomplishing control functions.
The Management plane logically centralizes the management functions for each stratum, including the management of the Control and Resource planes. [RFC7426] describes the functions of the management plane in a SDN environment. This plane is also part of the SDN Intelligence, and can interact with the corresponding management planes residing in SDN controllers of the same or different strata.
The Resource plane comprises the resources for either the transport or the service functions. In some cases the service resources can be connected to the transport ones (e.g., being the terminating points of a transport function) whereas in other cases it can be decoupled from the transport resources (e.g., one database keeping some register for the end user). Both forwarding and operational planes proposed in [RFC7426] would be part of the Resource plane in this architecture.
Since the CLAS architecture implies the interaction of different layers with different purposes and responsibilities, a number of features are required to be supported:
The SDN controllers residing respectively in the Service and the Transport Stratum need to establish a tight coordination. Mechanisms for transfer relevant information for each stratum should be defined.
From the service perspective, the Service SDN Intelligence needs to easily access transport resources through well-defined APIs to retrieve the capabilities offered by the Transport Stratum. There could be different ways of obtaining such transport-aware information, i.e., by discovering or publishing mechanisms. In the former case the Service SDN Intelligence could be able of handling complete information about the transport capabilities (including resources) offered by the Transport Stratum. In the latter case, the Transport Stratum exposes available capabilities, e.g., through a catalog, reducing the amount of detail of the underlying network.
On the other hand, the Transport Stratum requires to properly capture Service requirements. These can include SLA requirements with specific metrics (such as delay), level of protection to be provided, max/min capacity, applicable resource constraints, etc.
The communication between controllers must be also secure, e.g., by preventing denial of service or any other kind of threats (similarly, the communications with the network nodes must be secure).
Different situations can be found depending on the characteristics of the networks involved in a given deployment.
This case considers that the networks involved in the provision and delivery of a given service have SDN capabilities.
A single Transport Stratum can provide transfer functions to more than one Service strata. The Transport Stratum offers a standard interface(s) to each of the Service strata. The Service strata are the clients of the Transport Stratum. Some of the capabilities offered by the Transport stratum can be isolation of the transport resources (slicing), independent routing, etc.
A single Service stratum can make use of different Transport Strata for the provision of a certain service. The Service stratum interfaces each of the Transport Strata with standard protocols, and orchestrates the provided transfer capabilities for building the end to end transport needs.
This case considers scenarios where one of the strata is legacy totally or in part.
An SDN service stratum can interact with a legacy Transport Stratum through some interworking function able to adapt SDN-based control and management service-related commands to legacy transport-related protocols, as expected by the legacy Transport Stratum.
The SDN Intelligence in the Service stratum is not aware of the legacy nature of the underlying Transport Stratum.
A legacy Service stratum can work with an SDN-enabled Transport Stratum through the mediation of and interworking function capable to interpret commands from the legacy service functions and translate them into SDN protocols for operating with the SDN-enabled Transport Stratum.
The Transport Stratum can be composed by transport resources being part of different administrative, topological or technological domains. The Service Stratum can yet interact with a single entity in the Transport Stratum in case some abstraction capabilities are provided in the transport part to emulate a single stratum.
Those abstraction capabilities constitute a service itself offered by the Transport Stratum to the services making use of it. This service is focused on the provision of transport capabilities, then different of the final communication service using such capabilities.
In this particular case this recursion allows multi-domain scenarios at transport level.
Multi-domain situations can happen in both single-operator and multi-operator scenarios.
In single operator scenarios a multi-domain or end-to-end abstraction component can provide an homogeneous abstract view of the underlying heterogeneous transport capabilities for all the domains.
Multi-operator scenarios, at the Transport Stratum, should support the establishment of end-to-end paths in a programmatic manner across the involved networks. This could be accomplished, for example, by the exchange of traffic-engineered information of each of the administrative domains [RFC7926].
This section presents a number of use cases as examples of applicability of the CLAS approach.
NFV environments offer two possible levels of SDN control [ETSI_NFV_EVE005]. One level is the need for controlling the NFV Infrastructure (NFVI) to provide connectivity end-to- end among VNFs (Virtual Network Functions) or among VNFs and PNFs (Physical Network Functions). A second level is the control and configuration of the VNFs themselves (in other words, the configuration of the network service implemented by those VNFs), taking profit of the programmability brought by SDN. Both control concerns are separated in nature. However, interaction between both could be expected in order to optimize, scale or influence each other.
Abstraction and Control of Transport Networks (ACTN) [RFC8453] presents a framework to allow the creation of virtual networks to be offered to customers. The concept of provider in ACTN is limited to the offering of virtual network services. These services are essentially transport services, and would correspond to the Transport Stratum in CLAS. On the other hand, the Service Stratum in CLAS can be assimilated as a customer in the context of ACTN.
ACTN defines a hierarchy of controllers for facilitating the creation and operation of the virtual networks. An interface is defined for the relation of the customers requesting these virtual networks services with the controller in charge of orchestrating and serving such request. Such interface is equivalent to the one defined in Figure 1 (Section 3) between Service and Transport Strata.
The distinction of service and transport concerns raises a number of challenges in the communication between both strata. The following is a work-in-progress list reflecting some of the identified challenges:
This document does not request any action from IANA.
The CLAS architecture relies upon the functional entities that are introduced in [RFC7149] and [RFC7426]. As such security considerations discussed in Section 5 of [RFC7149], in particular, must be taken into account.
The communication between the service and transport SDN controllers must rely on secure means which achieve the following:
Each of the controllers must be provided with instructions about the set of information (and granularity) that can be disclosed to a peer controller. Means to prevent leaking privacy data (e.g., from the service stratum to the transport stratum) must be enabled. The exact set of information to be shared is deployment-specific.
A corrupted controller may induce some disruption on another controller. Guards against such attacks should be enabled.
Security in the communication between the strata here described should apply on the APIs (and/or protocols) to be defined among them. In consequence, security concerns will correspond to the specific solution.
This document was previously discussed and adopted in the IRTF SDN RG as [I-D.irtf-sdnrg-layered-sdn]. After the closure of the IRTF SDN RG this document is being progressed as Individual Submission to record (some of) that group's disucussions.
The authors would like to thank (in alphabetical order) Bartosz Belter, Gino Carrozzo, Ramon Casellas, Gert Grammel, Ali Haider, Evangelos Haleplidis, Zheng Haomian, Giorgios Karagianis, Gabriel Lopez, Maria Rita Palatella, Christian Esteve Rothenberg, and Jacek Wytrebowicz for their comments and suggestions.
Thanks to Adrian Farrel for the review.
| [Y.2011] | "General principles and general reference model for Next Generation Networks", ITU-T Recommendation Y.2011 , October 2004. |
[RFC7426] introduces an SDN taxonomy by defining a number of planes, abstraction layers, and interfaces or APIs among them, as a means of clarifying how the different parts constituent of SDN (network devices, control and management) relate among them. A number of planes are defined, namely:
Apart from that, [RFC7426] proposes a number of abstraction layers that permit the integration of the different planes through common interfaces. CLAS focuses on Control, Management and Resource planes as the basic pieces of its architecture. Essentially, the control plane modifies the behavior and actions of the controlled resources. The management plane monitors and retrieves the status of those resources. And finally, the resource plane groups all the resources related to the concerns of each strata.
From this point of view, CLAS planes can be seen as a superset of [RFC7426], even though in some cases not all the planes as considered in [RFC7426] could not be totally present in CLAS representation (e.g., forwarding plane in Service Stratum).
Being said that, internal structure of CLAS strata could follow the taxonomy defined in [RFC7426]. Which is differential is the specialization of the SDN environments, through the distinction between service and transport.