wdiff rfc8597.alt-original rfc8597.txt

Network Working Group
Independent Submission LM. Contreras
Internet-Draft
Request for Comments: 8597 Telefonica
Intended status:
Category: Informational CJ. Bernardos
Expires: May 25, 2019
ISSN: 2070-1721 UC3M
D. Lopez
Telefonica
M. Boucadair
Orange
P. Iovanna
Ericsson
November 21, 2018
May 2019

Cooperating Layered Architecture for Software Defined Software-Defined Networking (CLAS)
draft-contreras-layered-sdn-03

Abstract

Software Defined

Software-Defined Networking adheres to (SDN) advocates for 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 service intelligence is moved to these control
entities. Typically, such an entity is seen as a compendium of
interacting control functions in a vertical, tight tightly 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 rely
upon transport capabilities.

This document describes an approach named called Cooperating Layered
Architecture for Software Defined Networking. The idea behind that
is to differentiate Software-Defined Networking (CLAS), wherein the
control functions associated to with transport are differentiated from
those related to services, services in such a way that they can be provided and
maintained independently, independently and can follow their own evolution path.

Status of This Memo

This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not candidates for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list Standard;
see Section 2 of RFC 7841.

Information about the current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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.
https://www.rfc-editor.org/info/rfc8597.

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 5
3.1. Functional Strata . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Transport Stratum . . . . . . . . . . . . . . . . . . 9
3.1.2. Service Stratum . . . . . . . . . . . . . . . . . . . 10
3.1.3. Recursiveness . . . . . . . . . . . . . . . . . . . . 10
3.2. Plane Separation . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Management Plane . . . . . . . . . . . . . . . . . . 11
3.2.3. Resource Plane . . . . . . . . . . . . . . . . . . . 11
4. Required Features . . . . . . . . . . . . . . . . . . . . . . 11
5. Communication Between between SDN Controllers . . . . . . . . . . . . 12
6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 12
6.1. Full SDN Environments . . . . . . . . . . . . . . . . . . 12 13
6.1.1. Multiple Service Strata Associated to with a Single
Transport Stratum . . . . . . . . . . . . . . . . . . 13
6.1.2. Single Service Stratum associated to multiple Associated with Multiple
Transport Strata . . . . . . . . . . . . . . . . . . 13
6.2. Hybrid Environments . . . . . . . . . . . . . . . . . . . 13
6.2.1. SDN Service Stratum associated to Associated with a Legacy
Transport Stratum . . . . . . . . . . . . . . . . . . . . . . . 13
6.2.2. Legacy Service Stratum Associated to with an SDN
Transport Stratum . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Multi-domain Scenarios in the Transport Stratum . . . . . . . 13 14
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Network Function Virtualization (NFV) . . . . . . . . . . 14
7.2. Abstraction and Control of Transport TE Networks . . . . . . 14 . . . 15
8. Challenges for Implementing Actions Between between Service and
Transport Strata . . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . 17
12.1. Normative References . . . . . . . . . . . 17
Appendix A. Relationship with RFC 7426 . . . . . . . 17
12.2. Informative References . . . . . . 18
Acknowledgements . . . . . . . . . . . 17
Appendix A. Relationship with RFC7426 . . . . . . . . . . . . . 18 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 20

1. Introduction

Network softwarization advances are facilitating the introduction of
programmability in the services and infrastructures of telco
operators. This is generally achieved generically through the introduction of Software
Defined
Software-Defined Networking (SDN, [RFC7149][RFC7426]) (SDN) [RFC7149] [RFC7426] capabilities in
the network, including controllers and orchestrators.

However, there are concerns of a different nature that these SDN
capabilities have to resolve. In On the one hand there is a need for hand, actions focused on
programming the network for to handle the connectivity or forwarding of
digital data between distant nodes. nodes are needed. On the other hand, there is a need for
actions devoted to program programming the functions or services that process
(or manipulate) such digital data. data are also needed.

SDN adheres to advocates for 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 entity, which is
commonly referred as SDN Controller; Controller, to be centralized; 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
traffic-forwarding behavior accordingly. Additional Support for additional
capabilities (e.g., performance monitoring, fault management, etc.)
could be expected to
be supported through such this kind of programmatic interface
[RFC7149].

