    Independent Submission                                     LM. Contreras
    Request for Comments: 8597                                    Telefonica
    Category: Informational                                    CJ. Bernardos
    ISSN: 2070-1721                                                     UC3M
                                                                    D. Lopez
                                                                  Telefonica
                                                                M. Boucadair
                                                                      Orange
                                                                  P. Iovanna
                                                                    Ericsson
                                                                    May 2019

    Cooperating Layered Architecture for Software-Defined Networking (CLAS)

    Abstract

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

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

    Contreras, et al.             Informational                     [Page 1]

    RFC 8597                Layered SDN Architecture                May 2019

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for informational purposes.

       This is a contribution to the RFC Series, independently of any other
       RFC stream.  The RFC Editor has chosen to publish this document at
       its discretion and makes no statement about its value for
       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.

       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 (c) 2019 IETF Trust and the persons identified as the
       document authors.  All rights reserved.

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (https://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect
       to this document.

    Contreras, et al.             Informational                     [Page 2]

    RFC 8597                Layered SDN Architecture                May 2019

    Table of Contents

       1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   6
         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 SDN Controllers . . . . . . . . . . . .  12
       6.  Deployment Scenarios  . . . . . . . . . . . . . . . . . . . .  12
         6.1.  Full SDN Environments . . . . . . . . . . . . . . . . . .  13
           6.1.1.  Multiple Service Strata Associated with a Single
                   Transport Stratum . . . . . . . . . . . . . . . . . .  13
           6.1.2.  Single Service Stratum Associated with Multiple
                   Transport Strata  . . . . . . . . . . . . . . . . . .  13
         6.2.  Hybrid Environments . . . . . . . . . . . . . . . . . . .  13
           6.2.1.  SDN Service Stratum Associated with a Legacy
                   Transport Stratum . . . . . . . . . . . . . . . . . .  13
           6.2.2.  Legacy Service Stratum Associated with an SDN
                   Transport Stratum . . . . . . . . . . . . . . . . . .  13
         6.3.  Multi-domain Scenarios in the Transport Stratum . . . . .  14
       7.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  14
         7.1.  Network Function Virtualization (NFV) . . . . . . . . . .  14
         7.2.  Abstraction and Control of TE Networks  . . . . . . . . .  15
       8.  Challenges for Implementing Actions between Service and
           Transport Strata  . . . . . . . . . . . . . . . . . . . . . .  15
       9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
       10. Security Considerations . . . . . . . . . . . . . . . . . . .  16
       11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
         11.1.  Normative References . . . . . . . . . . . . . . . . . .  17
         11.2.  Informative References . . . . . . . . . . . . . . . . .  17
       Appendix A.  Relationship with RFC 7426 . . . . . . . . . . . . .  19
       Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
       Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

    Contreras, et al.             Informational                     [Page 3]

    RFC 8597                Layered SDN Architecture                May 2019

    1.  Introduction

       Network softwarization advances are facilitating the introduction of
       programmability in the services and infrastructures of
       telecommunications operators.  This is generally achieved through the
       introduction of Software-Defined Networking (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.  On the one hand, actions focused on
       programming the network to handle the connectivity or forwarding of
       digital data between distant nodes are needed.  On the other hand,
       actions devoted to programming the functions or services that process
       (or manipulate) such digital data are also needed.

       SDN advocates for the separation of the control plane from the data
       plane in the network nodes by introducing abstraction among both
       planes, allowing the control logic on a functional entity, which is
       commonly referred as SDN 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 behavior accordingly.  Support for additional
       capabilities (e.g., performance monitoring, fault management, etc.)
       could be expected through this kind of programmatic interface
       [RFC7149].

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

    Contreras, et al.             Informational                     [Page 4]

    RFC 8597                Layered SDN Architecture                May 2019

       o  Difficult interoperability and interchangeability of functional
          components.

       o  Blurred business boundaries among providers, especially in
          situations where one provider provides 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 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] and as
       defined in Section 2 of this document.

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

       Despite such differentiation, close cooperation between the service
       and transport layers (or strata in [Y.2011]) and the associated
       components are necessary to provide 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 or other means, such as MPLS or optics.

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

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

    Contreras, et al.             Informational                     [Page 5]

    RFC 8597                Layered SDN Architecture                May 2019

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

       o  Domain: is a set of elements that share a common property or
          characteristic.  In 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 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.

          An SDN Intelligence relies on inputs from various functional
          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, apart from the
          layering discussed here, is out of 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, and Security

          SDN: Software-Defined Networking

          SLA: Service Level Agreement

    3.  Architecture Overview

       Current operator networks support multiple services (e.g., Voice over
       IP (VoIP), IPTV, mobile VoIP, critical mission applications, etc.) on
       a variety of transport technologies.  The provision and delivery of a
       service independent of the underlying transport capabilities require
       a separation of the service-related functionalities and an
       abstraction of the transport network to hide the specifics of the
       underlying transfer techniques while offering a common set of
       capabilities.

    Contreras, et al.             Informational                     [Page 6]

    RFC 8597                Layered SDN Architecture                May 2019

       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; similarly, different technologies
       can accommodate the connectivity requirements of a certain service.
       Close coordination among these elements is required for consistent
       service delivery (inter-layer cooperation).

       This document focuses particularly on the means to:

       o  expose transport capabilities to services.

       o  capture transport requirements of services.

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

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

       An example is guaranteeing some 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 quality
       guarantees to the end user.

       CLAS architecture assumes that the logically centralized control
       functions are separated 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 Next Generation Network (NGN) architecture defined
       by the ITU-T in [Y.2011], where two strata of functionality are
       defined.  These strata are the Service Stratum, comprising the
       service-related functions, and the Transport Stratum, covering the
       transport-related functions.  The functions of each of these layers
       are further grouped into the control, management, and user (or data)
       planes.

       CLAS adopts the same structured model described in [Y.2011] but
       applies it to the objectives of programmability through SDN
       [RFC7149].  In this respect, CLAS advocates for addressing services
       and transport in a separated manner because of their differentiated
       concerns.

    Contreras, et al.             Informational                     [Page 7]

    RFC 8597                Layered SDN Architecture                May 2019

                                           Applications
                                                /\
                                                ||
                                                ||
          +-------------------------------------||-------------+
          | Service Stratum                     ||             |
          |                                     \/             |
          |                       ...........................  |
          |                       . SDN Intelligence        .  |
          |                       .                         .  |
          |  +--------------+     .        +--------------+ .  |
          |  | Resource Pl. |     .        |   Mgmt. Pl.  | .  |
          |  |              |<===>.  +--------------+     | .  |
          |  |              |     .  |  Control Pl. |     | .  |
          |  +--------------+     .  |              |-----+ .  |
          |                       .  |              |       .  |
          |                       .  +--------------+       .  |
          |                       ...........................  |
          |                                     /\             |
          |                                     ||             |
          +-------------------------------------||-------------+
                                                ||    Standard
                                             -- || --    API
                                                ||
          +-------------------------------------||-------------+
          | Transport Stratum                   ||             |
          |                                     \/             |
          |                       ...........................  |
          |                       . SDN Intelligence        .  |
          |                       .                         .  |
          |  +--------------+     .        +--------------+ .  |
          |  | Resource Pl. |     .        |   Mgmt. Pl.  | .  |
          |  |              |<===>.  +--------------+     | .  |
          |  |              |     .  |  Control Pl. |     | .  |
          |  +--------------+     .  |              |-----+ .  |
          |                       .  |              |       .  |
          |                       .  +--------------+       .  |
          |                       ...........................  |
          |                                                    |
          |                                                    |
          +----------------------------------------------------+

                Figure 1: Cooperating Layered Architecture for SDN

    Contreras, et al.             Informational                     [Page 8]

    RFC 8597                Layered SDN Architecture                May 2019

       In the CLAS architecture, both the control and management functions
       are considered to be performed by one or a set of SDN controllers
       (due to, for example, scalability, reliability), providing the SDN
       Intelligence in such a way that separated SDN controllers are present
       in the Service and Transport Strata.  Management functions are
       considered to be part of the SDN Intelligence to allow for effective
       operation in a service provider ecosystem [RFC7149], although some
       initial propositions did not consider such management as part of the
       SDN environment [ONFArch].

       Furthermore, the generic user- or data-plane functions included in
       the NGN architecture are referred to here as resource-plane
       functions.  The resource plane in each stratum is controlled by the
       corresponding SDN Intelligence through a standard interface.

       The SDN controllers cooperate in the provision and delivery of
       services.  There is a hierarchy in which the Service 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
       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 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 could offer an interface
       to applications to expose network service capabilities to those
       applications or customers.

    3.1.  Functional Strata

       As aforementioned, there is a functional split that separates
       transport-related functions from service-related functions.  Both
       strata cooperate for 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 endpoints (e.g., between end-user
       devices, between two service gateways, etc.).  The data-forwarding
       nodes are controlled and managed by the Transport SDN component.

    Contreras, et al.             Informational                     [Page 9]

    RFC 8597                Layered SDN Architecture                May 2019

       The control plane in the SDN Intelligence is in charge of instructing
       the forwarding devices to build the end-to-end data path for each
       communication or to make sure the forwarding service is appropriately
       set up.  Forwarding may not be rely solely on the preconfigured
       entries; means can be enabled so that involved nodes can 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 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 contains the functions related to the provision
       of services and the capabilities offered to external applications.
       The resource plane consists of the resources involved in the service
       delivery, such as computing resources, registries, databases, etc.

       The control plane is in charge of controlling and configuring those
       resources as well as interacting with the control plane of the
       Transport Stratum in client mode to request transport capabilities
       for a given service.  In the same way, the management plane
       implements management actions on the service-related resources and
       interacts with the management plane in the Transport Stratum 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
       Strata.  This could be the case in the provision of a transport
       service complemented with advanced capabilities in addition to the
       pure data transport (e.g., maintenance of a given SLA [RFC7297]).

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

    3.2.  Plane Separation

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

    Contreras, et al.             Informational                    [Page 10]

    RFC 8597                Layered SDN Architecture                May 2019

    3.2.1.  Control Plane

       The control plane logically centralizes the control functions of each
       stratum and directly controls the corresponding resources.  [RFC7426]
       introduces the role of the control plane in an SDN architecture.
       This plane is part of an SDN Intelligence and can interact with other
       control planes in the same or different strata to perform control
       functions.

    3.2.2.  Management Plane

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

    3.2.3.  Resource Plane

       The resource plane comprises the resources for either the transport
       or the service functions.  In some cases, the service resources can
       be connected to the transport ones (e.g., being the terminating
       points of a transport function); in other cases, it can be decoupled
       from the transport resources (e.g., one database keeping a register
       for the end user).  Both the forwarding and operational planes
       proposed in [RFC7426] would be part of the 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: 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 into account, for example, the traffic load.

    Contreras, et al.             Informational                    [Page 11]

    RFC 8597                Layered SDN Architecture                May 2019

       o  Resource 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, for
          example, DoS attacks.

    5.  Communication between SDN Controllers

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

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

       The communication between controllers must also be secure, e.g., by
       preventing denial of service or any other kind of threat (similarly,
       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.

    Contreras, et al.             Informational                    [Page 12]

    RFC 8597                Layered SDN Architecture                May 2019

    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 with a Single Transport
            Stratum

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

    6.1.2.  Single Service Stratum Associated with Multiple Transport Strata

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

    6.2.  Hybrid Environments

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

    6.2.1.  SDN Service Stratum Associated with a Legacy Transport Stratum

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

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

    6.2.2.  Legacy Service Stratum Associated with an SDN Transport Stratum

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

    Contreras, et al.             Informational                    [Page 13]

    RFC 8597                Layered SDN Architecture                May 2019

    6.3.  Multi-domain Scenarios in the Transport Stratum

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

       In this particular 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, a multi-domain or end-to-end
       abstraction component can provide a homogeneous abstract view of the
       underlying heterogeneous transport capabilities for all the domains.

       Multi-operator scenarios at the Transport Stratum should support the
       establishment of end-to-end paths in a programmatic manner across the
       involved networks.  For example, this could be accomplished by 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
       [GSNFV-EVE005].  One level is the need to control the NFV
       Infrastructure (NFVI) to provide end-to-end connectivity 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), which benefits from the
       programmability brought by SDN.  The two control concerns are
       separate in nature.  However, interaction between the two can be
       expected in order to optimize, scale, or influence one another.

    Contreras, et al.             Informational                    [Page 14]

    RFC 8597                Layered SDN Architecture                May 2019

    7.2.  Abstraction and Control of TE Networks

       Abstraction and Control of TE Networks (ACTN) [RFC8453] presents a
       framework that allows the creation of virtual networks to be offered
       to customers.  The concept of "provider" in ACTN is limited to the
       offering of virtual network services.  These services are essentially
       transport services and would correspond to the Transport Stratum in
       CLAS.  On the other hand, the Service Stratum in CLAS can be
       assimilated as a customer in the context of ACTN.

       ACTN defines a hierarchy of controllers to facilitate the creation
       and operation of the virtual networks.  An interface is defined for
       the relationship between the customers requesting these virtual
       network services 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 Service and Transport
        Strata

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

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

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

          Other potential candidates could be the Transport API [TAPI] or
          the Transport Northbound Interface [TRANS-NORTH].  Each of these
          options has a different scope.

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

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

    Contreras, et al.             Informational                    [Page 15]

    RFC 8597                Layered SDN Architecture                May 2019

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

       o  SLA mapping: Both strata will handle SLAs, but the nature of those
          SLAs could differ.  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 require the use of
          a discovery mechanism that dynamically establishes the association
          between the strata.

       o  Security: As reflected before, the communication between strata
          must be secure 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 has no IANA actions.

    10.  Security Considerations

       The CLAS architecture relies upon the functional entities that are
       introduced in [RFC7149] and [RFC7426].  As such, security
       considerations discussed in Section 5 of [RFC7149], in particular,
       must be taken into account.

       The communication between the service and transport SDN controllers
       must rely on secure means 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 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 to the Transport Stratum) must be enabled.
       The exact set of information to be shared is deployment specific.

    Contreras, et al.             Informational                    [Page 16]

    RFC 8597                Layered SDN Architecture                May 2019

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

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

    11.  References

    11.1.  Normative References

       [Y.2011]   International Telecommunication Union, "General principles
                  and general reference model for Next Generation Networks",
                  ITU-T Recommendation Y.2011, October 2004,
                  <https://www.itu.int/rec/T-REC-Y.2011-200410-I/en>.

    11.2.  Informative References

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

       [GSNFV-EVE005]
                  ETSI, "Network Functions Virtualisation (NFV); Ecosystem;
                  Report on SDN Usage in 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>.

    Contreras, et al.             Informational                    [Page 17]

    RFC 8597                Layered SDN Architecture                May 2019

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

    Contreras, et al.             Informational                    [Page 18]

    RFC 8597                Layered SDN Architecture                May 2019

    Appendix A.  Relationship with RFC 7426

       [RFC7426] introduces an SDN taxonomy by defining a number of planes,
       abstraction layers, and interfaces or APIs among them as a means of
       clarifying how the different parts constituent of SDN (network
       devices, control and management) relate.  A number of planes are
       defined, 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: dedicated to 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 these, [RFC7426] proposes a number of abstraction layers
       that permit the integration of the different planes through common
       interfaces.  CLAS focuses on control, management, and resource planes
       as the basic pieces of its architecture.  Essentially, the control
       plane modifies the behavior and actions of the controlled resources.
       The management plane monitors and retrieves the status of those
       resources.  And finally, the resource plane groups all the resources
       related to the concerns of each stratum.

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

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

    Contreras, et al.             Informational                    [Page 19]

    RFC 8597                Layered SDN Architecture                May 2019

    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

       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

    Contreras, et al.             Informational                    [Page 20]

    RFC 8597                Layered SDN Architecture                May 2019

       Mohamed Boucadair
       Orange
       Rennes  35000
       France

       Email: mohamed.boucadair@orange.com

       Paola Iovanna
       Ericsson
       Pisa
       Italy

       Email: paola.iovanna@ericsson.com

    Contreras, et al.             Informational                    [Page 21]