doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc8597.txt b/doc/rfc/rfc8597.txt
new file mode 100644
index 0000000..ff8312a
--- /dev/null
+++ b/doc/rfc/rfc8597.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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]
+