Most of the intelligence is moved to such this kind of functional entity.
Typically, such an entity is seen as a compendium of interacting
control functions in a vertical, tight tightly 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:

o From a provider perspective, where usually different departments usually
are responsible of for handling service and connectivity (i.e.,
transport capabilities for the service on top), the mentioned
approach offers unclear responsibilities for complete 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, especially in
situations where a one provider provides just only connectivity while
another provider offers a more sophisticated service on top of
that connectivity.

o Complex service/network diagnosis and troubleshooting,
particularly to determine which segment layer is responsible for a
failure.

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], [Y.2011] and also as
defined in Section 2 of this document.

This document describes an approach named called Cooperating Layered
Architecture for SDN (CLAS). The idea behind that is to
differentiate (CLAS), wherein the control functions associated to
with transport are differentiated from those related to services, services in
such a way that they can be provided and maintained independently, independently and
can follow their own evolution path.

Despite such differentiation it is required a differentiation, close cooperation between the service
and transport layers (or strata in [Y.2011]) and the associated
components are necessary to provide an efficient usage of the resources.

2. Terminology

This document makes use of the following terms:

o Transport: denotes the transfer capabilities offered by a
networking infrastructure. The transfer capabilities can rely
upon pure IP techniques, techniques or other means means, such as MPLS or optics.

o Service: denotes a logical construct that makes use of transport
capabilities.

This document does not make any assumption on assumptions about the functional
perimeter of a service that can be built above a transport
infrastructure. As such, a service can be an offering that is offered to customers or be
invoked for the delivery of another (added-value) service.

o Layer: refers to the set of elements comprised for enabling that enable either transport
or service capabilities capabilities, as defined before. previously. In [Y.2011], this
is referred to as stratum, a "stratum", and both the two terms are used
interchangeably.

o Domain: is a set of elements which that share a common property or
characteristic. In this document this document, it applies to the
administrative domain (i.e., elements pertaining to the same
organization), technological domain (elements implementing the
same kind of technology, such as for example optical nodes), etc.

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
controllers.

The intelligence can be centralized or distributed. Both schemes
are within the scope of this document.

The

An SDN intelligence Intelligence relies on inputs form from various functional
blocks
blocks, such as: network topology discovery, service topology
discovery, resource allocation, business guidelines, customer
profiles, service profiles, etc.

The exact decomposition of an SDN intelligence, Intelligence, apart from the
layering discussed in this document, here, is out of scope. the scope of this document.

Additionally, the following acronyms are used in this document:

CLAS: Cooperating Layered Architecture for SDN

FCAPS: Fault, Configuration, Accounting, Performance Performance, and Security

SDN: Software Defined Software-Defined Networking

SLA: Service Level Agreement

3. Architecture Overview

Current operator networks support multiple services (e.g., VoIP, Voice over
IP (VoIP), IPTV, mobile VoIP, critical mission applications, etc.) on
a variety of transport technologies. The provision and delivery of a
service
independently independent of the underlying transport capabilities require
a separation of the service related service-related functionalities and an
abstraction of the transport network to hide the specificities of the
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 infrastructure; similarly, different technologies
can accommodate the connectivity requirements of a certain service. A close
Close coordination among them these elements is required for a consistent
service delivery (inter-layer cooperation).

This document focuses particularly on: on the means to:

o Means to expose transport capabilities to services.

o Means to capture service transport requirements of services.

o Means to notify service intelligence with of underlying transport events, for example
example, to adjust a service decision-making process with
underlying transport events.

o Means to instruct the underlying transport capabilities to accommodate new
requirements, etc.

An example is to guarantee guaranteeing some Quality of Service Quality-of-Service (QoS) levels.
Different QoS-based offerings could be present at both the 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 into 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 Next Generation Network (NGN) architecture defined
by the ITU-T in [Y.2011], where two strata of functionality are defined, namely
defined. These strata are the Service Stratum, comprising the
service-related functions, and the
Connectivity Transport Stratum, covering the transport ones.
transport-related functions. The functions on of each of these layers
are further grouped on into the control, management management, and user (or data)
planes.

