RFC 8597

Cooperating Layered Architecture for Software-Defined Networking (CLAS)

📅 published May 2019, from ietf

Cooperating Layered Architecture for Software-Defined Networking (CLAS) 🎀

okay bestie, let's get into RFC 8597 💅 this one is a May 2019 doc, and the title block tells us it came in as an Independent Submission, so it didn't come out of an IETF working group 🧚 It's Informational, which means it's an idea to think about, not a rule you have to follow ✨ The authors are LM. Contreras (Telefonica), CJ. Bernardos (UC3M), D. Lopez (Telefonica), M. Boucadair (Orange), and P. Iovanna (Ericsson) 🫶 The ISSN is 2070-1721. It doesn't obsolete or update anything, since the title block doesn't list any RFCs 💜

Abstract ✨

Software-Defined Networking (SDN) is all about separating the control plane from the data plane in network nodes, and then centralizing that control onto one entity or a set of control entities 🔥 Most of the network and/or service intelligence gets moved into those control entities. Usually, one of them looks like a bundle of control functions that are tightly stuck together in a vertical way 💀 Moving control functions from a bunch of distributed nodes into one logical central entity means a bunch of control capabilities with totally different purposes end up in the same place 🙈 So, the existing solutions don't clearly separate transport control from the services that depend on transport capabilities. Not ideal, bestie.

This document describes an approach called Cooperating Layered Architecture for Software-Defined Networking (CLAS) 🦋 In CLAS, the control functions for transport are split off from the ones for services, so each side can be provided and maintained on its own and follow its own evolution path. Main character energy 👑

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes 🌸

This is a contribution to the RFC Series, and it's independent of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make 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 🍓

Info about the current status of this document, any errata, and how to give feedback can be found at https://www.rfc-editor.org/info/rfc8597 ✨

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) as they were in effect on the date this document was published. Please review those documents carefully, because they describe your rights and restrictions with respect to this document 🫶

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

1. Introduction 🧚

Network softwarization is moving fast and bringing programmability into the services and infrastructures of telecom operators 🚀 This usually happens by adding Software-Defined Networking (SDN) [RFC7149] [RFC7426] capabilities to the network, including controllers and orchestrators ✨

But there are different kinds of concerns that these SDN capabilities have to handle 🤔 On one hand, we need actions focused on programming the network to deal with connectivity or with forwarding digital data between distant nodes. On the other hand, we also need actions for programming the functions or services that process (or manipulate) that digital data 💖

SDN separates the control plane from the data plane in network nodes by putting an abstraction between the two planes. This lets the control logic, which lives in a functional entity commonly called an SDN Controller, be centralized, and you can deploy one or several controllers 🎀 A programmatic interface then sits between a forwarding entity (at the network node) and a control entity. Through that interface, the control entity tells the nodes in the forwarding plane what to do and changes how they forward traffic 🦋 Other capabilities (e.g., performance monitoring, fault management, etc.) could be expected through this same kind of programmatic interface [RFC7149] 💅

Most of the intelligence gets moved into this kind of functional entity. Usually, it looks like a bundle of interacting control functions stuck together vertically and tightly integrated 🫠

The idea of one all-powerful control entity running the whole network, especially both the transport network and the services built on top of it, comes with a bunch of issues 👀

  • From a provider perspective, different departments usually handle services and connectivity (i.e., transport capabilities for the service on top). With the approach above, it's really unclear who is responsible for complete service provision and delivery 😭
  • Reusing functions for providing services gets complicated 🌀
  • Control architectures end up closed and monolithic 🧱
  • Functional components are hard to make interoperable and interchangeable 🙅‍♀️
  • Business boundaries between providers get blurry, especially when one provider only sells connectivity and another provider offers a fancier service on top of that connectivity 🫣
  • Service and network diagnosis and troubleshooting get messy, especially when you're trying to figure out which layer is responsible for a failure 🔍

Moving control functions from a bunch of distributed network nodes into one other entity puts a bunch of control capabilities with different purposes together. So the existing SDN solutions don't clearly separate services from transport control 🙃 Here, the separation between service and transport follows the distinction made by [Y.2011] and defined in Section 2 of this document 📚

This document describes an approach called Cooperating Layered Architecture for SDN (CLAS) 🌈 In CLAS, the control functions for transport are separated from the ones for services, so they can be provided and maintained independently and follow their own evolution path 💜

