< draft-contreras-layered-sdn-03.txt   rfc8597.txt 
Network Working Group LM. Contreras Independent Submission LM. Contreras
Internet-Draft Telefonica Request for Comments: 8597 Telefonica
Intended status: Informational CJ. Bernardos Category: Informational CJ. Bernardos
Expires: May 25, 2019 UC3M ISSN: 2070-1721 UC3M
D. Lopez D. Lopez
Telefonica Telefonica
M. Boucadair M. Boucadair
Orange Orange
P. Iovanna P. Iovanna
Ericsson Ericsson
November 21, 2018 May 2019
Cooperating Layered Architecture for Software Defined Networking (CLAS) Cooperating Layered Architecture for Software-Defined Networking (CLAS)
draft-contreras-layered-sdn-03
Abstract Abstract
Software Defined Networking adheres to the separation of the control Software-Defined Networking (SDN) advocates for the separation of the
plane from the data plane in the network nodes and its logical control plane from the data plane in the network nodes and its
centralization on one or a set of control entities. Most of the logical centralization on one or a set of control entities. Most of
network and/or sevice intelligence is moved to these control the network and/or service intelligence is moved to these control
entities. Typically, such entity is seen as a compendium of entities. Typically, such an entity is seen as a compendium of
interacting control functions in a vertical, tight integrated interacting control functions in a vertical, tightly integrated
fashion. The relocation of the control functions from a number of fashion. The relocation of the control functions from a number of
distributed network nodes to a logical central entity conceptually distributed network nodes to a logical central entity conceptually
places together a number of control capabilities with different places together a number of control capabilities with different
purposes. As a consequence, the existing solutions do not provide a purposes. As a consequence, the existing solutions do not provide a
clear separation between transport control and services that relies clear separation between transport control and services that rely
upon transport capabilities. upon transport capabilities.
This document describes an approach named Cooperating Layered This document describes an approach called Cooperating Layered
Architecture for Software Defined Networking. The idea behind that Architecture for Software-Defined Networking (CLAS), wherein the
is to differentiate the control functions associated to transport control functions associated with transport are differentiated from
from those related to services, in such a way that they can be those related to services in such a way that they can be provided and
provided and maintained independently, and can follow their own maintained independently and can follow their own evolution path.
evolution path.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
This Internet-Draft will expire on May 25, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8597.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6
3.1. Functional Strata . . . . . . . . . . . . . . . . . . . . 9 3.1. Functional Strata . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Transport Stratum . . . . . . . . . . . . . . . . . . 9 3.1.1. Transport Stratum . . . . . . . . . . . . . . . . . . 9
3.1.2. Service Stratum . . . . . . . . . . . . . . . . . . . 10 3.1.2. Service Stratum . . . . . . . . . . . . . . . . . . . 10
3.1.3. Recursiveness . . . . . . . . . . . . . . . . . . . . 10 3.1.3. Recursiveness . . . . . . . . . . . . . . . . . . . . 10
3.2. Plane Separation . . . . . . . . . . . . . . . . . . . . 10 3.2. Plane Separation . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Management Plane . . . . . . . . . . . . . . . . . . 11 3.2.2. Management Plane . . . . . . . . . . . . . . . . . . 11
3.2.3. Resource Plane . . . . . . . . . . . . . . . . . . . 11 3.2.3. Resource Plane . . . . . . . . . . . . . . . . . . . 11
4. Required Features . . . . . . . . . . . . . . . . . . . . . . 11 4. Required Features . . . . . . . . . . . . . . . . . . . . . . 11
5. Communication Between SDN Controllers . . . . . . . . . . . . 12 5. Communication between SDN Controllers . . . . . . . . . . . . 12
6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 12 6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 12
6.1. Full SDN Environments . . . . . . . . . . . . . . . . . . 12 6.1. Full SDN Environments . . . . . . . . . . . . . . . . . . 13
6.1.1. Multiple Service Strata Associated to a Single 6.1.1. Multiple Service Strata Associated with a Single
Transport Stratum . . . . . . . . . . . . . . . . . . 13 Transport Stratum . . . . . . . . . . . . . . . . . . 13
6.1.2. Single Service Stratum associated to multiple 6.1.2. Single Service Stratum Associated with Multiple
Transport Strata . . . . . . . . . . . . . . . . . . 13 Transport Strata . . . . . . . . . . . . . . . . . . 13
6.2. Hybrid Environments . . . . . . . . . . . . . . . . . . . 13 6.2. Hybrid Environments . . . . . . . . . . . . . . . . . . . 13
6.2.1. SDN Service Stratum associated to a Legacy Transport 6.2.1. SDN Service Stratum Associated with a Legacy
Stratum . . . . . . . . . . . . . . . . . . . . . . . 13 Transport Stratum . . . . . . . . . . . . . . . . . . 13
6.2.2. Legacy Service Stratum Associated to an SDN Transport 6.2.2. Legacy Service Stratum Associated with an SDN
Stratum . . . . . . . . . . . . . . . . . . . . . . . 13 Transport Stratum . . . . . . . . . . . . . . . . . . 13
6.3. Multi-domain Scenarios in the Transport Stratum . . . . . 14
6.3. Multi-domain Scenarios in Transport Stratum . . . . . . . 13
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Network Function Virtualization (NFV) . . . . . . . . . . 14 7.1. Network Function Virtualization (NFV) . . . . . . . . . . 14
7.2. Abstraction and Control of Transport Networks . . . . . . 14 7.2. Abstraction and Control of TE Networks . . . . . . . . . 15
8. Challenges for Implementing Actions Between Service and 8. Challenges for Implementing Actions between Service and
Transport Strata . . . . . . . . . . . . . . . . . . . . . . 15 Transport Strata . . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Relationship with RFC 7426 . . . . . . . . . . . . . 19
Appendix A. Relationship with RFC7426 . . . . . . . . . . . . . 18 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Network softwarization advances are facilitating the introduction of Network softwarization advances are facilitating the introduction of
programmability in services and infrastructures of telco operators. programmability in the services and infrastructures of
This is achieved generically through the introduction of Software telecommunications operators. This is generally achieved through the
Defined Networking (SDN, [RFC7149][RFC7426]) capabilities in the introduction of Software-Defined Networking (SDN) [RFC7149] [RFC7426]
network, including controllers and orchestrators. capabilities in the network, including controllers and orchestrators.
However, there are concerns of different nature that these SDN However, there are concerns of a different nature that these SDN
capabilities have to resolve. In one hand there is a need for capabilities have to resolve. On the one hand, actions focused on
actions focused on programming the network for handle the programming the network to handle the connectivity or forwarding of
connectivity or forwarding of digital data between distant nodes. On digital data between distant nodes are needed. On the other hand,
the other hand, there is a need for actions devoted to program the actions devoted to programming the functions or services that process
functions or services that process (or manipulate) such digital data. (or manipulate) such digital data are also needed.
SDN adheres to the separation of the control plane from the data SDN advocates for the separation of the control plane from the data
plane in the network nodes by introducing abstraction among both plane in the network nodes by introducing abstraction among both
planes, allowing to centralize the control logic on a functional planes, allowing the control logic on a functional entity, which is
entity which is commonly referred as SDN Controller; one or multiple commonly referred as SDN Controller, to be centralized; one or
controllers may be deployed. A programmatic interface is then multiple controllers may be deployed. A programmatic interface is
defined between a forwarding entity (at the network node) and a then defined between a forwarding entity (at the network node) and a
control entity. Through that interface, a control entity instructs control entity. Through that interface, a control entity instructs
the nodes involved in the forwarding plane and modifies their traffic the nodes involved in the forwarding plane and modifies their
forwarding behavior accordingly. Additional capabilities (e.g., traffic-forwarding behavior accordingly. Support for additional
performance monitoring, fault management, etc.) could be expected to capabilities (e.g., performance monitoring, fault management, etc.)
be supported through such kind of programmatic interface [RFC7149]. could be expected through this kind of programmatic interface
[RFC7149].
Most of the intelligence is moved to such functional entity. Most of the intelligence is moved to this kind of functional entity.
Typically, such entity is seen as a compendium of interacting control Typically, such an entity is seen as a compendium of interacting
functions in a vertical, tight integrated fashion. control functions in a vertical, tightly integrated fashion.
The approach of considering an omnipotent control entity governing The approach of considering an omnipotent control entity governing
the overall aspects of a network, especially both the transport the overall aspects of a network, especially both the transport
network and the services to be supported on top of it, presents a network and the services to be supported on top of it, presents a
number of issues: number of issues:
o From a provider perspective, where usually different departments o From a provider perspective, where different departments usually
are responsible of handling service and connectivity (i.e., are responsible for handling service and connectivity (i.e.,
transport capabilities for the service on top), the mentioned transport capabilities for the service on top), the mentioned
approach offers unclear responsibilities for complete service approach offers unclear responsibilities for complete service
provision and delivery. provision and delivery.
o Complex reuse of functions for the provision of services. o Complex reuse of functions for the provision of services.
o Closed, monolithic control architectures. o Closed, monolithic control architectures.
o Difficult interoperability and interchangeability of functional o Difficult interoperability and interchangeability of functional
components. components.
o Blurred business boundaries among providers, especially in o Blurred business boundaries among providers, especially in
situations where a provider provides just connectivity while situations where one provider provides only connectivity while
another provider offers a more sophisticated service on top of another provider offers a more sophisticated service on top of
that connectivity. that connectivity.
o Complex service/network diagnosis and troubleshooting, o Complex service/network diagnosis and troubleshooting,
particularly to determine which segment is responsible for a particularly to determine which layer is responsible for a
failure. failure.
The relocation of the control functions from a number of distributed The relocation of the control functions from a number of distributed
network nodes to another entity conceptually places together a number network nodes to another entity conceptually places together a number
of control capabilities with different purposes. As a consequence, of control capabilities with different purposes. As a consequence,
the existing SDN solutions do not provide a clear separation between the existing SDN solutions do not provide a clear separation between
services and transport control. Here, the separation between service services and transport control. Here, the separation between service
and transport follows the distinction provided by [Y.2011], and also and transport follows the distinction provided by [Y.2011] and as
defined in Section 2 of this document. defined in Section 2 of this document.
This document describes an approach named Cooperating Layered This document describes an approach called Cooperating Layered
Architecture for SDN (CLAS). The idea behind that is to Architecture for SDN (CLAS), wherein the control functions associated
differentiate the control functions associated to transport from with transport are differentiated from those related to services in
those related to services, in such a way that they can be provided such a way that they can be provided and maintained independently and
and maintained independently, and can follow their own evolution can follow their own evolution path.
path.
Despite such differentiation it is required a close cooperation Despite such differentiation, close cooperation between the service
between service and transport layers (or strata in [Y.2011]) and and transport layers (or strata in [Y.2011]) and the associated
associated components to provide an efficient usage of the resources. components are necessary to provide efficient usage of the resources.
2. Terminology 2. Terminology
This document makes use of the following terms: This document makes use of the following terms:
o Transport: denotes the transfer capabilities offered by a o Transport: denotes the transfer capabilities offered by a
networking infrastructure. The transfer capabilities can rely networking infrastructure. The transfer capabilities can rely
upon pure IP techniques, or other means such as MPLS or optics. upon pure IP techniques or other means, such as MPLS or optics.
o Service: denotes a logical construct that makes use of transport o Service: denotes a logical construct that makes use of transport
capabilities. capabilities.
This document does not make any assumption on the functional This document does not make any assumptions about the functional
perimeter of a service that can be built above a transport perimeter of a service that can be built above a transport
infrastructure. As such, a service can be an offering that is infrastructure. As such, a service can be offered to customers or
offered to customers or be invoked for the delivery of another invoked for the delivery of another (added-value) service.
(added-value) service.
o Layer: refers to the set of elements comprised for enabling either o Layer: refers to the set of elements that enable either transport
transport or service capabilities as defined before. In [Y.2011], or service capabilities, as defined previously. In [Y.2011], this
this is referred to as stratum, and both are used interchangeably. is referred to as a "stratum", and the two terms are used
interchangeably.
o Domain: is a set of elements which share a common property or o Domain: is a set of elements that share a common property or
characteristic. In this document this applies to administrative characteristic. In this document, it applies to the
domain (i.e., elements pertaining to the same organization), administrative domain (i.e., elements pertaining to the same
technological domain (elements implementing the same kind of organization), technological domain (elements implementing the
technology, as for example optical nodes), etc. same kind of technology, such as optical nodes), etc.
o SDN Intelligence: refers to the decision-making process that is o SDN Intelligence: refers to the decision-making process that is
hosted by a node or a set of nodes. These nodes are called SDN hosted by a node or a set of nodes. These nodes are called SDN
controllers. controllers.
The intelligence can be centralized or distributed. Both schemes The intelligence can be centralized or distributed. Both schemes
are within the scope of this document. are within the scope of this document.
The SDN intelligence relies on inputs form various functional An SDN Intelligence relies on inputs from various functional
blocks such as: network topology discovery, service topology blocks, such as: network topology discovery, service topology
discovery, resource allocation, business guidelines, customer discovery, resource allocation, business guidelines, customer
profiles, service profiles, etc. profiles, service profiles, etc.
The exact decomposition of an SDN intelligence, apart from the The exact decomposition of an SDN Intelligence, apart from the
layering discussed in this document, is out of scope. layering discussed here, is out of the scope of this document.
Additionally, the following acronyms are used in this document: Additionally, the following acronyms are used in this document:
CLAS: Cooperating Layered Architecture for SDN CLAS: Cooperating Layered Architecture for SDN
FCAPS: Fault, Configuration, Accounting, Performance and Security FCAPS: Fault, Configuration, Accounting, Performance, and Security
SDN: Software Defined Networking
SDN: Software-Defined Networking
SLA: Service Level Agreement SLA: Service Level Agreement
3. Architecture Overview 3. Architecture Overview
Current operator networks support multiple services (e.g., VoIP, Current operator networks support multiple services (e.g., Voice over
IPTV, mobile VoIP, critical mission applications, etc.) on a variety IP (VoIP), IPTV, mobile VoIP, critical mission applications, etc.) on
of transport technologies. The provision and delivery of a service a variety of transport technologies. The provision and delivery of a
independently of the underlying transport capabilities require a service independent of the underlying transport capabilities require
separation of the service related functionalities and an abstraction a separation of the service-related functionalities and an
of the transport network to hide the specificities of underlying abstraction of the transport network to hide the specifics of the
transfer techniques while offering a common set of capabilities. underlying transfer techniques while offering a common set of
capabilities.
Such separation can provide configuration flexibility and Such separation can provide configuration flexibility and
adaptability from the point of view of either the services or the adaptability from the point of view of either the services or the
transport network. Multiple services can be provided on top of a transport network. Multiple services can be provided on top of a
common transport infrastructure, and similarly, different common transport infrastructure; similarly, different technologies
technologies can accommodate the connectivity requirements of a can accommodate the connectivity requirements of a certain service.
certain service. A close coordination among them is required for a Close coordination among these elements is required for consistent
consistent service delivery (inter-layer cooperation). service delivery (inter-layer cooperation).
This document focuses particularly on: This document focuses particularly on the means to:
o Means to expose transport capabilities to services. o expose transport capabilities to services.
o Means to capture service requirements of services. o capture transport requirements of services.
o Means to notify service intelligence with underlying transport o notify service intelligence of underlying transport events, for
events, for example to adjust service decision-making process with example, to adjust a service decision-making process with
underlying transport events. underlying transport events.
o Means to instruct the underlying transport capabilities to o instruct the underlying transport capabilities to accommodate new
accommodate new requirements, etc. requirements, etc.
An example is to guarantee some Quality of Service (QoS) levels. An example is guaranteeing some Quality-of-Service (QoS) levels.
Different QoS-based offerings could be present at both service and Different QoS-based offerings could be present at both the service
transport layers. Vertical mechanisms for linking both service and and transport layers. Vertical mechanisms for linking both service
transport QoS mechanisms should be in place to provide the quality and transport QoS mechanisms should be in place to provide quality
guarantees to the end user. guarantees to the end user.
CLAS architecture assumes that the logically centralized control CLAS architecture assumes that the logically centralized control
functions are separated in two functional layers. One of the functions are separated into two functional layers. One of the
functional layers comprises the service-related functions, whereas functional layers comprises the service-related functions, whereas
the other one contains the transport-related functions. The the other one contains the transport-related functions. The
cooperation between the two layers is expected to be implemented cooperation between the two layers is expected to be implemented
through standard interfaces. through standard interfaces.
Figure 1 shows the CLAS architecture. It is based on functional Figure 1 shows the CLAS architecture. It is based on functional
separation in the NGN architecture defined by the ITU-T in [Y.2011], separation in the Next Generation Network (NGN) architecture defined
where two strata of functionality are defined, namely the Service by the ITU-T in [Y.2011], where two strata of functionality are
Stratum, comprising the service-related functions, and the defined. These strata are the Service Stratum, comprising the
Connectivity Stratum, covering the transport ones. The functions on service-related functions, and the Transport Stratum, covering the
each of these layers are further grouped on control, management and transport-related functions. The functions of each of these layers
user (or data) planes. are further grouped into the control, management, and user (or data)
planes.
CLAS adopts the same structured model described in [Y.2011] but CLAS adopts the same structured model described in [Y.2011] but
applying it to the objectives of programmability through SDN applies it to the objectives of programmability through SDN
[RFC7149]. To this respect, CLAS advocates for addressing services [RFC7149]. In this respect, CLAS advocates for addressing services
and transport in a separated manner because of their differentiated and transport in a separated manner because of their differentiated
concerns. concerns.
Applications Applications
/\ /\
|| ||
|| ||
+-------------------------------------||-------------+ +-------------------------------------||-------------+
| Service Stratum || | | Service Stratum || |
| \/ | | \/ |
| ........................... | | ........................... |
| . SDN Intelligence . | | . SDN Intelligence . |
| . . | | . . |
| +--------------+ . +--------------+ . | | +--------------+ . +--------------+ . |
| | Resource Pl. | . | Mngmt. Pl. | . | | | Resource Pl. | . | Mgmt. Pl. | . |
| | |<===>. +--------------+ | . | | | |<===>. +--------------+ | . |
| | | . | Control Pl. | | . | | | | . | Control Pl. | | . |
| +--------------+ . | |-----+ . | | +--------------+ . | |-----+ . |
| . | | . | | . | | . |
| . +--------------+ . | | . +--------------+ . |
| ........................... | | ........................... |
| /\ | | /\ |
| || | | || |
+-------------------------------------||-------------+ +-------------------------------------||-------------+
|| Standard || Standard
-- || -- API -- || -- API
|| ||
+-------------------------------------||-------------+ +-------------------------------------||-------------+
| Transport Stratum || | | Transport Stratum || |
| \/ | | \/ |
| ........................... | | ........................... |
| . SDN Intelligence . | | . SDN Intelligence . |
| . . | | . . |
| +--------------+ . +--------------+ . | | +--------------+ . +--------------+ . |
| | Resource Pl. | . | Mngmt. Pl. | . | | | Resource Pl. | . | Mgmt. Pl. | . |
| | |<===>. +--------------+ | . | | | |<===>. +--------------+ | . |
| | | . | Control Pl. | | . | | | | . | Control Pl. | | . |
| +--------------+ . | |-----+ . | | +--------------+ . | |-----+ . |
| . | | . | | . | | . |
| . +--------------+ . | | . +--------------+ . |
| ........................... | | ........................... |
| | | |
| | | |
+----------------------------------------------------+ +----------------------------------------------------+
Figure 1: Cooperating Layered Architecture for SDN Figure 1: Cooperating Layered Architecture for SDN
In the CLAS architecture both the control and management functions In the CLAS architecture, both the control and management functions
are considered to be performed by one or a set of SDN controllers are considered to be performed by one or a set of SDN controllers
(due to, e.g., scalability, reliability) providing the SDN (due to, for example, scalability, reliability), providing the SDN
Intelligence, in such a way that separated SDN controllers are Intelligence in such a way that separated SDN controllers are present
present in the Service and Transport strata. Management functions in the Service and Transport Strata. Management functions are
are considered to be part of the SDN Intelligence to allow the considered to be part of the SDN Intelligence to allow for effective
effective operation in a service provider ecosystem [RFC7149] despite operation in a service provider ecosystem [RFC7149], although some
some initial propositions did not consider such management as part of initial propositions did not consider such management as part of the
the SDN environment [ONFArch]. SDN environment [ONFArch].
Furthermore, the generic user or data plane functions included in the Furthermore, the generic user- or data-plane functions included in
NGN architecture are referred here as resource plane functions. The the NGN architecture are referred to here as resource-plane
resource plane in each stratum is controlled by the corresponding SDN functions. The resource plane in each stratum is controlled by the
Intelligence through a standard interface. corresponding SDN Intelligence through a standard interface.
The SDN controllers cooperate for the provision and delivery of The SDN controllers cooperate in the provision and delivery of
services. There is a hierarchy in which the Service SDN Intelligence services. There is a hierarchy in which the Service SDN Intelligence
requests transport capabilities to the Transport SDN Intelligence. makes requests of the Transport SDN Intelligence for the provision of
transport capabilities.
The Service SDN Intelligence acts as a client of the Transport SDN The Service SDN Intelligence acts as a client of the Transport SDN
Intelligence. Intelligence.
Furthermore, the Transport SDN Intelligence interacts with the Furthermore, the Transport SDN Intelligence interacts with the
Service SDN Intelligence to inform it about events in the transport Service SDN Intelligence to inform it about events in the transport
network that can motivate actions in the service layer. network that can motivate actions in the service layer.
Despite it is not shown in Figure 1, the resource planes of each Despite not being shown in Figure 1, the resource planes of each
stratum could be connected. This will depend on the kind of service stratum could be connected. This will depend on the kind of service
provided. Furthermore, the Service stratum could offer an interface provided. Furthermore, the Service Stratum could offer an interface
towards applications to expose network service capabilities to those to applications to expose network service capabilities to those
applications or customers. applications or customers.
3.1. Functional Strata 3.1. Functional Strata
As described before, the functional split separates transport-related As aforementioned, there is a functional split that separates
functions from service-related functions. Both strata cooperate for transport-related functions from service-related functions. Both
a consistent service delivery. strata cooperate for consistent service delivery.
Consistency is determined and characterized by the service layer. Consistency is determined and characterized by the service layer.
3.1.1. Transport Stratum 3.1.1. Transport Stratum
The Transport Stratum comprises the functions focused on the transfer The Transport Stratum comprises the functions focused on the transfer
of data between the communication end points (e.g., between end-user of data between the communication endpoints (e.g., between end-user
devices, between two service gateways, etc.). The data forwarding devices, between two service gateways, etc.). The data-forwarding
nodes are controlled and managed by the Transport SDN component. nodes are controlled and managed by the Transport SDN component.
The Control plane in the SDN Intelligence is in charge of instructing 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 the forwarding devices to build the end-to-end data path for each
communication or to make sure forwarding service is appropriately communication or to make sure the forwarding service is appropriately
setup. Forwarding may not be rely on the sole pre-configured set up. Forwarding may not be rely solely on the preconfigured
entries; dynamic means can be enabled so that involved nodes can entries; means can be enabled so that involved nodes can dynamically
build dynamically routing and forwarding paths (this would require build routing and forwarding paths (this would require that the nodes
that the nodes retain some of the control and management capabilities retain some of the control and management capabilities for enabling
for enabling this). Finally, the Management plane performs this). Finally, the management plane performs management functions
management functions (i.e., FCAPS) on those devices, like fault or (i.e., FCAPS) on those devices, like fault or performance management,
performance management, as part of the Transport Stratum as part of the Transport Stratum capabilities.
capabilities.
3.1.2. Service Stratum 3.1.2. Service Stratum
The Service stratum contains the functions related to the provision The Service Stratum contains the functions related to the provision
of services and the capabilities offered to external applications. of services and the capabilities offered to external applications.
The Resource plane consists of the resources involved in the service The resource plane consists of the resources involved in the service
delivery, such as computing resources, registries, databases, etc. delivery, such as computing resources, registries, databases, etc.
The Control plane is in charge of controlling and configuring those The control plane is in charge of controlling and configuring those
resources, as well as interacting with the Control plane of the resources as well as interacting with the control plane of the
Transport stratum in client mode for requesting transport Transport Stratum in client mode to request transport capabilities
capabilities for a given service. In the same way, the Management for a given service. In the same way, the management plane
plane implements management actions on the service-related resources implements management actions on the service-related resources and
and interacts with the Management plane in the Transport Stratum for interacts with the management plane in the Transport Stratum to
a cooperating management between layers. ensure management cooperation between layers.
3.1.3. Recursiveness 3.1.3. Recursiveness
Recursive layering can happen in some usage scenarios in which the Recursive layering can happen in some usage scenarios in which the
Transport Stratum is itself structured in Service and Transport Transport Stratum is itself structured in the Service and Transport
Stratum. This could be the case of the provision of a transport Strata. This could be the case in the provision of a transport
service complemented with advanced capabilities additional to the service complemented with advanced capabilities in addition to the
pure data transport (e.g., maintenance of a given SLA [RFC7297]). pure data transport (e.g., maintenance of a given SLA [RFC7297]).
Recursiveness has been also discussed in [ONFArch] as a way of Recursiveness has also been discussed in [ONFArch] as a way of
reaching scalability and modularity, when each higher level can reaching scalability and modularity, where each higher level can
provide greater abstraction capabilities. Additionally, provide greater abstraction capabilities. Additionally,
recursiveness can allow some scenarios for multi-domain where single recursiveness can allow some multi-domain scenarios where single or
or multiple administrative domains are involved, as the ones multiple administrative domains are involved, such as those described
described in Section 6.3. in Section 6.3.
3.2. Plane Separation 3.2. Plane Separation
The CLAS architecture leverages on plane separation. As mentioned The CLAS architecture leverages plane separation. As mentioned in
before, three different planes are considered for each stratum. The Sections 3.1.1 and 3.1.2, three different planes are considered for
communication among these three planes (and with the corresponding each stratum. The communication among these three planes (with the
plane in other strata) is based on open, standard interfaces. corresponding plane in other strata) is based on open, standard
interfaces.
3.2.1. Control Plane 3.2.1. Control Plane
The Control plane logically centralizes the control functions of each The control plane logically centralizes the control functions of each
stratum and directly controls the corresponding resources. [RFC7426] stratum and directly controls the corresponding resources. [RFC7426]
introduces the role of the control plane in a SDN architecture. This introduces the role of the control plane in an SDN architecture.
plane is part of an SDN Intelligence, and can interact with other This plane is part of an SDN Intelligence and can interact with other
control planes in the same or different strata for accomplishing control planes in the same or different strata to perform control
control functions. functions.
3.2.2. Management Plane 3.2.2. Management Plane
The Management plane logically centralizes the management functions The management plane logically centralizes the management functions
for each stratum, including the management of the Control and for each stratum, including the management of the control and
Resource planes. [RFC7426] describes the functions of the management resource planes. [RFC7426] describes the functions of the management
plane in a SDN environment. This plane is also part of the SDN plane in an SDN environment. This plane is also part of the SDN
Intelligence, and can interact with the corresponding management Intelligence and can interact with the corresponding management
planes residing in SDN controllers of the same or different strata. planes residing in SDN controllers of the same or different strata.
3.2.3. Resource Plane 3.2.3. Resource Plane
The Resource plane comprises the resources for either the transport The resource plane comprises the resources for either the transport
or the service functions. In some cases the service resources can be or the service functions. In some cases, the service resources can
connected to the transport ones (e.g., being the terminating points be connected to the transport ones (e.g., being the terminating
of a transport function) whereas in other cases it can be decoupled points of a transport function); in other cases, it can be decoupled
from the transport resources (e.g., one database keeping some from the transport resources (e.g., one database keeping a register
register for the end user). Both forwarding and operational planes for the end user). Both the forwarding and operational planes
proposed in [RFC7426] would be part of the Resource plane in this proposed in [RFC7426] would be part of the resource plane in this
architecture. architecture.
4. Required Features 4. Required Features
Since the CLAS architecture implies the interaction of different Since the CLAS architecture implies the interaction of different
layers with different purposes and responsibilities, a number of layers with different purposes and responsibilities, a number of
features are required to be supported: features are required to be supported:
o Abstraction: the mapping of physical resources into the o Abstraction: the mapping of physical resources into the
corresponding abstracted resources. corresponding abstracted resources.
o Service parameter translation: translation of service parameters o Service-Parameter Translation: the translation of service
(e.g., in the form of SLAs) to transport parameters (or parameters (e.g., in the form of SLAs) to transport parameters (or
capabilities) according to different policies. capabilities) according to different policies.
o Monitoring: mechanisms (e.g., event notifications) available in o Monitoring: mechanisms (e.g., event notifications) available in
order to dynamically update the (abstracted) resources' status order to dynamically update the (abstracted) resources' status
taking in to account, e.g., the traffic load. while taking into account, for example, the traffic load.
o Resource computation: functions able to decide which resources o Resource Computation: functions able to decide which resources
will be used for a given service request. As an example, will be used for a given service request. As an example,
functions like PCE could be used to compute/select/decide a functions like PCE could be used to compute/select/decide a
certain path. certain path.
o Orchestration: ability to combine diverse resources (e.g., IT and o Orchestration: the ability to combine diverse resources (e.g., IT
network resources) in an optimal way. and network resources) in an optimal way.
o Accounting: record of resource usage. o Accounting: record of resource usage.
o Security: secure communication among components, preventing, e.g., o Security: secure communication among components, preventing, for
DoS attacks. example, DoS attacks.
5. Communication Between SDN Controllers 5. Communication between SDN Controllers
The SDN controllers residing respectively in the Service and the The SDN controllers residing respectively in the Service and
Transport Stratum need to establish a tight coordination. Mechanisms Transport Strata need to establish tight coordination. Mechanisms
for transfer relevant information for each stratum should be defined. for transferring relevant information for each stratum should be
defined.
From the service perspective, the Service SDN Intelligence needs to From the service perspective, the Service SDN Intelligence needs to
easily access transport resources through well-defined APIs to easily access transport resources through well-defined APIs to
retrieve the capabilities offered by the Transport Stratum. There retrieve the capabilities offered by the Transport Stratum. There
could be different ways of obtaining such transport-aware could be different ways of obtaining such transport-aware
information, i.e., by discovering or publishing mechanisms. In the information, i.e., by discovering or publishing mechanisms. In the
former case the Service SDN Intelligence could be able of handling former case, the Service SDN Intelligence could be able to handle
complete information about the transport capabilities (including complete information about the transport capabilities (including
resources) offered by the Transport Stratum. In the latter case, the resources) offered by the Transport Stratum. In the latter case, the
Transport Stratum exposes available capabilities, e.g., through a Transport Stratum reveals the available capabilities, for example,
catalog, reducing the amount of detail of the underlying network. through a catalog, reducing the amount of detail of the underlying
network.
On the other hand, the Transport Stratum requires to properly capture On the other hand, the Transport Stratum must properly capture the
Service requirements. These can include SLA requirements with Service requirements. These can include SLA requirements with
specific metrics (such as delay), level of protection to be provided, specific metrics (such as delay), the level of protection to be
max/min capacity, applicable resource constraints, etc. provided, maximum/minimum capacity, applicable resource constraints,
etc.
The communication between controllers must be also secure, e.g., by The communication between controllers must also be secure, e.g., by
preventing denial of service or any other kind of threats (similarly, preventing denial of service or any other kind of threat (similarly,
the communications with the network nodes must be secure). communications with the network nodes must be secure).
6. Deployment Scenarios 6. Deployment Scenarios
Different situations can be found depending on the characteristics of Different situations can be found depending on the characteristics of
the networks involved in a given deployment. the networks involved in a given deployment.
6.1. Full SDN Environments 6.1. Full SDN Environments
This case considers that the networks involved in the provision and This case considers that the networks involved in the provision and
delivery of a given service have SDN capabilities. delivery of a given service have SDN capabilities.
6.1.1. Multiple Service Strata Associated to a Single Transport Stratum 6.1.1. Multiple Service Strata Associated with a Single Transport
Stratum
A single Transport Stratum can provide transfer functions to more A single Transport Stratum can provide transfer functions to more
than one Service strata. The Transport Stratum offers a standard than one Service Stratum. The Transport Stratum offers a standard
interface(s) to each of the Service strata. The Service strata are interface(s) to each of the Service Strata. The Service Strata are
the clients of the Transport Stratum. Some of the capabilities the clients of the Transport Stratum. Some of the capabilities
offered by the Transport stratum can be isolation of the transport offered by the Transport Stratum can be isolation of the transport
resources (slicing), independent routing, etc. resources (slicing), independent routing, etc.
6.1.2. Single Service Stratum associated to multiple Transport Strata 6.1.2. Single Service Stratum Associated with Multiple Transport Strata
A single Service stratum can make use of different Transport Strata A single Service Stratum can make use of different Transport Strata
for the provision of a certain service. The Service stratum for the provision of a certain service. The Service Stratum invokes
interfaces each of the Transport Strata with standard protocols, and standard interfaces to each of the Transport Strata, and orchestrates
orchestrates the provided transfer capabilities for building the end the provided transfer capabilities for building the end-to-end
to end transport needs. transport needs.
6.2. Hybrid Environments 6.2. Hybrid Environments
This case considers scenarios where one of the strata is legacy This case considers scenarios where one of the strata is totally or
totally or in part. partly legacy.
6.2.1. SDN Service Stratum associated to a Legacy Transport Stratum 6.2.1. SDN Service Stratum Associated with a Legacy Transport Stratum
An SDN service stratum can interact with 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 through an interworking function that is able to adapt SDN-based
and management service-related commands to legacy transport-related control and management service-related commands to legacy transport-
protocols, as expected by the legacy Transport Stratum. related protocols, as expected by the legacy Transport Stratum.
The SDN Intelligence in the Service stratum is not aware of the The SDN Intelligence in the Service Stratum is not aware of the
legacy nature of the underlying Transport Stratum. legacy nature of the underlying Transport Stratum.
6.2.2. Legacy Service Stratum Associated to an SDN Transport Stratum 6.2.2. Legacy Service Stratum Associated with an SDN Transport Stratum
A legacy Service stratum can work with an SDN-enabled Transport A legacy Service Stratum can work with an SDN-enabled Transport
Stratum through the mediation of and interworking function capable to Stratum through the mediation of an interworking function capable of
interpret commands from the legacy service functions and translate interpreting commands from the legacy service functions and
them into SDN protocols for operating with the SDN-enabled Transport translating them into SDN protocols for operation with the SDN-
Stratum. enabled Transport Stratum.
6.3. Multi-domain Scenarios in Transport Stratum 6.3. Multi-domain Scenarios in the Transport Stratum
The Transport Stratum can be composed by transport resources being The Transport Stratum can be composed of transport resources that are
part of different administrative, topological or technological part of different administrative, topological, or technological
domains. The Service Stratum can yet interact with a single entity domains. The Service Stratum can interact with a single entity in
in the Transport Stratum in case some abstraction capabilities are the Transport Stratum in case some abstraction capabilities are
provided in the transport part to emulate a single stratum. provided in the transport part to emulate a single stratum.
Those abstraction capabilities constitute a service itself offered by Those abstraction capabilities constitute a service itself offered by
the Transport Stratum to the services making use of it. This service the Transport Stratum to the services making use of this stratum.
is focused on the provision of transport capabilities, then different This service is focused on the provision of transport capabilities,
of the final communication service using such capabilities. which is different from the final communication service using such
capabilities.
In this particular case this recursion allows multi-domain scenarios In this particular case, this recursion allows multi-domain scenarios
at transport level. at the transport level.
Multi-domain situations can happen in both single-operator and multi- Multi-domain situations can happen in both single-operator and multi-
operator scenarios. operator scenarios.
In single operator scenarios a multi-domain or end-to-end abstraction In single-operator scenarios, a multi-domain or end-to-end
component can provide an homogeneous abstract view of the underlying abstraction component can provide a homogeneous abstract view of the
heterogeneous transport capabilities for all the domains. underlying heterogeneous transport capabilities for all the domains.
Multi-operator scenarios, at the Transport Stratum, should support Multi-operator scenarios at the Transport Stratum should support the
the establishment of end-to-end paths in a programmatic manner across establishment of end-to-end paths in a programmatic manner across the
the involved networks. This could be accomplished, for example, by involved networks. For example, this could be accomplished by each
the exchange of traffic-engineered information of each of the of the administrative domains exchanging their traffic-engineered
administrative domains [RFC7926]. information [RFC7926].
7. Use Cases 7. Use Cases
This section presents a number of use cases as examples of This section presents a number of use cases as examples of the
applicability of the CLAS approach. applicability of the CLAS approach.
7.1. Network Function Virtualization (NFV) 7.1. Network Function Virtualization (NFV)
NFV environments offer two possible levels of SDN control NFV environments offer two possible levels of SDN control
[ETSI_NFV_EVE005]. One level is the need for controlling the NFV [GSNFV-EVE005]. One level is the need to control the NFV
Infrastructure (NFVI) to provide connectivity end-to- end among VNFs Infrastructure (NFVI) to provide end-to-end connectivity among VNFs
(Virtual Network Functions) or among VNFs and PNFs (Physical Network (Virtual Network Functions) or among VNFs and PNFs (Physical Network
Functions). A second level is the control and configuration of the Functions). A second level is the control and configuration of the
VNFs themselves (in other words, the configuration of the network VNFs themselves (in other words, the configuration of the network
service implemented by those VNFs), taking profit of the service implemented by those VNFs), which benefits from the
programmability brought by SDN. Both control concerns are separated programmability brought by SDN. The two control concerns are
in nature. However, interaction between both could be expected in separate in nature. However, interaction between the two can be
order to optimize, scale or influence each other. expected in order to optimize, scale, or influence one another.
7.2. Abstraction and Control of Transport Networks 7.2. Abstraction and Control of TE Networks
Abstraction and Control of Transport Networks (ACTN) [RFC8453] Abstraction and Control of TE Networks (ACTN) [RFC8453] presents a
presents a framework to allow the creation of virtual networks to be framework that allows the creation of virtual networks to be offered
offered to customers. The concept of provider in ACTN is limited to to customers. The concept of "provider" in ACTN is limited to the
the offering of virtual network services. These services are offering of virtual network services. These services are essentially
essentially transport services, and would correspond to the Transport transport services and would correspond to the Transport Stratum in
Stratum in CLAS. On the other hand, the Service Stratum in CLAS can CLAS. On the other hand, the Service Stratum in CLAS can be
be assimilated as a customer in the context of ACTN. assimilated as a customer in the context of ACTN.
ACTN defines a hierarchy of controllers for facilitating the creation ACTN defines a hierarchy of controllers to facilitate the creation
and operation of the virtual networks. An interface is defined for and operation of the virtual networks. An interface is defined for
the relation of the customers requesting these virtual networks the relationship between the customers requesting these virtual
services with the controller in charge of orchestrating and serving network services and the controller in charge of orchestrating and
such request. Such interface is equivalent to the one defined in serving such a request. Such an interface is equivalent to the one
Figure 1 (Section 3) between Service and Transport Strata. defined in Figure 1 (Section 3) between the Service and Transport
Strata.
8. Challenges for Implementing Actions Between Service and Transport 8. Challenges for Implementing Actions between Service and Transport
Strata Strata
The distinction of service and transport concerns raises a number of The distinction of service and transport concerns raises a number of
challenges in the communication between both strata. The following challenges in the communication between the two strata. The
is a work-in-progress list reflecting some of the identified following list reflects some of the identified challenges:
challenges:
o Standard mechanisms for interaction between layers: Nowadays there o Standard mechanisms for interaction between layers: Nowadays,
are a number of proposals that could accommodate requests from the there are a number of proposals that could accommodate requests
service stratum to the transport stratum. from the Service Stratum to the Transport Stratum.
Some of them could be solutions like the Connectivity Provisioning Some of the proposals could be solutions like the Connectivity
Protocol [I-D.boucadair-connectivity-provisioning-protocol] or the Provisioning Negotiation Protocol [CPNP] or the Intermediate-
Intermediate-Controller Plane Interface (I-CPI) [ONFArch]. Controller Plane Interface (I-CPI) [ONFArch].
Other potential candidates could be the Transport API [TAPI] or Other potential candidates could be the Transport API [TAPI] or
the Transport Transport Northbound Interface the Transport Northbound Interface [TRANS-NORTH]. Each of these
[I-D.ietf-ccamp-transport-nbi-app-statement]. Each of these options has a different scope.
options has a different status of maturity and scope.
o Multi-provider awareness: In multi-domain scenarios involving more o Multi-provider awareness: In multi-domain scenarios involving more
than one provider at transport level, the service stratum could than one provider at the transport level, the Service Stratum may
have or not awareness of such multiplicity of domains. or may not be aware of such multiplicity of domains.
If the service stratum is unaware of the multi-domain situation, If the Service Stratum is unaware of the multi-domain situation,
then the Transport Stratum acting as entry point of the service then the Transport Stratum acting as the entry point of the
stratum request should be responsible of managing the multi-domain Service Stratum request should be responsible for managing the
issue. multi-domain issue.
On the contrary, if the service stratum is aware of the multi- On the contrary, if the Service Stratum is aware of the multi-
domain situation, it should be in charge of orchestrating the domain situation, it should be in charge of orchestrating the
requests to the different underlying Transport Strata for requests to the different underlying Transport Strata to compose
composing the final end-to-end path among service end-points the final end-to-end path among service endpoints (i.e., service
(i.e., service functions). functions).
o SLA mapping: Both strata will handle SLAs but the nature of those o SLA mapping: Both strata will handle SLAs, but the nature of those
SLAs could differ. Then it is required for the entities in each SLAs could differ. Therefore, it is required for the entities in
stratum to map service SLAs to connectivity SLAs in order to each stratum to map service SLAs to connectivity SLAs in order to
ensure proper service delivery. ensure proper service delivery.
o Association between strata: The association between strata could o Association between strata: The association between strata could
be configured beforehand, or could be dynamic following mechanisms be configured beforehand, or both strata could require the use of
of discovery, that could be required to be supported by both a discovery mechanism that dynamically establishes the association
strata with this purpose. between the strata.
o Security: As reflected before, the communication between strata o Security: As reflected before, the communication between strata
must be secure preventing attacks and threats. Additionally, must be secure to prevent attacks and threats. Additionally,
privacy should be enforced, especially when addressing multi- privacy should be enforced, especially when addressing multi-
provider scenarios at transport level. provider scenarios at the transport level.
o Accounting: The control and accountancy of resources used and o Accounting: The control and accountancy of resources used and
consumed by services should be supported in the communication consumed by services should be supported in the communication
among strata. among strata.
9. IANA Considerations 9. IANA Considerations
This document does not request any action from IANA. This document has no IANA actions.
10. Security Considerations 10. Security Considerations
The CLAS architecture relies upon the functional entities that are The CLAS architecture relies upon the functional entities that are
introduced in [RFC7149] and [RFC7426]. As such security introduced in [RFC7149] and [RFC7426]. As such, security
considerations discussed in Section 5 of [RFC7149], in particular, considerations discussed in Section 5 of [RFC7149], in particular,
must be taken into account. must be taken into account.
The communication between the service and transport SDN controllers The communication between the service and transport SDN controllers
must rely on secure means which achieve the following: must rely on secure means that achieve the following:
o Mutual authentication must be enabled before taking any action. o Mutual authentication must be enabled before taking any action.
o Message integrity protection. o Message integrity protection.
Each of the controllers must be provided with instructions about the Each of the controllers must be provided with instructions regarding
set of information (and granularity) that can be disclosed to a peer the set of information (and granularity) that can be disclosed to a
controller. Means to prevent leaking privacy data (e.g., from the peer controller. Means to prevent the leaking of privacy data (e.g.,
service stratum to the transport stratum) must be enabled. The exact from the Service Stratum to the Transport Stratum) must be enabled.
set of information to be shared is deployment-specific. The exact set of information to be shared is deployment specific.
A corrupted controller may induce some disruption on another A corrupted controller may induce some disruption on another
controller. Guards against such attacks should be enabled. controller. Protection against such attacks should be enabled.
Security in the communication between the strata here described Security in the communication between the strata described here
should apply on the APIs (and/or protocols) to be defined among them. should apply to the APIs (and/or protocols) to be defined among them.
In consequence, security concerns will correspond to the specific Consequently, security concerns will correspond to the specific
solution. solution.
11. Acknowledgements 11. References
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.
12. References
12.1. Normative References
[Y.2011] "General principles and general reference model for Next
Generation Networks", ITU-T Recommendation Y.2011 ,
October 2004.
12.2. Informative References 11.1. Normative References
[ETSI_NFV_EVE005] [Y.2011] International Telecommunication Union, "General principles
"Report on SDN Usage in NFV Architectural Framework", and general reference model for Next Generation Networks",
December 2015. ITU-T Recommendation Y.2011, October 2004,
<https://www.itu.int/rec/T-REC-Y.2011-200410-I/en>.
[I-D.boucadair-connectivity-provisioning-protocol] 11.2. Informative References
Boucadair, M., Jacquenet, C., Zhang, D., and P.
Georgatsos, "Connectivity Provisioning Negotiation
Protocol (CPNP)", draft-boucadair-connectivity-
provisioning-protocol-15 (work in progress), December
2017.
[I-D.ietf-ccamp-transport-nbi-app-statement] [CPNP] Boucadair, M., Jacquenet, C., Zhang, D., and
Busi, I., King, D., Zheng, H., and Y. Xu, "Transport P. Georgatsos, "Connectivity Provisioning Negotiation
Northbound Interface Applicability Statement", draft-ietf- Protocol (CPNP)", Work in Progress, draft-boucadair-
ccamp-transport-nbi-app-statement-04 (work in progress), connectivity-provisioning-protocol-15, December 2017.
November 2018.
[I-D.irtf-sdnrg-layered-sdn] [GSNFV-EVE005]
Contreras, L., Bernardos, C., Lopez, D., Boucadair, M., ETSI, "Network Functions Virtualisation (NFV); Ecosystem;
and P. Iovanna, "Cooperating Layered Architecture for Report on SDN Usage in NFV Architectural Framework", ETSI
SDN", draft-irtf-sdnrg-layered-sdn-01 (work in progress), GS NFV-EVE 005, V1.1.1, December 2015,
October 2016. <https://www.etsi.org/deliver/etsi_gs/
NFV-EVE/001_099/005/01.01.01_60/
gs_nfv-eve005v010101p.pdf>.
[ONFArch] Open Networking Foundation, "SDN Architecture, Issue 1", [ONFArch] Open Networking Foundation, "SDN Architecture, Issue 1",
June 2014, June 2014, <https://www.opennetworking.org/images/stories/
<https://www.opennetworking.org/images/stories/downloads/ downloads/sdn-resources/technical-reports/
sdn-resources/technical-reports/
TR_SDN_ARCH_1.0_06062014.pdf>. TR_SDN_ARCH_1.0_06062014.pdf>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>. <https://www.rfc-editor.org/info/rfc7149>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297, Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014, DOI 10.17487/RFC7297, July 2014,
skipping to change at page 18, line 39 skipping to change at page 18, line 23
Architecture for Information Exchange between Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206, Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016, RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>. <https://www.rfc-editor.org/info/rfc7926>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. <https://www.rfc-editor.org/info/rfc8453>.
[TAPI] "Functional Requirements for Transport API", June 2016. [SDN-ARCH] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M.,
and P. Iovanna, "Cooperating Layered Architecture for
SDN", Work in Progress, draft-irtf-sdnrg-layered-sdn-01,
October 2016.
Appendix A. Relationship with RFC7426 [TAPI] Open Networking Foundation, "Functional Requirements for
Transport API", June 2016,
<https://www.opennetworking.org/wp-content/uploads/
2014/10/TR-527_TAPI_Functional_Requirements.pdf>.
[TRANS-NORTH]
Busi, I., King, D., Zheng, H., and Y. Xu, "Transport
Northbound Interface Applicability Statement", Work in
Progress, draft-ietf-ccamp-transport-nbi-app-statement-05,
March 2019.
Appendix A. Relationship with RFC 7426
[RFC7426] introduces an SDN taxonomy by defining a number of planes, [RFC7426] introduces an SDN taxonomy by defining a number of planes,
abstraction layers, and interfaces or APIs among them, as a means of abstraction layers, and interfaces or APIs among them as a means of
clarifying how the different parts constituent of SDN (network clarifying how the different parts constituent of SDN (network
devices, control and management) relate among them. A number of devices, control and management) relate. A number of planes are
planes are defined, namely: defined, including:
o Forwarding Plane: focused on delivering packets in the data path o Forwarding Plane: focused on delivering packets in the data path
based on the instructions received from the control plane. based on the instructions received from the control plane.
o Operational Plane: centered on managing the operational state of o Operational Plane: centered on managing the operational state of
the network device. the network device.
o Control Plane: devoted to instruct the device on how packets o Control Plane: dedicated to instructing the device on how packets
should be forwarded. should be forwarded.
o Management Plane: in charge of monitoring and maintaining network o Management Plane: in charge of monitoring and maintaining network
devices. devices.
o Application Plane: enabling the usage for different purposes (as o Application Plane: enabling the usage for different purposes (as
determined by each application) of all the devices controlled in determined by each application) of all the devices controlled in
this manner. this manner.
Apart from that, [RFC7426] proposes a number of abstraction layers Apart from these, [RFC7426] proposes a number of abstraction layers
that permit the integration of the different planes through common that permit the integration of the different planes through common
interfaces. CLAS focuses on Control, Management and Resource planes interfaces. CLAS focuses on control, management, and resource planes
as the basic pieces of its architecture. Essentially, the control as the basic pieces of its architecture. Essentially, the control
plane modifies the behavior and actions of the controlled resources. plane modifies the behavior and actions of the controlled resources.
The management plane monitors and retrieves the status of those The management plane monitors and retrieves the status of those
resources. And finally, the resource plane groups all the resources resources. And finally, the resource plane groups all the resources
related to the concerns of each strata. related to the concerns of each stratum.
From this point of view, CLAS planes can be seen as a superset of 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 those defined in [RFC7426]. However, in some cases, not all the
in [RFC7426] could not be totally present in CLAS representation planes considered in [RFC7426] may be totally present in CLAS
(e.g., forwarding plane in Service Stratum). representation (e.g., the forwarding plane in the Service Stratum).
Being said that, internal structure of CLAS strata could follow the That being said, the internal structure of CLAS strata could follow
taxonomy defined in [RFC7426]. Which is differential is the the taxonomy defined in [RFC7426]. What is different is the
specialization of the SDN environments, through the distinction specialization of the SDN environments through the distinction
between service and transport. between service and transport.
Acknowledgements
This document was previously discussed and adopted in the IRTF SDN RG
as [SDN-ARCH]. After the closure of the IRTF SDN RG, this document
was progressed as an Independent Submission to record (some of) that
group's discussions.
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.
Authors' Addresses Authors' Addresses
Luis M. Contreras Luis M. Contreras
Telefonica Telefonica
Ronda de la Comunicacion, s/n Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor Sur-3 building, 3rd floor
Madrid 28050 Madrid 28050
Spain Spain
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
 End of changes. 145 change blocks. 
401 lines changed or deleted 406 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/