CLAS adopts the same structured model described in [Y.2011] but
applying
applies it to the objectives of programmability through SDN
[RFC7149]. To In 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 architecture, both the control and management functions
are considered to be performed by one or a set of SDN controllers
(due to, e.g., for example, scalability, reliability) reliability), providing the SDN
Intelligence,
Intelligence in such a way that separated SDN controllers are present
in the Service and Transport strata. Strata. Management functions are
considered to be part of the SDN Intelligence to allow the for effective
operation in a service provider ecosystem [RFC7149] despite [RFC7149], although some
initial propositions did not consider such management as part of the
SDN environment [ONFArch].

Furthermore, the generic user user- or data plane data-plane functions included in
the NGN architecture are referred to here as resource plane 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 in the provision and delivery of
services. There is a hierarchy in which the Service SDN Intelligence
makes requests transport capabilities to of the Transport SDN Intelligence. Intelligence for the provision of
transport capabilities.

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 being 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 Stratum could offer an interface
towards
to applications to expose network service capabilities to those
applications or customers.

3.1. Functional Strata

As described before, the aforementioned, there is a functional split that 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.

3.1.1. Transport Stratum

The Transport Stratum comprises the functions focused on the transfer
of data between the communication end points endpoints (e.g., between end-user
devices, between two service gateways, etc.). The data forwarding data-forwarding
nodes are controlled and managed by the Transport SDN component.

The Control control plane in the SDN Intelligence is in charge of instructing
the forwarding devices to build the end to end end-to-end data path for each
communication or to make sure the forwarding service is appropriately
setup.
set up. Forwarding may not be rely solely on the sole pre-configured preconfigured
entries; dynamic means can be enabled so that involved nodes can
build dynamically
build routing and forwarding paths (this would require that the nodes
retain some of the control and management capabilities for enabling
this). Finally, the Management management plane performs management functions
(i.e., FCAPS) on those devices, like fault or performance management,
as part of the Transport Stratum capabilities.

3.1.2. Service Stratum

The Service stratum Stratum contains the functions related to the provision
of services and the capabilities offered to external applications.
The Resource resource plane consists of the resources involved in the service
delivery, such as computing resources, registries, databases, etc.

The Control control plane is in charge of controlling and configuring those
resources,
resources as well as interacting with the Control control plane of the
Transport stratum Stratum in client mode for requesting to request transport capabilities
for a given service. In the same way, the Management management plane
implements management actions on the service-related resources and
interacts with the Management management plane in the Transport Stratum for
a cooperating to
ensure management cooperation between layers.

3.1.3. Recursiveness

Recursive layering can happen in some usage scenarios in which the
Transport Stratum is itself structured in the Service and Transport
Stratum.
Strata. This could be the case of in the provision of a transport
service complemented with advanced capabilities additional in addition to the
pure data transport (e.g., maintenance of a given SLA [RFC7297]).

Recursiveness has been also been discussed in [ONFArch] as a way of
reaching scalability and modularity, when where each higher level can
provide greater abstraction capabilities. Additionally,
recursiveness can allow some scenarios for multi-domain scenarios where single or
multiple administrative domains are involved, such as the ones those described
in Section 6.3.

3.2. Plane Separation

The CLAS architecture leverages on plane separation. As mentioned
before, in
Sections 3.1.1 and 3.1.2, three different planes are considered for
each stratum. The communication among these three planes (and with (with the
corresponding plane in other strata) is based on open, standard
interfaces.

3.2.1. Control Plane

The Control 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 an SDN architecture.
This plane is part of an SDN Intelligence, Intelligence and can interact with other
control planes in the same or different strata for accomplishing to perform control
functions.

3.2.2. Management Plane

The Management management plane logically centralizes the management functions
for each stratum, including the management of the Control control and
Resource
resource planes. [RFC7426] describes the functions of the management
plane in a an SDN environment. This plane is also part of the SDN
Intelligence,
Intelligence and can interact with the corresponding management
planes residing in SDN controllers of the same or different strata.

3.2.3. Resource Plane

The Resource resource plane comprises the resources for either the transport
or the service functions. In some cases cases, the service resources can
be connected to the transport ones (e.g., being the terminating
points of a transport function) whereas function); in other cases cases, it can be decoupled
from the transport resources (e.g., one database keeping some a register
for the end user). Both the forwarding and operational planes
proposed in [RFC7426] would be part of the Resource resource plane in this
architecture.

4. Required Features

Since the CLAS architecture implies the interaction of different
layers with different purposes and responsibilities, a number of
features are required to be supported:

o Abstraction: the mapping of physical resources into the
corresponding abstracted resources.

o Service parameter translation: Service-Parameter Translation: the translation of service
parameters (e.g., in the form of SLAs) to transport parameters (or
capabilities) according to different policies.

o Monitoring: mechanisms (e.g., event notifications) available in
order to dynamically update the (abstracted) resources' status
while taking in to into account, e.g., for example, the traffic load.

o Resource computation: Computation: functions able to decide which resources
will be used for a given service request. As an example,
functions like PCE could be used to compute/select/decide a
certain path.

o Orchestration: the ability to combine diverse resources (e.g., IT
and network resources) in an optimal way.

o Accounting: record of resource usage.

o Security: secure communication among components, preventing, e.g., for
example, DoS attacks.

5. Communication Between between SDN Controllers

The SDN controllers residing respectively in the Service and the
Transport Stratum Strata need to establish a tight coordination. Mechanisms
for transfer transferring 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 case, the Service SDN Intelligence could be able of handling to handle
complete information about the transport capabilities (including
resources) offered by the Transport Stratum. In the latter case, the
Transport Stratum exposes reveals the available capabilities, e.g., for example,
through a catalog, reducing the amount of detail of the underlying
network.

On the other hand, the Transport Stratum requires to must properly capture the
Service requirements. These can include SLA requirements with
specific metrics (such as delay), the level of protection to be
provided,
max/min maximum/minimum capacity, applicable resource constraints,
etc.

The communication between controllers must be also be secure, e.g., by
preventing denial of service or any other kind of threats threat (similarly,
the
communications with the network nodes must be secure).

6. Deployment Scenarios

Different situations can be found depending on the characteristics of
the networks involved in a given deployment.

6.1. Full SDN Environments

This case considers that the networks involved in the provision and
delivery of a given service have SDN capabilities.

6.1.1. Multiple Service Strata Associated to with a Single Transport
Stratum

A single Transport Stratum can provide transfer functions to more
than one Service strata. Stratum. The Transport Stratum offers a standard
interface(s) to each of the Service strata. Strata. The Service strata Strata are
the clients of the Transport Stratum. Some of the capabilities
offered by the Transport stratum Stratum can be isolation of the transport
resources (slicing), independent routing, etc.

6.1.2. Single Service Stratum associated to multiple Associated with Multiple Transport Strata

A single Service stratum Stratum can make use of different Transport Strata
for the provision of a certain service. The Service stratum Stratum invokes
standard interfaces to each of the Transport Strata with standard protocols, Strata, and orchestrates
the provided transfer capabilities for building the end
to end end-to-end
transport needs.

6.2. Hybrid Environments

This case considers scenarios where one of the strata is legacy totally or in part.
partly legacy.

6.2.1. SDN Service Stratum associated to Associated with a Legacy Transport Stratum

An SDN service stratum Stratum can interact with a legacy Transport Stratum
through some an interworking function that is able to adapt SDN-based
control and management service-related commands to legacy transport-related transport-
related protocols, as expected by the legacy Transport Stratum.

The SDN Intelligence in the Service stratum Stratum is not aware of the
legacy nature of the underlying Transport Stratum.

6.2.2. Legacy Service Stratum Associated to with an SDN Transport Stratum

A legacy Service stratum Stratum can work with an SDN-enabled Transport
Stratum through the mediation of and an interworking function capable to
interpret of
interpreting commands from the legacy service functions and translate
translating them into SDN protocols for operating operation with the SDN-enabled SDN-
enabled Transport Stratum.

6.3. Multi-domain Scenarios in the Transport Stratum

The Transport Stratum can be composed by of transport resources being that are
part of different administrative, topological 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 stratum.
This service is focused on the provision of transport capabilities, then
which is different
of from the final communication service using such
capabilities.

In this particular case case, this recursion allows multi-domain scenarios
at the transport level.

Multi-domain situations can happen in both single-operator and multi-
operator scenarios.

In single operator scenarios single-operator scenarios, a multi-domain or end-to-end
abstraction component can provide an a homogeneous abstract view of the
underlying heterogeneous transport capabilities for all the domains.

Multi-operator scenarios, scenarios at the Transport Stratum, Stratum should support the
establishment of end-to-end paths in a programmatic manner across the
involved networks. This For example, this could be accomplished, for example, accomplished by
the exchange of traffic-engineered information of each
of the administrative domains exchanging their traffic-engineered
information [RFC7926].

