GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8597

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8597.txt · Last modified: 2019/05/16 04:55 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki