SDN Research Group LM. Contreras
Internet-Draft Telefonica I+D
Intended status: Standards Track CJ. Bernardos
Expires: February 12, 2015 UC3M
D. Lopez
Telefonica I+D
August 11, 2014
Cooperating Layered Architecture for SDN
draft-contreras-sdnrg-layered-sdn-01
Abstract
The Software Defined Networking paradigm proposes the separation of
the control plane from the data plane in the network nodes and its
logical centralization on a control entity. All the network
intelligence is moved to this central entity. Typically, such
central 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 services
and transport control.
This document describes a new proposal named Cooperating Layered
Architecture for SDN. 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 evolutionary way.
Status of This Memo
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 http://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 February 12, 2015.
Contreras, et al. Expires February 12, 2015 [Page 1]
Internet-Draft Layered SDN Architecture August 2014
Copyright Notice
Copyright (c) 2014 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
(http://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture overview . . . . . . . . . . . . . . . . . . . . 4
3.1. Functional strata . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Transport stratum . . . . . . . . . . . . . . . . . . 6
3.1.2. Service stratum . . . . . . . . . . . . . . . . . . . 6
3.1.3. Recursiveness . . . . . . . . . . . . . . . . . . . . 7
3.2. Plane separation . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Management Plane . . . . . . . . . . . . . . . . . . 7
3.2.3. Resource Plane . . . . . . . . . . . . . . . . . . . 8
4. Deployment scenarios . . . . . . . . . . . . . . . . . . . . 8
4.1. Full SDN environments . . . . . . . . . . . . . . . . . . 8
4.1.1. Multiple Service strata associated to a single
Transport stratum . . . . . . . . . . . . . . . . . . 8
4.1.2. Single service stratum associated to multiple
Transport strata . . . . . . . . . . . . . . . . . . 8
4.2. Hybrid environments . . . . . . . . . . . . . . . . . . . 8
4.2.1. SDN Service stratum associated to a legacy Transport
stratum . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Legacy Service stratum associated to an SDN Transport
stratum . . . . . . . . . . . . . . . . . . . . . . . 9
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Network Function Virtualization . . . . . . . . . . . . . 9
5.2. Abstraction and Control of Transport Networks . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Contreras, et al. Expires February 12, 2015 [Page 2]
Internet-Draft Layered SDN Architecture August 2014
1. Introduction
Software Defined Networking (SDN) proposes the separation of the
control plane from the data plane in the network nodes and its
logical centralization on a control entity. A programmatic interface
is defined between such entity and the network nodes, which
functionality is now simplified to purely perform traffic forwarding.
Through that interface, the central control entity instructs the
nodes and modifies their traffic forwarding behavior.
All the intelligence is moved to such central entity. Typically,
such central entity is seen as a compendium of interacting control
functions in a vertical, tight integrated fashion.
This approach presents a number of issues:
o Unclear responsibilities between actors involved in a service
provision and delivery.
o Complex reuse of functions for the provision of services.
o Closed, monolithic control architectures.
o Difficult interoperability and interchangeability of functional
components.
o Blurred business boundaries among providers.
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 services and transport control.
This document describes a new proposal 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 evolutionary
way.
Despite such differentiation it is required a close cooperation
between service and transport layers and associated components to
provide an efficient usage of the resources.
Contreras, et al. Expires February 12, 2015 [Page 3]
Internet-Draft Layered SDN Architecture August 2014
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
Additionally, the following acronyms are used in this document.
CLAS: Cooperating Layered Architecture for SDN
SDN: Software Defined Networking
SLA: Service Level Agreement
3. Architecture overview
Current operator networks support multiple services (e.g., mobile,
fixed, enterprise, etc) on a variety of transport technologies. The
provision and delivery of a service independently of the underlying
transport capabilities requires a separation of the service related
functionalities and, ideally, an abstraction of the transport network
to hide the particularities of each technology while offering a
common set of capabilities.
Such separation can provide configuration flexibility and
adaptability either from the point of view of the services or the
transport network. Multiple services can be provided on top of a
common transport network, and similarly, different technologies can
support a certain service. A close coordination among them is
required for a consistent service delivery.
An example of that could be the guarantee of some Quality of Service
(QoS) level. Different QoS 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.
This document presents a proposal called Cooperating Layered
Architecture for SDN (CLAS). In this architecture the logically
centralized control functions are separated in two blocks or layers.
One of the layers comprises the service-related functions, whereas
the other one contains the transport-related functions. The
cooperation between the two layers is considered to be implemented
through open, 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].
Two strata of functionality are defined, namely the Service Stratum,
Contreras, et al. Expires February 12, 2015 [Page 4]
Internet-Draft Layered SDN Architecture August 2014
comprising the service-related functions, and the Transport Stratum,
covering the transport ones. The functions on each of these layers
are further grouped on control, management and user (or data) planes.
North Bound Interface
/\
||
+-------------------------------------||-------------+
| Service Stratum || |
| \/ |
| ........................... |
| . SDN Controller . |
| . . |
| +--------------+ . +--------------+ . |
| | Resource Pl. | . | Mngmt. Pl. | . |
| | |<===>. +--------------+ | . |
| | | . | Control Pl. | | . |
| +--------------+ . | |-----+ . |
| . | | . |
| . +--------------+ . |
| ........................... |
| /\ |
| || |
+-------------------------------------||-------------+
||
||
||
+-------------------------------------||-------------+
| Transport Stratum || |
| \/ |
| ........................... |
| . SDN Controller . |
| . . |
| +--------------+ . +--------------+ . |
| | Resource Pl. | . | Mngmt. Pl. | . |
| | |<===>. +--------------+ | . |
| | | . | Control Pl. | | . |
| +--------------+ . | |-----+ . |
| . | | . |
| . +--------------+ . |
| ........................... |
| |
| |
+----------------------------------------------------+
Figure 1: Cooperating Layered Architecture for SDN
Contreras, et al. Expires February 12, 2015 [Page 5]
Internet-Draft Layered SDN Architecture August 2014
In the CLAS architecture both the control and management functions
are the ones logically centralized in an SDN controller, in such a
way that separated SDN controllers are present in the Service and
Transport strata. 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 controller through an standard
interface.
The SDN controllers cooperate for the provision and delivery of
services. There is a hierarchy in which the Service SDN controller
requests transport capabilities to the Transport SDN controller.
Furthermore, the Transport SDN controller interacts with the Service
SDN controller to inform it about events in the transport network
that can motivate actions in the service layer.
The Service SDN controller acts as a client of the Transport SDN
controller.
Despite it is not shown in the figure, the Resource planes of each
stratum could be connected. This will depend on the kind of service
provided. Furthermore, the Service stratum could offer a North Bound
Interface towards external applications to expose network service
capabilities to those applications.
3.1. Functional strata
As described before, the functional split separates transport-related
functions from service-related functions. Both strata cooperate for
a consistent service delivery.
3.1.1. Transport stratum
The Transport stratum comprises the functions focused on the pure
transfer of end user data between the communication end points. The
data forwarding nodes are part of the Resource plane. These nodes
are controlled and managed by the Transport SDN controller. The
Control plane in the SDN controller is in charge of instructing the
forwarding devices to build the end to end data path for each
communication. Finally, the Management plane performs management
functions on those devices, like fault or performance management, as
part of the Transport stratum capabilities.
3.1.2. Service stratum
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
Contreras, et al. Expires February 12, 2015 [Page 6]
Internet-Draft Layered SDN Architecture August 2014
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.
3.1.3. Recursiveness
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
services complemented with advanced capabilities additional to the
pure data transport (e.g., maintenance of a given SLA).
3.2. Plane separation
The CLAS architecture leverages on the SDN proposition of 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.
3.2.1. Control Plane
The Control plane logically centralizes the control functions of each
stratum and directly controls the corresponding resources.
[I-D.haleplidis-sdnrg-layer-terminology] introduces the role of the
control plane in a SDN architecture. This plane is part of an SDN
controller, and can interact with other control planes in the same or
different strata for accomplishing control functions.
3.2.2. Management Plane
The Management plane logically centralizes the management functions
for each stratum, including the management of the Control and
Resource planes. [I-D.haleplidis-sdnrg-layer-terminology] describes
the functions of the management plane in a SDN environment. This
plane is also part of the SDN controller, and can interact with the
corresponding management planes residing in SDN controllers of the
same or different strata.
Contreras, et al. Expires February 12, 2015 [Page 7]
Internet-Draft Layered SDN Architecture August 2014
3.2.3. Resource Plane
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 [I-D.haleplidis-sdnrg-layer-terminology] would be part of
the Resource plane in this architecture.
4. Deployment scenarios
Different situations can be found depending on the characteristics of
the networks involved in a given deployment.
4.1. Full SDN environments
This case considers the fact that the networks involved in the
provision and delivery of a given service have SDN capabilities.
4.1.1. Multiple Service strata associated to a single Transport stratum
A single Transport stratum can provide transfer functions to more
than one Service strata. The Transport stratum offers a standard
interface 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,
independent routing, etc.
4.1.2. Single service stratum associated to multiple Transport strata
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.
4.2. Hybrid environments
This case considers scenarios where one of the strata is legacy
totally or in part.
4.2.1. SDN Service stratum associated to a legacy Transport stratum
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
Contreras, et al. Expires February 12, 2015 [Page 8]
Internet-Draft Layered SDN Architecture August 2014
protocols, as expected by the legacy Transport stratum. The SDN
controller in the Service stratum is not aware of the legacy nature
of the underlying Transport stratum.
4.2.2. Legacy Service stratum associated to an SDN 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.
5. Use cases
This section presents a number of use cases as examples of
applicability of this proposal
5.1. Network Function Virtualization
To be completed.
5.2. Abstraction and Control of Transport Networks
To be completed.
6. IANA Considerations
TBD.
7. Security Considerations
TBD. Security in the communication between strata to be addressed.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Y.2011] "General principles and general reference model for Next
Generation Networks", ITU-T Recommendation Y.2011 ,
October 2004.
Contreras, et al. Expires February 12, 2015 [Page 9]
Internet-Draft Layered SDN Architecture August 2014
8.2. Informative References
[I-D.haleplidis-sdnrg-layer-terminology]
Haleplidis, E., Pentikousis, K., Denazis, S., Salim, J.,
Meyer, D., and O. Koufopavlou, "SDN Layers and
Architecture Terminology", draft-haleplidis-sdnrg-layer-
terminology-07 (work in progress), August 2014.
Authors' Addresses
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: lmcm@tid.es
URI: http://people.tid.es/LuisM.Contreras/
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Diego R. Lopez
Telefonica I+D
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: diego@tid.es
Contreras, et al. Expires February 12, 2015 [Page 10]