7. Use Cases

This section presents a number of use cases as examples of the
applicability of the CLAS approach.

7.1. Network Function Virtualization (NFV)

NFV environments offer two possible levels of SDN control
[ETSI_NFV_EVE005].
[GSNFV-EVE005]. One level is the need for controlling to control the NFV
Infrastructure (NFVI) to provide end-to-end 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 which benefits from the
programmability brought by SDN. Both The two control concerns are separated
separate in nature. However, interaction between both could the two can be
expected in order to optimize, scale scale, or influence each other. one another.

7.2. Abstraction and Control of Transport TE Networks

Abstraction and Control of Transport TE Networks (ACTN) [RFC8453] presents a
framework to allow that allows the creation of virtual networks to be offered
to customers. The concept of provider "provider" in ACTN is limited to the
offering of virtual network services. These services are essentially
transport services, 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 to facilitate the creation
and operation of the virtual networks. An interface is defined for
the relation of relationship between the customers requesting these virtual networks
network services with and the controller in charge of orchestrating and
serving such a request. Such an interface is equivalent to the one
defined in Figure 1 (Section 3) between the Service and Transport
Strata.

8. Challenges for Implementing Actions Between between Service and Transport
Strata

The distinction of service and transport concerns raises a number of
challenges in the communication between both the two strata. The
following
is a work-in-progress list reflecting reflects some of the identified challenges:

o Standard mechanisms for interaction between layers: Nowadays Nowadays,
there are a number of proposals that could accommodate requests
from the
service stratum Service Stratum to the transport stratum. Transport Stratum.

Some of them the proposals could be solutions like the Connectivity
Provisioning Negotiation Protocol [I-D.boucadair-connectivity-provisioning-protocol] [CPNP] or the
Intermediate-Controller Intermediate-
Controller Plane Interface (I-CPI) [ONFArch].

Other potential candidates could be the Transport API [TAPI] or
the Transport Transport Northbound Interface
[I-D.ietf-ccamp-transport-nbi-app-statement]. [TRANS-NORTH]. Each of these
options has a different status of maturity and scope.

o Multi-provider awareness: In multi-domain scenarios involving more
than one provider at the transport level, the service stratum could
have Service Stratum may
or may not awareness be aware of such multiplicity of domains.

If the service stratum Service Stratum is unaware of the multi-domain situation,
then the Transport Stratum acting as the entry point of the service
stratum
Service Stratum request should be responsible of for managing the
multi-domain issue.

On the contrary, if the service stratum Service Stratum is aware of the multi-
domain situation, it should be in charge of orchestrating the
requests to the different underlying Transport Strata for
composing to compose
the final end-to-end path among service end-points endpoints (i.e., service
functions).

o SLA mapping: Both strata will handle SLAs SLAs, but the nature of those
SLAs could differ. Then Therefore, it is required for the entities in
each stratum to map service SLAs to connectivity SLAs in order to
ensure proper service delivery.

o Association between strata: The association between strata could
be configured beforehand, or both strata could be dynamic following mechanisms require the use of discovery,
a discovery mechanism that could be required to be supported by both
strata with this purpose. dynamically establishes the association
between the strata.

o Security: As reflected before, the communication between strata
must be secure preventing to prevent attacks and threats. Additionally,
privacy should be enforced, especially when addressing multi-
provider scenarios at the transport level.

o Accounting: The control and accountancy of resources used and
consumed by services should be supported in the communication
among strata.

9. IANA Considerations

This document does not request any action from IANA. has no IANA actions.

10. Security Considerations

The CLAS architecture relies upon the functional entities that are
introduced in [RFC7149] and [RFC7426]. As such 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 that achieve the following:

o Mutual authentication must be enabled before taking any action.

o Message integrity protection.

Each of the controllers must be provided with instructions about regarding
the set of information (and granularity) that can be disclosed to a
peer controller. Means to prevent the leaking of privacy data (e.g.,
from the
service stratum Service Stratum to the transport stratum) Transport Stratum) must be enabled.
The exact set of information to be shared is deployment-specific. deployment specific.

A corrupted controller may induce some disruption on another
controller. Guards Protection against such attacks should be enabled.

Security in the communication between the strata here described here
should apply on to the APIs (and/or protocols) to be defined among them.
In consequence,
Consequently, security concerns will correspond to the specific
solution.

12.

11. References

12.1.

11.1. Normative References

[Y.2011] International Telecommunication Union, "General principles
and general reference model for Next Generation Networks",
ITU-T Recommendation Y.2011 , Y.2011, October 2004.

12.2. 2004,
<https://www.itu.int/rec/T-REC-Y.2011-200410-I/en>.

11.2. Informative References

[ETSI_NFV_EVE005]
"Report on SDN Usage in NFV Architectural Framework",
December 2015.

[I-D.boucadair-connectivity-provisioning-protocol]

[CPNP] Boucadair, M., Jacquenet, C., Zhang, D., and P.
Georgatsos, "Connectivity Provisioning Negotiation
Protocol (CPNP)", draft-boucadair-connectivity-
provisioning-protocol-15 (work Work in progress), Progress, draft-boucadair-
connectivity-provisioning-protocol-15, December 2017.

[I-D.ietf-ccamp-transport-nbi-app-statement]
Busi, I., King, D., Zheng, H., and Y. Xu, "Transport
Northbound Interface Applicability Statement", draft-ietf-
ccamp-transport-nbi-app-statement-04 (work in progress),
November 2018.

[I-D.irtf-sdnrg-layered-sdn]
Contreras, L., Bernardos, C., Lopez, D., Boucadair, M.,
and P. Iovanna, "Cooperating Layered Architecture for
SDN", draft-irtf-sdnrg-layered-sdn-01 (work

[GSNFV-EVE005]
ETSI, "Network Functions Virtualisation (NFV); Ecosystem;
Report on SDN Usage in progress),
October 2016. NFV Architectural Framework", ETSI
GS NFV-EVE 005, V1.1.1, December 2015,
<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",
June 2014,
<https://www.opennetworking.org/images/stories/downloads/
sdn-resources/technical-reports/
TR_SDN_ARCH_1.0_06062014.pdf>.

[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>.

[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014,
<https://www.rfc-editor.org/info/rfc7297>.

[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>.

[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>.

[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.

[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.

[TAPI] Open Networking Foundation, "Functional Requirements for
Transport API", June 2016. 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 RFC7426 RFC 7426

[RFC7426] introduces an SDN taxonomy by defining a number of planes,
abstraction layers, and interfaces or APIs among them, them as a means of
clarifying how the different parts constituent of SDN (network
devices, control and management) relate among them. relate. A number of planes are
defined, namely: including:

o Forwarding Plane: focused on delivering packets in the data path
based on the instructions received from the control plane.

o Operational Plane: centered on managing the operational state of
the network device.

o Control Plane: devoted dedicated to instruct instructing the device on how packets
should be forwarded.

o Management Plane: in charge of monitoring and maintaining network
devices.

o Application Plane: enabling the usage for different purposes (as
determined by each application) of all the devices controlled in
this manner.

Apart from that, these, [RFC7426] proposes a number of abstraction layers
that permit the integration of the different planes through common
interfaces. CLAS focuses on Control, Management control, management, and Resource 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. stratum.

From this point of view, CLAS planes can be seen as a superset of
[RFC7426], even though
those defined in [RFC7426]. However, in some cases cases, not all the
planes as considered in [RFC7426] could not may be totally present in CLAS
representation (e.g., the forwarding plane in the Service Stratum).

Being said that,

That being said, the internal structure of CLAS strata could follow
the taxonomy defined in [RFC7426]. Which What is differential different is the
specialization of the SDN environments, environments through the distinction
between service and transport.

11.

Acknowledgements

This document was previously discussed and adopted in the IRTF SDN RG
as [I-D.irtf-sdnrg-layered-sdn]. [SDN-ARCH]. After the closure of the IRTF SDN
RG RG, this document is being
was progressed as Individual an Independent Submission to record (some of) that
group's disucussions. 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

Luis M. Contreras
Telefonica
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain

Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://lmcontreras.com

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
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain

Email: diego.r.lopez@telefonica.com

Mohamed Boucadair
Orange
Rennes 35000
France

Email: mohamed.boucadair@orange.com

Paola Iovanna
Ericsson
Pisa
Italy

Email: paola.iovanna@ericsson.com