Even with that separation, the service and transport layers (or strata in [Y.2011]) and their components still need to work closely together to use resources efficiently 🫶 Cooperation is key, bestie 👑

2. Terminology 📖

This document uses the following terms:

  • Transport: the transfer capabilities offered by a networking infrastructure. These capabilities can rely on pure IP techniques or on other means, such as MPLS or optics 🚆
  • Service: a logical construct that makes use of transport capabilities 🎁

This document doesn't make any assumptions about the functional perimeter of a service that can be built above a transport infrastructure. So a service can be offered to customers, or it can be invoked to deliver another (added-value) service 💖

  • Layer: the set of elements that enable either transport or service capabilities, as defined above. In [Y.2011] this is called a "stratum", and the two terms are used interchangeably 🍰
  • Domain: a set of elements that share a common property or characteristic. In this document, it applies to the administrative domain (i.e., elements belonging to the same organization), the technological domain (elements implementing the same kind of technology, such as optical nodes), etc. 🏷️
  • SDN Intelligence: the decision-making process hosted by a node or a set of nodes. These nodes are called SDN controllers 🧠

The intelligence can be centralized or distributed, and 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

Part 2 is coming next, so keep your eyes peeled 👀🦋

3. Architecture Overview ✨

okay so bestie, real talk: today's operator networks are juggling a LOT 😭 VoIP, IPTV, mobile VoIP, critical mission apps, all running on a bunch of different transport technologies. To deliver a service no matter what's underneath, you need to separate the service stuff from the transport stuff and wrap the transport network in an abstraction. That hides the messy details of how data actually moves and gives everyone one clean set of capabilities to use. Iconic, honestly 💅

That separation is giving flexibility 🎀. Services can be tweaked without touching transport, and transport can change without wrecking services. Multiple services can share one transport infrastructure, and different technologies can step up to meet what a particular service needs. The catch? The layers have to work together super closely for delivery to stay consistent. That's what we call inter-layer cooperation 🫶

This document is obsessed with four things:

  • exposing transport capabilities to services 🦋
  • capturing the transport requirements that services have 💜
  • notifying service intelligence about transport events, so the service can adjust its decision-making when something happens down below 🔥
  • instructing the transport capabilities to accommodate new requirements, and so on ✨

A classic example is guaranteeing some Quality-of-Service (QoS) levels. QoS offerings can show up at both the service and transport layers, and there should be vertical mechanisms linking the two so the end user actually gets the quality they're promised 🌈

Here's the CLAS vibe: the logically centralized control functions get split into two functional layers. One layer handles the service-related functions, and the other handles the transport-related functions. The two layers are expected to cooperate through standard interfaces 🧚

Figure 1 shows the whole CLAS architecture. It's built on the functional separation from the Next Generation Network (NGN) architecture that the ITU-T defined in [Y.2011], which has two strata of functionality: the Service Stratum (service-related functions) and the Transport Stratum (transport-related functions). Each of those strata is then grouped further into control, management, and user (or data) planes 💖

CLAS uses the same structured model as [Y.2011], but points it at SDN programmability [RFC7149]. The big idea is that services and transport get addressed separately, because they have totally different concerns 🍓

                                    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

Now the controllers. In CLAS, both control and management functions are handled by one or more SDN controllers (for things like scalability and reliability 💪). They make up the SDN Intelligence, and there are separate SDN controllers living in the Service Stratum and the Transport Stratum. Management counts as part of the SDN Intelligence so it works properly in a service provider ecosystem [RFC7149]. Some early proposals didn't include management in the SDN world at all, though [ONFArch] 🙈

The generic user- or data-plane functions from the NGN architecture get a new name here: resource-plane functions ✨. Each stratum's resource plane is controlled by its own SDN Intelligence through a standard interface.

The SDN controllers team up to deliver services, and it's hierarchical 👑 The Service SDN Intelligence asks the Transport SDN Intelligence to provide transport capabilities. So the Service SDN Intelligence acts as a client of the Transport SDN Intelligence. And the favour goes back the other way too: the Transport SDN Intelligence keeps the Service SDN Intelligence in the loop about transport network events that might call for action in the service layer 🦋

Not drawn in Figure 1, but the resource planes of each stratum could be connected, depending on the kind of service being provided. The Service Stratum could also offer an interface so applications can expose network service capabilities to those apps or to customers 🌸

3.1. Functional Strata

As mentioned, there's a functional split that separates transport-related functions from service-related functions. Both strata cooperate so delivery stays consistent 💜

Consistency is determined and characterized by the service layer 💅

3.1.1. Transport Stratum

The Transport Stratum covers the functions focused on moving data between communication endpoints (like between end-user devices, or between two service gateways). The data-forwarding nodes are controlled and managed by the Transport SDN component 🚀

The control plane in the SDN Intelligence is responsible for telling the forwarding devices to build the end-to-end data path for each communication, or to make sure the forwarding service is set up properly. Forwarding doesn't rely only on preconfigured entries, though. Nodes can be enabled to dynamically build routing and forwarding paths, which requires the nodes to keep some of their control and management capabilities to make that happen 🧠 Last but not least, the management plane handles management functions (FCAPS) on those devices, like fault or performance management, as part of the Transport Stratum capabilities ✨

3.1.2. Service Stratum

The Service Stratum holds the functions related to providing services and the capabilities offered to external applications. Its resource plane is made up of the resources involved in delivering the service, like computing resources, registries, databases, and so on 🎀

The control plane controls and configures those resources. It also talks to the control plane of the Transport Stratum in client mode, to request transport capabilities for a given service 🫶 Similarly, the management plane carries out management actions on the service-related resources and interacts with the management plane in the Transport Stratum so the layers manage things cooperatively 🌈

3.1.3. Recursiveness

Recursive layering can happen in some scenarios where the Transport Stratum is itself structured into a Service and a Transport Stratum. This could happen when a transport service comes with advanced capabilities on top of plain data transport, like keeping a given SLA [RFC7297] 📈

Recursiveness has also been talked about in [ONFArch] as a path to scalability and modularity, where each higher level can offer more abstraction 🧚 It can also enable some multi-domain scenarios with one or several administrative domains involved, such as the ones described in Section 6.3 🌍

3.2. Plane Separation

CLAS leans into plane separation 🍰 As mentioned in Sections 3.1.1 and 3.1.2, each stratum has three different planes. Communication among those three planes (and with the matching planes in other strata) runs over open, standard interfaces 💖

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 it can interact with other control planes in the same or different strata to carry out 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 management plane's functions in an SDN environment 📋 This plane is also part of the SDN Intelligence, and it can interact with the corresponding management planes in SDN controllers of the same or different strata 🫶

3.2.3. Resource Plane

The resource plane holds the resources for either the transport or the service functions. Sometimes service resources are connected to transport ones (like being the terminating points of a transport function). Other times they're decoupled, like a 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 ✨

okay so, the CLAS architecture has a bunch of different layers, all with their own jobs and responsibilities, so a few features are required to be supported 💅

  • Abstraction: mapping physical resources into their abstracted resources 🧚
  • Service-Parameter Translation: translating service parameters (like SLAs) into transport parameters (or capabilities), following different policies 📋
  • Monitoring: mechanisms (like event notifications) that dynamically update the (abstracted) resources' status, taking things like traffic load into account 📡
  • Resource Computation: functions that decide which resources will be used for a given service request. For example, functions like PCE could compute, select, or decide on a certain path 🛤️
  • Orchestration: the ability to combine diverse resources (like IT and network resources) in an optimal way 🎀
  • Accounting: a record of resource usage 🧾
  • Security: secure communication among components, which helps prevent things like DoS attacks 🛡️

5. Communication between SDN Controllers

the SDN controllers living in the Service and Transport Strata need to establish tight coordination 🫶 mechanisms for transferring the relevant information for each stratum should be defined.

from the service side, the Service SDN Intelligence needs to easily access transport resources through well-defined APIs so it can retrieve the capabilities the Transport Stratum offers 🔥 there are different ways to get that transport-aware information, meaning discovering or publishing mechanisms. with discovery, the Service SDN Intelligence could handle complete information about the transport capabilities (including resources) offered by the Transport Stratum. with publishing, the Transport Stratum reveals the available capabilities, for example through a catalog, which cuts down on how much detail of the underlying network gets shared 🌸

on the other side, 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, for example 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 show up depending on the characteristics of the networks involved in a given deployment 🦋

6.1. Full SDN Environments

this case considers that the networks involved in providing and delivering 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, and the Service Strata are the clients of the Transport Stratum. some of the capabilities the Transport Stratum can offer are 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 to provide a certain service 🌈 the Service Stratum invokes standard interfaces to each of the Transport Strata, and orchestrates the provided transfer capabilities to build 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 adapts SDN-based control and management service-related commands to legacy transport-related protocols, the way the legacy Transport Stratum expects 🙌

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 an interworking function that can interpret commands from the legacy service functions and translate them into SDN protocols for operation with the SDN-enabled Transport Stratum 🔄

6.3. Multi-domain Scenarios in the Transport Stratum

the Transport Stratum can be made up 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 if some abstraction capabilities are provided in the transport part to emulate a single stratum 🪄

those abstraction capabilities are a service in their own right, offered by the Transport Stratum to the services that make use of this stratum. this service is focused on providing transport capabilities, which is different from the final communication service that uses those 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 establishing end-to-end paths in a programmatic manner across the involved networks. for example, this could be done by each of the administrative domains exchanging their traffic-engineered information [RFC7926] 🤝

7. Use Cases

this section walks through a few use cases as examples of where the CLAS approach applies 🎬

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). the 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 SDN brings 🪩 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 🥰

7.2. Abstraction and Control of TE Networks

Abstraction and Control of TE Networks (ACTN) [RFC8453] presents a framework that allows virtual networks to be created and offered to customers 💖 the concept of "provider" in ACTN is limited to offering virtual network services. these services are essentially transport services and would correspond to the Transport Stratum in CLAS. the Service Stratum in CLAS can be treated as a customer in the context of ACTN 🛍️

ACTN defines a hierarchy of controllers to facilitate creating and operating 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. that 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 between service and transport concerns raises a number of challenges in the communication between the two strata 😭 the following list reflects some of the challenges that have been identified:

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

  • 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 that 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.

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) 🧵

  • 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 📊
  • Association between strata: the association between strata could be configured beforehand, or both strata could require a discovery mechanism that dynamically establishes the association between them 🔗
  • 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 🔒
  • 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

okay this section is SERIOUS bestie 🚨 the CLAS architecture relies upon the functional entities that are introduced in [RFC7149] and [RFC7426]. as such, the 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:

  • Mutual authentication must be enabled before taking any action.
  • Message integrity protection.

each of the controllers must be provided with instructions about the set of information (and granularity) that can be disclosed to a peer controller. means to prevent the leaking of privacy data (for example, from the Service Stratum to the Transport Stratum) must be enabled. the exact set of information to be shared is deployment specific 🕵️‍♀️

a corrupted controller may cause 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 📚

Okay so these are the must-reads, bestie. You need these to get the full picture of this doc 💅

11.2. Informative References 🌸

These ones are the extra credit reading. Super helpful, not required 🫶

Appendix A. Relationship with RFC 7426 🔥

Okay, this part is all about how this work lines up with the SDN taxonomy in [RFC7426] 🧚 [RFC7426] introduces an SDN taxonomy by defining a number of planes, abstraction layers, and interfaces or APIs among them. The point is to make it clear how the different parts that make up SDN (network devices, control, and management) relate to each other ✨ A number of planes are defined, including:

  • Forwarding Plane: focused on delivering packets in the data path based on the instructions received from the control plane.
  • Operational Plane: centered on managing the operational state of the network device.
  • Control Plane: dedicated to instructing the device on how packets should be forwarded.
  • Management Plane: in charge of monitoring and maintaining network devices.
  • 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 🦋

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 🌈

Here are the authors' details, so you know exactly who to thank (or DM) 💅

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

Email: luismiguel.contrerasmurillo@telefonica.com
URI:   http://lmcontreras.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid  28911
Spain

Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI:   http://www.it.uc3m.es/cjbc/
Diego R. Lopez
Telefonica
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid  28050
Spain

Email: diego.r.lopez@telefonica.com
Mohamed Boucadair
Orange
Rennes  35000
France

Email: mohamed.boucadair@orange.com
Paola Iovanna
Ericsson
Pisa
Italy

Email: paola.iovanna@ericsson.com

That's the whole RFC, bestie! 🦋✨ Thanks for reading all the way through, you're so iconic 🌸

📦 where this page comes from