RFC 7426

Software-Defined Networking (SDN): Layers and Architecture Terminology

📅 published January 2015, from ietf

Software-Defined Networking (SDN): Layers and Architecture Terminology 🦋

okay bestie, let's get into it 💖 This is RFC 7426, and the title block tells us the main facts. It's an Informational doc, so it's not a Standards Track spec, and it came out in January 2015 from the Internet Research Task Force (IRTF). The ISSN is 2070-1721. The editors are E. Haleplidis, Ed. from the University of Patras, and K. Pentikousis, Ed. from EICT. The other authors are S. Denazis (University of Patras), J. Hadi Salim (Mojatatu Networks), D. Meyer (Brocade), and O. Koufopavlou (University of Patras) 🎀. The title block doesn't list anything it obsoletes or updates, so it isn't replacing or patching any other RFC ✨.

Abstract ✨

so Software-Defined Networking (SDN) is a new approach to network programmability. That means the ability to initialize, control, change, and manage network behavior dynamically through open interfaces 🔥. SDN puts software at the center of running networks by adding an abstraction for the data forwarding plane, which splits it off from the control plane. That separation lets both planes innovate faster, and experience has already shown it works 💅. But people are getting confused about what SDN actually is, what layers an SDN architecture has, and how those layers talk to each other 💀.

This document answers those questions. It comes from the IRTF Software-Defined Networking Research Group (SDNRG) and is a concise reference for the SDN research community. It's based on relevant peer-reviewed literature, the RFC series, and documents from other standards organizations 🧚.

Status of This Memo 🌸

this doc is not an Internet Standards Track specification. It's published for informational purposes 🙈

It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development. Those results might not be suitable for deployment. This RFC represents the consensus of the SDNRG. Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 🫶

For info on the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7426 🌈

Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) as they were in effect on the date of publication. Please read these carefully, since they describe your rights and restrictions with respect to this document 📜

Table of Contents 🍓

1. Introduction ....................................................4
2. Terminology .....................................................5
3. SDN Layers and Architecture .....................................7
   3.1. Overview ...................................................9
   3.2. Network Devices ...........................................12
   3.3. Control Plane .............................................13
   3.4. Management Plane ..........................................14
   3.5. Discussion of Control and Management Planes ...............16
        3.5.1. Timescale ..........................................16
        3.5.2. Persistence ........................................16
        3.5.3. Locality ...........................................16
        3.5.4. CAP Theorem Insights ...............................17
   3.6. Network Services Abstraction Layer ........................18
   3.7. Application Plane .........................................19
4. SDN Model View .................................................19
   4.1. ForCES ....................................................19
   4.2. NETCONF/YANG ..............................................20
   4.3. OpenFlow ..................................................21
   4.4. Interface to the Routing System ...........................21
   4.5. SNMP ......................................................22
   4.6. PCEP ......................................................23
   4.7. BFD .......................................................23
5. Summary ........................................................24
6. Security Considerations ........................................24
7. Informative References .........................................25
Acknowledgements ..................................................33
Contributors ......................................................34
Authors' Addresses ................................................34

1. Introduction ✨

so "Software-Defined Networking (SDN)" is a term from the programmable networks paradigm [PNSurvey99] [OF08]. Basically, SDN means software apps can program individual network devices on the fly, which lets them control how the whole network behaves [NV09] 💻. Boucadair and Jacquenet [RFC7149] describe SDN as a set of techniques for designing, delivering, and operating network services in a deterministic, dynamic, and scalable way 🦋

the big idea is adding an abstraction between the (traditional) forwarding and control planes 🫧. That separates them, and it gives apps what they need to control the network programmatically. The goal is to use that separation and programmability to cut complexity and speed up innovation on both planes [A4D05] 🚀

the history of programmable networks is covered in detail in [SDNHistory] and [SDNSurvey], going back to the 1980s 🕰️. As [SDNHistory] documents, a lot of the ideas, concepts, and concerns still apply to today's SDN research, standardization included. People have been investigating them in the research community for a long time 📚. For example, Rooney, et al. [Tempest] talk about letting third parties access the network without hurting network integrity, and about fitting legacy networking solutions into their then-new programmable environment 🧠. Separating the control and forwarding planes, which is so central to SDN now, was also discussed a lot before 1998 [Tempest] [P1520]. It showed up in SS7 networks [ITUSS7], Ipsilon Flow Switching [RFC1953] [RFC2297], and ATM [ITUATM] 💅

SDN research often focuses on different parts of programmability, so we keep running into conflicting takes on what SDN even is 😭. For example, some well-accepted definitions don't line up with each other, for various reasons. One reason is that work focused on one domain isn't always directly applicable to others. Another example: OpenFlow [OpenFlow] and the Network Configuration Protocol (NETCONF) [RFC6241] have both been called SDN interfaces, but they're about control and management, respectively 🙃

this document tries to pull the SDN definitions in the literature together and connect them to earlier work at the IETF and in the research community 🧩. It's especially interested in figuring out which layers make up the SDN architecture, and which interfaces and attributes are best suited for use between them. So the aim is not to standardize any particular layer or interface. It's meant to be a concise reference that reflects current approaches to the SDN layer architecture. We expect it'll be useful for future SDNRG work and for SDN discussions across the whole community 🎀

this doc addresses the SDNRG charter item titled "Survey of SDN approaches and Taxonomies." It describes prominent SDN technologies in a technology-impartial and business-agnostic way, but it isn't a new IETF standard. It's meant as a shared base for more discussion. That means we don't make value statements or talk about whether any of the frameworks here fit any particular purpose. We just document their characteristics and attributes and classify them into a taxonomy 🍭. This doc also doesn't try to list every SDN research issue. If you want more, check out [SLTSDN] and [SDNACS]. In particular, Jarraya, et al. [SLTSDN] give an overview of SDN research topics, like control partitioning, which relates to the Consistency, Availability and Partitioning (CAP) theorem discussed in Section 3.5.4 🌟

this doc got a thorough review, discussion, and commenting from the vast majority of SDNRG members, a community of well over 100 people 🙌. SDNRG agreed that this document should be published in the IRTF stream of the RFC series [RFC5743] 💜

here's how the rest of the doc is laid out. Section 2 explains the terminology used here. Section 3 gives a high-level overview of current SDN architecture abstractions. And Section 4 looks at how the SDN layer architecture relates to the big SDN-enabling technologies 🧚‍♀️

  1. Terminology 💅✨

okay so before we dive into the architecture stuff, we need to get the vocab locked in, bestie 🎀 this doc uses the following terms:

  • Software-Defined Networking (SDN) - a programmable networks approach that supports the separation of control and forwarding planes via standardized interfaces. it's giving "the brain and the muscles are separate and they talk through a standard language" 🧠💪
  • Resource - a physical or virtual component available within a system. resources can be super simple and fine-grained (like a port or a queue) or complex, made up of multiple resources (like a network device) 🌸
  • Network Device - a device that performs one or more network operations related to packet manipulation and forwarding. this reference model makes no distinction whether a network device is physical or virtual. a device can also be considered as a container for resources and can be a resource in itself 📦 no cap it's a whole vibe
  • Interface - a point of interaction between two entities. when the entities are placed at different locations, the interface is usually implemented through a network protocol. if the entities are collocated in the same physical location, the interface can be implemented using a software application programming interface (API), inter-process communication (IPC), or a network protocol 🦋
  • Application (App) - an application in the context of SDN is a piece of software that utilizes underlying services to perform a function. application operation can be parameterized, for example, by passing certain arguments at call time, but it is meant to be a standalone piece of software; an App does not offer any interfaces to other applications or services. main character energy, it keeps to itself 🙈
  • Service - a piece of software that performs one or more functions and provides one or more APIs to applications or other services of the same or different layers to make use of said functions and returns one or more results. services can be combined with other services, or called in a certain serialized manner, to create a new service 🧚
  • Forwarding Plane (FP) - the collection of resources across all network devices responsible for forwarding traffic 🚀
  • Operational Plane (OP) - the collection of resources responsible for managing the overall operation of individual network devices 🍓
  • Control Plane (CP) - the collection of functions responsible for controlling one or more network devices. CP instructs network devices with respect to how to process and forward packets. the control plane interacts primarily with the forwarding plane and, to a lesser extent, with the operational plane 👑
  • Management Plane (MP) - the collection of functions responsible for monitoring, configuring, and maintaining one or more network devices or parts of network devices. the management plane is mostly related to the operational plane (it is related less to the forwarding plane) 🫶
  • Application Plane - the collection of applications and services that program network behavior 💜
  • Device and resource Abstraction Layer (DAL) - the device's resource abstraction layer based on one or more models. if it is a physical device, it may be referred to as the Hardware Abstraction Layer (HAL). DAL provides a uniform point of reference for the device's forwarding- and operational-plane resources 🌈
  • Control Abstraction Layer (CAL) - the control plane's abstraction layer. CAL provides access to the Control-Plane Southbound Interface ⭐
  • Management Abstraction Layer (MAL) - the management plane's abstraction layer. MAL provides access to the Management-Plane Southbound Interface 🎀
  • Network Services Abstraction Layer (NSAL) - provides service abstractions that can be used by applications and services 🦋

3. SDN Layers and Architecture ✨

okay the vibe check on this section: figure 1 summarizes the SDN architecture abstractions in a detailed, high-level schematic. note that in a particular implementation, planes can be collocated with other planes or can be physically separated, as we discuss below 🍓

SDN is based on the concept of separation between a controlled entity and a controller entity. the controller manipulates the controlled entity via an interface. interfaces, when local, are mostly API invocations through some library or system call. however, such interfaces may be extended via some protocol definition, which may use local inter-process communication (IPC) or a protocol that could also act remotely; the protocol may be defined as an open standard or in a proprietary manner 💅

Day [PiNA] explores the use of IPC as the mainstay for the definition of recursive network architectures with varying degrees of scope and range of operation. The Recursive InterNetwork Architecture [RINA] outlines a recursive network architecture based on IPC that capitalizes on repeating patterns and structures. this document does not propose a new architecture -- we simply document previous work through a taxonomy. although recursion is out of the scope of this work, Figure 1 illustrates a hierarchical model in which layers can be stacked on top of each other and employed recursively as needed 🌸

               o--------------------------------o
               |                                |
               | +-------------+   +----------+ |
               | | Application |   |  Service | |
               | +-------------+   +----------+ |
               |       Application Plane        |
               o---------------Y----------------o
                               |
 *-----------------------------Y---------------------------------*
 |           Network Services Abstraction Layer (NSAL)           |
 *------Y------------------------------------------------Y-------*
        |                                                |
        |               Service Interface                |
        |                                                |
 o------Y------------------o       o---------------------Y------o
 |      |    Control Plane |       | Management Plane    |      |
 | +----Y----+   +-----+   |       |  +-----+       +----Y----+ |
 | | Service |   | App |   |       |  | App |       | Service | |
 | +----Y----+   +--Y--+   |       |  +--Y--+       +----Y----+ |
 |      |           |      |       |     |               |      |
 | *----Y-----------Y----* |       | *---Y---------------Y----* |
 | | Control Abstraction | |       | | Management Abstraction | |
 | |     Layer (CAL)     | |       | |      Layer (MAL)       | |
 | *----------Y----------* |       | *----------Y-------------* |
 |            |            |       |            |               |
 o------------|------------o       o------------|---------------o
              |                                 |
              | CP                              | MP
              | Southbound                      | Southbound
              | Interface                       | Interface
              |                                 |
 *------------Y---------------------------------Y----------------*
 |         Device and resource Abstraction Layer (DAL)           |
 *------------Y---------------------------------Y----------------*
 |            |                                 |                |
 |    o-------Y----------o   +-----+   o--------Y----------o     |
 |    | Forwarding Plane |   | App |   | Operational Plane |     |
 |    o------------------o   +-----+   o-------------------o     |
 |                       Network Device                          |
 +---------------------------------------------------------------+

Figure 1: SDN Layer Architecture 🧚

3.1. Overview ✨

okay bestie, so this doc takes a network-device-centric approach 🔧 Control is mostly about the device's packet-handling power, and management is about the overall operation of the device. The way it sees a network device is as a complex resource 🧩 that contains and is part of multiple resources, similar to [DIOPR]. A resource can be tiny, like a single port or queue on the device, or it can be bundled into something bigger, like a network card or a whole network device 💖

Keep in mind there's no difference between "physical" and "virtual" resources, or between "hardware" and "software" versions, in this doc. It doesn't dig into implementation or performance stuff 🙈 So a resource can be fully hardware, fully software, or any mix in between. It also doesn't care whether a resource is an overlay or part of some other device. Network device software can run on so-called "bare metal" or on a virtualized substrate, and that's all fine 🌈 Finally, this doc doesn't talk about how resources get allocated, orchestrated, or released, because orchestration is out of scope. Not its vibe 💅

SDN spans multiple planes, as shown in Figure 1 🦋 If you start at the bottom of the figure and climb up, you get these planes:

  • Forwarding Plane - Handles packets in the data path based on instructions from the control plane 📦 Its actions include, but aren't limited to, forwarding, dropping, and changing packets. It's usually where control-plane services and applications actually end up, and it can hold forwarding resources like classifiers. It's also widely called the "data plane" or the "data path" ✨
  • Operational Plane - Manages the operational state of the network device, like whether it's active or inactive, how many ports are available, the status of each port, and so on 🔌 It's usually where management-plane services and applications end up, and it deals with resources like ports, memory, and so on. ngl, this one is a little debated. Some folks in the IRTF SDNRG think the operational plane isn't really a "plane" and is basically a mashup of functions on the forwarding plane 🤔 Others think a "plane" is a good way to separate different areas of operations, so the operational plane gets to be a "plane" in Figure 1. This doc goes with the second view 💜
  • Control Plane - Makes decisions about how packets should be forwarded by one or more network devices, then pushes those decisions down to the devices to be carried out 🧠 It mostly focuses on the forwarding plane and less on the operational plane. It may care about operational-plane info, like the current state of a port or what a port is capable of. Its main job is to fine-tune the forwarding tables living in the forwarding plane, based on network topology or external service requests 🎀
  • Management Plane - Monitors, configures, and maintains network devices, for example by making decisions about the state of a device 🛠️ It mostly focuses on the operational plane and less on the forwarding plane. It can be used to configure the forwarding plane, but it does that infrequently and in a more wholesale way than the control plane. For instance, it might set up all or part of the forwarding rules at once, though that's expected to happen sparingly 🍓
  • Application Plane - Where the applications and services that define network behavior live 🌸 Apps that directly (or mainly) support the forwarding plane, like routing processes inside the control plane, don't count as part of the application plane. Apps can be modular and distributed, so they can often span multiple planes in Figure 1 🫶

[RFC7276] defined the data, control, and management planes in terms of Operations, Administration, and Maintenance (OAM). This doc tries to broaden those terms from [RFC7276] so they cover every part of an SDN architecture 🌈

All the planes above are connected through interfaces, marked with "Y" in Figure 1. An interface can play different roles depending on whether the connected planes are on the same physical or virtual device 🧚 If the planes are designed so they don't have to live on the same device, the interface can only be a protocol. If they're collocated on one device, the interface could be an open or proprietary protocol, an open or proprietary software inter-process communication API, or operating system kernel system calls 💻

Applications, meaning software programs that do specific computations and consume services without giving access to other applications, can be built natively inside one plane or can span multiple planes 🦋 For example, an app or service can span both the control and management planes, so it can use both the Control-Plane Southbound Interface (CPSI) and the Management-Plane Southbound Interface (MPSI). This is only implicitly shown in Figure 1 though 👀 An example is an app that uses both [OpenFlow] and [OF-CONFIG].

Services, meaning software programs that provide APIs to other applications or services, can also be built natively in specific planes. Services that span multiple planes count as part of the application plane too 💖

Not shown explicitly in Figure 1, but services, applications, and entire planes can be placed recursively, which gives the model overlay semantics 🌀 For example, application-plane services can be provided to other applications or services through NSAL. Other examples include virtual resources realized on top of physical resources, and hierarchical control-plane controllers [KANDOO] 🪞

The focus here is, of course, on the north/south communication between entities in different planes. But that clearly doesn't rule out entities communicating within a single plane 💅

Real talk though: Figure 1 is an abstract view of the planes, with no implementation details 🙈 A lot of past implementations put the management plane on top of the control plane, which you can read as the control plane acting as a service to the management plane. Also, in many networks (especially Internet routers and Ethernet switches), the control plane has usually been tightly coupled with the network device. Taken as a whole, the control plane has been distributed network-wide. The management plane, on the other hand, has traditionally been centralized and responsible for managing the control plane and the devices. With SDN principles being adopted, though, that line isn't so clear-cut anymore ✨

This doc also considers four abstraction layers 🍰

  • Device and resource Abstraction Layer (DAL) - Abstracts the resources of the device's forwarding and operational planes for the control and management planes. Variations of DAL may abstract both planes, or just one of them, and may abstract any plane of the device to either the control or management plane 🧩
  • Control Abstraction Layer (CAL) - Abstracts the Control-Plane Southbound Interface and the DAL away from the applications and services of the control plane 🎀
  • Management Abstraction Layer (MAL) - Abstracts the Management-Plane Southbound Interface and the DAL away from the applications and services of the management plane 💜
  • Network Services Abstraction Layer (NSAL) - Provides service abstractions for use by applications and other services 🌈

SDN activities have started in other SDOs too, so the picture isn't just this doc 🌍 For example, at the ITU, work on architectural [ITUSG13] and on signaling requirements and protocols [ITUSG11] has started, but those study groups haven't published their documents yet, except for [ITUY3300]. The views in [ITUY3300] and in [ONFArch] line up really well with this doc 🫶🔥

3.2. Network Devices ✨

okay so a network device is basically anything that catches packets on its ports and does something with them 📦 like forward it, drop it, edit the header (or payload) 🙈, forward it again, you name it. it's an aggregation of a bunch of resources, like ports, CPU, memory, and queues, and each of those is either simple or can be stacked together into a complex resource that looks like one thing. the network device is itself a complex resource 👑. examples are switches and routers, obviously, but also stuff that works above IP (firewalls, load balancers, video transcoders) or below IP (Layer 2 switches, optical or microwave network elements) 🌈

network devices can be hardware or software, and physical or virtual. as already mentioned, this document makes no such distinction, so don't come for it 💅. every network device has a presence in a forwarding plane and an operational plane. ✨

the forwarding plane (aka the "data path") is the one handling and forwarding packets. it provides switching, routing, packet transformation, and filtering functions, and its resources include (but aren't limited to) filters, meters, markers, and classifiers 🦋

the operational plane is in charge of the device's operational state, like the status of ports and interfaces. its resources include (but again, not limited to) memory, CPU, ports, interfaces, and queues 🫶

the forwarding and operational planes are exposed through the Device and resource Abstraction Layer (DAL), which can be expressed by one or more abstraction models. forwarding-plane examples are Forwarding and Control Element Separation (ForCES) [RFC5812], OpenFlow [OpenFlow], YANG model [RFC6020], and SNMP MIBs [RFC3418]. operational-plane examples are the ForCES model [RFC5812], the YANG model [RFC6020], and SNMP MIBs [RFC3418] 🧚

and ngl, applications can live inside a network device too 🤯 like event monitoring and handling (offloading), topology discovery, or ARP [RFC0826] handled in the device itself instead of sending that traffic up to the control plane. main character energy 💖

3.3. Control Plane 👑

the control plane is usually distributed, and it's mainly responsible for configuring the forwarding plane through a Control-Plane Southbound Interface (CPSI), with DAL as the point of reference. CP tells FP how to handle network packets 🎀

control-plane entities talk to each other over the "east-west" interface. that's usually done with gateway protocols like BGP [RFC4271], or other protocols like the Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440]. those protocol messages are usually exchanged in-band and then redirected by the forwarding plane up to the control plane for processing. examples in this category include [RCP], [SoftRouter], and [RouteFlow] 🌸

control-plane functionalities usually include:

  • Topology discovery and maintenance
  • Packet route selection and instantiation
  • Path failover mechanisms

the CPSI is usually defined with these characteristics:

  • time-critical interface that needs low latency and sometimes high bandwidth so it can get a bunch of operations done quickly ⚡
  • oriented toward wire efficiency and device representation instead of human readability 🤖

examples include fast and high-frequency flow or table updates, high throughput, and robustness for packet handling and events 💅

the CPSI can be built on a protocol, an API, or even inter-process communication. if the control plane and the network device aren't collocated, then the interface is definitely a protocol. examples of CPSIs are ForCES [RFC5810] and the OpenFlow protocol [OpenFlow] 🫶

the Control Abstraction Layer (CAL) gives control applications and services access to various CPSIs. the control plane may support more than one CPSI 🧚

control applications can use CAL to control a network device without providing any service to upper layers. examples include applications doing control functions like OSPF, IS-IS, and BGP 💜

control-plane service examples include a virtual private LAN service, service tunnels, topology services, etc. ✨

3.4. Management Plane 🍓

the management plane is usually centralized, and its job is making sure the network as a whole runs optimally by talking to the network devices' operational plane through a Management-Plane Southbound Interface (MPSI), with DAL as the point of reference 🌈

management-plane functionalities are usually started based on an overall view of the network, and they've traditionally been human-centric. lately though, algorithms are replacing most of the human intervention 🤖 management-plane functionalities [FCAPS] typically include:

  • Fault and monitoring management
  • Configuration management

the management plane can also include entities like orchestrators, Virtual Network Function Managers (VNF Managers), and Virtualised Infrastructure Managers, as described in [NFVArch]. these entities can use management interfaces to reach operational-plane resources to request and provision resources for virtual functions, and to instruct the instantiation of virtual forwarding functions on top of physical forwarding functions 🦋 a common abstraction model for both SDN and Network Function Virtualization (NFV) is explored in [SDNNFV]. but note that these are only examples of applications and services in the management plane, not formal definitions of entities in this document. as noted above, orchestration, and therefore the definition of any associated entities, is out of scope for this document 🙈

the MPSI, unlike the CPSI, is usually not time-critical and doesn't share the CPSI requirements 💅

because the MPSI is typically closer to human interaction than the CPSI (cf. [RFC3535]), it usually has these characteristics:

  • It is oriented more toward usability, with optimal wire performance being a secondary concern.
  • Messages tend to be less frequent than in the CPSI.

as an example of usability versus performance, the consensus of the 2002 IAB Workshop [RFC3535] was that the key requirement for a network management technology is ease of use, not performance 🎀 as per [RFC6632], textual configuration files should be able to contain international characters. human-readable strings should use UTF-8, and protocol elements should be case-insensitive ASCII, which takes more processing capability to parse 🌸

the MPSI can be a protocol, an API, or even inter-process communication. if the management plane isn't embedded in the network device, the MPSI is definitely a protocol. examples of MPSIs are ForCES [RFC5810], NETCONF [RFC6241], IP Flow Information Export (IPFIX) [RFC7011], Syslog [RFC5424], Open vSwitch Database (OVSDB) [RFC7047], and SNMP [RFC3411] 🧚

the Management Abstraction Layer (MAL) gives management applications and services access to various MPSIs. the management plane may support more than one MPSI 💜

management applications can use MAL to manage the network device without providing any service to upper layers. examples include network monitoring, fault detection, and recovery applications ✨

management-plane services provide access to other services or applications above the management plane. 🫶

3.5. Discussion of Control and Management Planes 💅

the definition of a clear distinction between "control" and "management" in the context of SDN got a LOT of community attention while this document was being prepared 😭 we noticed that the management plane's role had mostly been ignored earlier, or specified as out of scope for the SDN ecosystem. in the rest of this subsection, we sum up the characteristics that tell the two planes apart, so we all understand the mechanics, capabilities, and needs of each interface 🔥

3.5.1. Timescale ⏰

a point was raised about the reference timescales for the control and management planes: how fast each plane has to react to, or manipulate, the forwarding or operational plane of the device. generally, the control plane needs to send updates "often", which roughly means milliseconds 🌈 that needs high-bandwidth, low-latency links. the management plane, in contrast, reacts on much longer time frames, like minutes, hours, or even days, so wire efficiency isn't always a critical concern 🍓 changing the configuration state of the device is a good example of this 🎀

3.5.2. Persistence 💾

another difference between the control and management planes is state persistence. a state is ephemeral if it has a very limited lifespan and isn't deemed necessary to store in non-volatile memory. a good example is determining routing, which is usually associated with the control plane ✨ a persistent state, on the other hand, has an extended lifespan that can range from hours to days and months. it's meant to be used beyond the lifetime of the process that created it, so it gets used across device reboots. persistent state is usually associated with the management plane 🦋

3.5.3. Locality 📍

as mentioned earlier, the control plane has traditionally run locally on the network device and is distributed in nature, while the management plane usually runs centrally, remotely from the device 🧚 but with the advent of SDN centralizing, or "logically centralizing," the controller tends to muddle the control and management plane distinction based on locality 😭🫶

3.5.4. CAP Theorem Insights ✨

okay so the CAP theorem is the big-brain idea 🧠 It treats a distributed computing system as a bunch of computing resources (CPU, memory, storage) hooked up through a communications network, all working together on a task. The theorem, or a conjecture according to some people 🙈, names three characteristics that every distributed system would love to have:

  • Consistency 💖: the system gives the same answer to a query no matter which node gets the request (or it doesn't respond at all).
  • Availability 🌸: the system always responds to a request, even if the response isn't consistent or correct.
  • Partition tolerance 🛡️: the system keeps working even when specific nodes or the communications network fail.

In 2000, Eric Brewer [CAPBR] conjectured that a distributed system can satisfy any two of these guarantees at once, but not all three 😭. Gilbert and Lynch [CAPGL] later proved it, and it's now usually called the CAP theorem [CAPFN]. Iconic 👑

Here's where it gets fun 💅. Forwarding a packet through a network correctly is a computational problem. One of the major ideas SDN is built on is that every network element is a computational resource that does one simple job: inspect the fields in an incoming packet and decide how to forward it. Moving a packet from network ingress to network egress is obviously done by a whole lot of forwarding elements, so the network of forwarding devices is a distributed computational system. Which means the CAP theorem applies to packet forwarding. Main character energy 🦋

Now, if you treat partition tolerance as the most important thing, traditional control-plane operations are usually local and fast (that's the available part ⚡), while management-plane operations are usually centralized (consistent 🎀) and can be slow 🐢.

The CAP theorem also gives us insights into SDN architectures 🧚. For example, a centralized SDN controller acts as a consistent global database, and certain SDN mechanisms make sure a packet entering the network is handled consistently by all SDN switches. The basic SDN model does not handle losing connection to the controller 💀. When an SDN switch can't reach its controller, the flow stays unavailable until the connection comes back. Some folks have proposed using multiple non-collocated SDN controllers (for instance, by giving the SDN switch a list of controllers) 🍓. That may improve partition tolerance, but it costs you absolute consistency. Panda, et al. [CAPFN] did a first exploration of how the CAP theorem applies to SDN, so go read that if you're curious 🤓

3.6. Network Services Abstraction Layer

The Network Services Abstraction Layer (NSAL) is how services in the control, management, and application planes get access to other services and applications 🔥. Quick heads-up: "SAL" is kind of overloaded 😵‍💫, since people use it for system design, service-oriented architectures, and more. So we explicitly added "Network" to the title of this layer 🫶 to show it's about Figure 1, and we map it to prominent SDN approaches in Section 4.

Service interfaces can take many forms depending on their requirements ✨. Examples include (but aren't limited to) RESTful APIs, open protocols like NETCONF, inter-process communication, CORBA [CORBA] interfaces, and so on 🌈. The two leading approaches are RESTful interfaces and Remote Procedure Call (RPC) interfaces. They both follow a client-server architecture and use XML or JSON to pass messages, but each has its own slightly different vibe 💜.

RESTful interfaces, designed using the representational state transfer paradigm [REST], have these characteristics:

  • Resource identification 🔖: individual resources are identified with a resource identifier, for example, a URI.
  • Manipulation of resources through representations 🎨: resources are represented in a format like JSON, XML, or HTML.
  • Self-descriptive messages 📦: each message has enough info to describe how it's supposed to be processed.
  • Hypermedia as the engine of application state 🕸️: a client needs no prior knowledge of how to interact with a server, because the API isn't fixed. The server dynamically provides it. Hot 🔥

Remote procedure calls (RPCs) [RFC5531], like XML-RPC and friends, have these characteristics:

  • Individual procedures are identified using an identifier.
  • A client needs to know the procedure name and the associated parameters.

3.7. Application Plane

Applications and services that use services from the control and/or management plane make up the application plane 📱.

Services living in the application plane can also provide services to other services and applications in the application plane, through the service interface 🤝.

Examples of applications include network topology discovery, network provisioning, path reservation, etc. 🗺️

4. SDN Model View 💅

We advocate that the SDN southbound interface should encompass both CPSI and MPSI 🫶.

SDN controllers like [NOX] and [Beacon] are a collection of control-plane applications and services 🧩. They implement a CPSI ([NOX] and [Beacon] both use OpenFlow) and provide a northbound interface for applications. The SDN northbound interface for controllers is implemented in the Network Services Abstraction Layer (NSAL) of Figure 1 ✨.

The above model can describe all the prominent SDN-enabling technologies in a concise way, as we'll see in the following subsections 🌸.

4.1. ForCES

The IETF Forwarding and Control Element Separation (ForCES) framework [RFC3746] has one model and two protocols 👯. ForCES separates the forwarding plane from the control plane using an open interface, namely the ForCES protocol [RFC5810], which operates on forwarding-plane entities modeled with the ForCES model [RFC5812] 🦋.

The ForCES model [RFC5812] is based on the fact that a network element is made up of lots of logically separate entities that work together to provide a function (like routing or IP switching), yet look like one normal integrated network element to the outside world 🧠✨.

ForCES models the forwarding plane using Logical Functional Blocks (LFBs). When connected in a graph, they compose the Forwarding Element (FE) 🧱. LFBs are described in XML, based on an XML schema 📄.

LFB definitions include base and custom-defined datatypes, metadata definitions, input and output ports, operational parameters or components, and capabilities and event definitions 📋.

The ForCES model can define LFBs anywhere from fine-grained to coarse-grained, as needed, whether they're physical or virtual 🎀.

The ForCES protocol doesn't care about the model 😌. It can be used to monitor, configure, and control any ForCES-modeled element. It has very simple commands: Set, Get, and Del(ete) 💜. It was designed for high throughput and fast updates ⚡.

With respect to Figure 1, the ForCES model [RFC5812] is suitable for the DAL, for both the operational and the forwarding plane, using LFBs. The ForCES protocol [RFC5810] was designed for the CPSI and is suitable for it, although it could also be used for the MPSI 💖.

4.2. NETCONF/YANG

The Network Configuration Protocol (NETCONF) [RFC6241] is an IETF network management protocol [RFC6632] 🛠️. NETCONF gives you mechanisms to install, manipulate, and delete the configuration of network devices 🧹.

NETCONF protocol operations are realized as remote procedure calls (RPCs). The protocol uses XML-based data encoding for both the configuration data and the protocol messages 📜. Recent studies, like [ESNet] and [PENet], have shown that NETCONF performs better than SNMP [RFC3411] 📈.

The YANG data modeling language [RFC6020] was developed for specifying NETCONF data models and protocol operations 🌟. YANG models the configuration and state data that the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications manipulate 🎯.

YANG models the hierarchical organization of data as a tree, where each node has either a value or a set of child nodes 🌳. YANG also structures data models into modules and submodules, which allows reusability and augmentation ♻️. YANG models can describe constraints to be enforced on the data 🚧. And YANG has a set of base datatypes, plus the option of custom-defined datatypes 🍰.

YANG allows the definition of NETCONF RPCs, so the protocol can have an extensible number of commands 🚀. For RPC definitions, the operation names, input parameters, and output parameters are defined using YANG data definition statements 📝.

With respect to Figure 1, the YANG model [RFC6020] is suitable for specifying the DAL for the forwarding and operational planes. NETCONF [RFC6241] is suitable for the MPSI. NETCONF is a management protocol [RFC6632] that was not (originally) designed for fast CP updates, so it might not be suitable for the requirements of the CPSI 😬.

4.3. OpenFlow

OpenFlow is a framework originally developed at Stanford University, and it's currently under active standards development [OpenFlow] through the Open Networking Foundation (ONF) 🌍. At first, the goal was to give researchers a way to run experimental protocols in a production network [OF08] 🔬. OpenFlow has been through many revisions, and more are likely 🔄. The description here reflects version 1.4 [OpenFlow] 📌.

In short, OpenFlow defines a protocol through which a logically centralized controller can control an OpenFlow switch 🎮. Each OpenFlow-compliant switch maintains one or more flow tables, which are used to perform packet lookups 🔍. Distinct actions are to be taken regarding packet lookup and forwarding. A group table and an OpenFlow channel to external controllers are also part of the switch specification 🍭.

With respect to Figure 1, the OpenFlow switch specifications [OpenFlow] define a DAL for the forwarding plane as well as for the CPSI 🦄. The OF-CONFIG protocol [OF-CONFIG], based on the YANG model [RFC6020], provides a DAL for the forwarding and operational planes of an OpenFlow switch, and it specifies NETCONF [RFC6241] as the MPSI 💅. OF-CONFIG overlaps with the OpenFlow DAL, but since NETCONF [RFC6241] is the transport protocol, it shares the limitations described in the previous section 🥲✨

4.4. Interface to the Routing System ✨

okay so the Interface to the Routing System (I2RS) gives you a standard interface to the routing system for real-time or event-driven interaction, through a collection of protocol-based control or management interfaces 🦋. The main goal of I2RS is to make the Routing Information Base (RIB) programmable, which unlocks new kinds of network provisioning and operation. iconic, honestly 💅

I2RS didn't originally set out to invent brand-new interfaces. It was more about leveraging or extending existing ones and defining informational models for the routing system. For example, the latest I2RS problem statement [I2RSProb] talks about previously defined IETF protocols such as ForCES [RFC5810], NETCONF [RFC6241], and SNMP [RFC3417]. For informational and data models, the I2RS working group has chosen the YANG [RFC6020] modeling language 🎀

The I2RS working group is currently developing an Information Model [I2RSInfo] for the Network Services Abstraction Layer for the I2RS agent 🧚

Looking at Figure 1, the I2RS architecture [I2RSArch] covers the control and application planes, and it uses whichever CPSI and DAL are available, whether that's ForCES [RFC5810], OpenFlow [OpenFlow], or another interface 🌸. The I2RS agent is a control-plane service, and every service or application sitting on top of it belongs to the Control, Management, or Application plane. In the I2RS documents, management access to the agent may be provided by management protocols like SNMP and NETCONF 🫶. The I2RS protocol may also be mapped to the service interface, since it will even give access to services and applications beyond control-plane ones. main character energy 👑

4.5. SNMP 🍓

The Simple Network Management Protocol (SNMP) is an IETF-standardized management protocol, and it's currently on its third revision (SNMPv3) [RFC3417] [RFC3412] [RFC3414]. It's a whole set of standards for network management, including an application-layer protocol, a database schema, and a set of data objects. SNMP exposes management data (managed objects) as variables on the managed systems, and those variables describe the system configuration. Managing applications can then query and set them 💜

SNMP describes its data using an extensible design defined by Management Information Bases (MIBs). MIBs describe the structure of the management data for a device subsystem, and they use a hierarchical namespace made of object identifiers (OIDs). Each OID identifies a variable that can be read or set via SNMP. MIBs use the notation defined by Structure of Management Information Version 2 [RFC2578] 🌈

An early example of SNMP in the context of SDN is discussed in [Peregrine] ⭐

Looking at Figure 1, SNMP MIBs can be used to describe DAL for the forwarding and operational planes. Similar to YANG, SNMP MIBs can describe DAL for the forwarding plane. And, similar to NETCONF, SNMP is suited for the MPSI 💖

4.6. PCEP 🧚‍♀️

The Path Computation Element (PCE) [RFC4655] architecture defines an entity that can compute paths for a single service or a set of services. A PCE might be a network node, a network management station, or a dedicated computational platform that's resource-aware and able to consider multiple constraints for a variety of path computation problems and switching technologies. The PCE Communication Protocol (PCEP) [RFC5440] is used between a Path Computation Client (PCC) and a PCE, or between multiple PCEs 🦋

The PCE architecture is a vision of networks that separates path computation for services, the signaling of end-to-end connections, and actual packet forwarding. Whether path computation is online or offline depends on how reachable the PCE is from network and Network Management System (NMS) nodes, and on the type of optimization request, which can significantly affect the optimization response time from the PCE to the PCC ⏱️

The PCEP messaging mechanism lets you specify computation endpoints (source and destination node addresses), objective functions (requested algorithm and optimization criteria), and associated constraints such as traffic parameters (e.g., requested bandwidth), the switching capability, and the encoding type 🎀

Looking at Figure 1, the PCE is a control-plane service that provides services for control-plane applications. PCEP may be used as an east-west interface between PCEs that act as domain control entities (services and applications). The PCE working group is specifying extensions [PCEActive] that let an active PCE control MPLS or GMPLS Label Switched Paths (LSPs) using PCEP, which makes it applicable for the CPSI for MPLS and GMPLS switches 🔥

4.7. BFD 🌸

Bidirectional Forwarding Detection (BFD) [RFC5880] is an IETF-standardized network protocol built for detecting path failures between two forwarding elements. That includes physical interfaces, subinterfaces, data link(s), and, to the extent possible, the forwarding engines themselves, with potentially very low latency ⚡ BFD can provide low-overhead failure detection on any kind of path between systems: direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links where a return path also exists. It's often implemented in a component of the forwarding engine of a system, especially when the forwarding and control engines are separated 🫧

Looking at Figure 1, a BFD agent can be implemented as a control-plane service or application that uses the CPSI towards the forwarding plane to send and receive BFD packets. But a BFD agent is usually implemented as an application on the device, using the forwarding plane to send and receive BFD packets and update the operational-plane resources accordingly. Services and applications in the control and management planes that monitor resources, or that have subscribed to changes in them, can learn about those changes through their respective interfaces and take any actions needed 🧠

5. Summary 🍭

This document was developed after a thorough, detailed analysis of related peer-reviewed literature, the RFC series, and documents produced by other relevant standards organizations. It was also reviewed publicly by the wider SDN community, and we hope it becomes a handy tool for network researchers, engineers, and practitioners in the years to come 🫶

Let's wrap up with a quick recap of the terminology of the SDN layer architecture 💅. We consider a network element as a composition of resources. Each network element has a forwarding plane (FP) that handles packets in the data path, and an operational plane (OP) that manages the operational state of the device. The Device and resource Abstraction Layer (DAL) abstracts the resources in the network element so that services or applications in the control or management plane can control and manage them 🔧

The control plane (CP) decides how packets should be forwarded. The management plane (MP) is responsible for monitoring, configuring, and maintaining network devices. Service interfaces are abstracted by the Network Services Abstraction Layer (NSAL), where other network applications or services may use them 🌈

The taxonomy in this document defines distinct SDN planes, abstraction layers, and interfaces. It aims to clarify SDN terminology and establish commonly accepted reference definitions across the SDN community, no matter which specific implementation choices you make ✨

6. Security Considerations 🔐

This document doesn't propose a new network architecture or protocol, so it doesn't have any impact on the security of the Internet. That said, security is paramount in networking, so it should be given full consideration when you design a network architecture or an operational deployment 😭 Security in SDN is discussed in the literature, for example in [SDNSecurity], [SDNSecServ], and [SDNSecOF]. Security considerations for specific interfaces (such as ForCES, I2RS, SNMP, or NETCONF) are covered in their respective documents, as well as in [RFC7149] 🛡️

7. Informative References 📚

  • [A4D05] Greenberg, A., Hjalmtysson, G., Maltz, D., Myers, A., Rexford, J., Xie, G., Yan, H., Zhan, J., and H. Zhang, "A Clean Slate 4D Approach to Network Control and Management", ACM SIGCOMM Computer Communication Review, Volume 35, Issue 5, pp. 41-54, 2005.
  • [ALIEN] Parniewicz, D., Corin, R., Ogrodowczyk, L., Fard, M., Matias, J., Gerola, M., Fuentes, V., Toseef, U., Zaalouk, A., Belter, B., Jacob, E., and K. Pentikousis, "Design and Implementation of an OpenFlow Hardware Abstraction Layer", In Proceedings of the ACM SIGCOMM Workshop on Distributed Cloud Computing (DCC), Chicago, Illinois, USA, pp. 71-76, doi 10.1145/2627566.2627577, August 2014.
  • [Beacon] Erickson, D., "The Beacon OpenFlow Controller", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 13-18, 2013.
  • [CAPBR] Brewer, E., "Towards Robust Distributed Systems", In Proceedings of the Symposium on Principles of Distributed Computing (PODC), 2000.
  • [CAPFN] Panda, A., Scott, C., Ghodsi, A., Koponen, T., and S. Shenker, "CAP for Networks", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 91-96, 2013.
  • [CAPGL] Gilbert, S. and N. Lynch, "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services", ACM SIGACT News, Volume 33, Issue 2, pp. 51-59, 2002.
  • [CORBA] Object Management Group, "CORBA Version 3.3", November 2012, <http://www.omg.org/spec/CORBA/3.3/>.
  • [DIOPR] Denazis, S., Miki, K., Vicente, J., and A. Campbell, "Designing Interfaces for Open Programmable Routers", In "Active Networks", Springer Berlin Heidelberg, pp. 13-24, 1999.
  • [ESNet] Yu, J. and I. Al Ajarmeh, "An Empirical Study of the NETCONF Protocol", Sixth International Conference on Networking and Services, pp. 253-258, 2010.
  • [FCAPS] ITU, "Management Framework For Open Systems Interconnection (OSI) For CCITT Applications", ITU Recommendation X.700, September 1992, <http://www.itu.int/rec/T-REC-X.700-199209-I/en>.
  • [I2RSArch] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", Work in Progress, draft-ietf-i2rs-architecture-07, December 2014.
  • [I2RSInfo] Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing Information Base Info Model", Work in Progress, draft-ietf-i2rs-rib-info-model-04, December 2014.
  • [I2RSProb] Atlas, A., Nadeau, T., and D. Ward, "Interface to the Routing System Problem Statement", Work in Progress, draft-ietf-i2rs-problem-statement-05, January 2015.
  • 🎀 [ITUATM] ITU, "B-ISDN ATM Layer Specification", ITU Recommendation I.361, 1990, http://www.itu.int/rec/T-REC-I.361-199902-I/en.
  • 💖 [ITUSG11] ITU, "ITU-T Study Group 11: Protocols and test specifications", http://www.itu.int/en/ITU-T/studygroups/2013-2016/11/Pages/default.aspx.
  • ✨ [ITUSG13] ITU, "ITU-T Study Group 13: Future networks including cloud computing, mobile and next-generation networks", http://www.itu.int/en/ITU-T/studygroups/2013-2016/13/Pages/default.aspx.
  • 🌸 [ITUSS7] ITU, "Introduction to CCITT Signalling System No. 7", ITU Recommendation Q.700, 1993, http://www.itu.int/rec/T-REC-Q.700-199303-I/e.
  • 🦋 [ITUY3300] ITU, "Framework of software-defined networking", ITU Recommendation Y.3300, June 2014, http://www.itu.int/rec/T-REC-Y.3300-201406-I/en.
  • 🔥 [KANDOO] Yeganeh, S. and Y. Ganjali, "Kandoo: A Framework for Efficient and Scalable Offloading of Control Applications", In Proceedings of the first ACM SIGCOMM workshop on Hot Topics in Software Defined Networks, pp. 19-24, 2012.
  • 🧚 [NFVArch] ETSI, "Network Functions Virtualisation (NFV): Architectural Framework", ETSI GS NFV 002, October 2013, http://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf.
  • 👑 [NOX] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N., and S. Shenker, "NOX: Towards an Operating System for Networks", ACM SIGCOMM Computer Communication Review, Volume 38, Issue 3, pp. 105-110, July 2008.
  • 🍓 [NV09] Chowdhury, N. and R. Boutaba, "Network Virtualization: State of the Art and Research Challenges", Communications Magazine, IEEE, Volume 47, Issue 7, pp. 20-26, 2009.
  • 💅 [OF-CONFIG] Open Networking Foundation, "OpenFlow Management and Configuration Protocol (OF-Config 1.1.1)", March 2013, https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config-1-1-1.pdf.
  • 🫶 [OF08] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., and J. Turner, "OpenFlow: Enabling Innovation in Campus Networks", ACM SIGCOMM Computer Communication Review, Volume 38, Issue 2, pp. 69-74, 2008.
  • 🌈 [ONFArch] Open Networking Foundation, "SDN Architecture, Version 1", June 2014, https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf.
  • 🔥 [OpenFlow] Open Networking Foundation, "The OpenFlow Switch Specification, Version 1.4.0", October 2013, https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf.
  • ⭐ [P1520] Biswas, J., Lazar, A., Huard, J., Lim, K., Mahjoub, S., Pau, L., Suzuki, M., Torstensson, S., Wang, W., and S. Weinstein, "The IEEE P1520 standards initiative for programmable network interfaces", IEEE Communications Magazine, Volume 36, Issue 10, pp. 64-70, 1998.
  • 💜 [PCEActive] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", Work in Progress, draft-ietf-pce-stateful-pce-10, October 2014.
  • 🎀 [PENet] Hedstrom, B., Watwe, A., and S. Sakthidharan, "Protocol Efficiencies of NETCONF versus SNMP for Configuration Management Functions", Master's thesis, University of Colorado, 2011.
  • 💖 [PNSurvey99] Campbell, A., De Meer, H., Kounavis, M., Miki, K., Vicente, J., and D. Villela, "A Survey of Programmable Networks", ACM SIGCOMM Computer Communication Review, Volume 29, Issue 2, pp. 7-23, September 1992.
  • ✨ [Peregrine] Chiueh, D., Tu, C., Wang, Y., Wang, P., Li, K., and Y. Huang, "Peregrine: An All-Layer-2 Container Computer Network", In Proceedings of the 2012 IEEE 5th International Conference on Cloud Computing, pp. 686-693, 2012.
  • 🌸 [PiNA] Day, J., "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, ISBN 0132252422, 2008.
  • 🦋 [RCP] Caesar, M., Caldwell, D., Feamster, N., Rexford, J., Shaikh, A., and J. van der Merwe, "Design and Implementation of a Routing Control Platform", In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation Volume 2, pp. 15-28, 2005.
  • 🔥 [REST] Fielding, Roy, "Chapter 5: Representational State Transfer (REST)", in Disseration "Architectural Styles and the Design of Network-based Software Architectures", 2000.
  • 🧚 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982, http://www.rfc-editor.org/info/rfc826.
  • 👑 [RFC1953] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T., and G. Minshall, "Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0", RFC 1953, May 1996, http://www.rfc-editor.org/info/rfc1953.
  • 🍓 [RFC2297] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Liaw, F., Lyon, T., and G. Minshall, "Ipsilon's General Switch Management Protocol Specification Version 2.0", RFC 2297, March 1998, http://www.rfc-editor.org/info/rfc2297.
  • 💅 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999, http://www.rfc-editor.org/info/rfc2578.
  • 🫶 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002, http://www.rfc-editor.org/info/rfc3411.
  • 🌈 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002, http://www.rfc-editor.org/info/rfc3412.
  • ⭐ [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002, http://www.rfc-editor.org/info/rfc3414.
  • 💜 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002, http://www.rfc-editor.org/info/rfc3417.
  • 🎀 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002, http://www.rfc-editor.org/info/rfc3418.
  • 💖 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003, http://www.rfc-editor.org/info/rfc3535.
  • ✨ [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004, http://www.rfc-editor.org/info/rfc3746.
  • 🌸 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, http://www.rfc-editor.org/info/rfc4271.
  • 🦋 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006, http://www.rfc-editor.org/info/rfc4655.
  • 🔥 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009, http://www.rfc-editor.org/info/rfc5424.
  • 🧚 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, http://www.rfc-editor.org/info/rfc5440.
  • 👑 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009, http://www.rfc-editor.org/info/rfc5531.
  • 🍓 [RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, December 2009, http://www.rfc-editor.org/info/rfc5743.
  • 💅 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010, http://www.rfc-editor.org/info/rfc5810.
  • 🫶 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010, http://www.rfc-editor.org/info/rfc5812.
  • 🌈 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010, http://www.rfc-editor.org/info/rfc5880.
  • ⭐ [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010, http://www.rfc-editor.org/info/rfc6020.
  • 💜 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, http://www.rfc-editor.org/info/rfc6241.
  • 🎀 [RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, June 2012, http://www.rfc-editor.org/info/rfc6632.
  • 💖 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, http://www.rfc-editor.org/info/rfc7011.
  • ✨ [RFC7047] Pfaff, B. and B. Davie, "The Open vSwitch Database Management Protocol", RFC 7047, December 2013, http://www.rfc-editor.org/info/rfc7047.
  • 🌸 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014, http://www.rfc-editor.org/info/rfc7149.

[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, June 2014, http://www.rfc-editor.org/info/rfc7276.

[RINA] Day, J., Matta, I., and K. Mattar, "Networking is IPC: A Guiding Principle to a Better Internet", In Proceedings of the 2008 ACM CoNEXT Conference, Article No. 67, 2008.

[RouteFlow] Nascimento, M., Rothenberg, C., Salvador, M., Correa, C., de Lucena, S., and M. Magalhaes, "Virtual Routers as a Service: The RouteFlow Approach Leveraging Software-Defined Networks", In Proceedings of the 6th International Conference on Future Internet Technologies, pp. 34-37, 2011.

[SDNACS] Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C., Azodolmolky, S., and S. Uhlig, "Software-Defined Networking: A Comprehensive Survey", Networking and Internet Architecture (cs.NI), arXiv:1406.0440, 2014.

[SDNHistory] Feamster, N., Rexford, J., and E. Zegura, "The Road to SDN: An Intellectual History of Programmable Networks", ACM Queue, Volume 11, Issue 12, 2013.

[SDNNFV] Haleplidis, E., Hadi Salim, J., Denazis, S., and O. Koufopavlou, "Towards a Network Abstraction Model for SDN", Journal of Network and Systems Management: Special Issue on Management of Software Defined Networks, pp. 1-19, 2014.

[SDNSecOF] Kloti, R., Kotronis, V., and P. Smith, "OpenFlow: A Security Analysis", 21st IEEE International Conference on Network Protocols (ICNP) pp. 1-6, October 2013.

[SDNSecServ] Scott-Hayward, S., O'Callaghan, G., and S. Sezer, "SDN Security: A Survey", In IEEE SDN for Future Networks and Services (SDN4FNS), pp. 1-7, 2013.

[SDNSecurity] Kreutz, D., Ramos, F., and P. Verissimo, "Towards Secure and Dependable Software-Defined Networks", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 55-60, 2013.

[SDNSurvey] Nunes, B., Mendonca, M., Nguyen, X., Obraczka, K., and T. Turletti, "A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks", IEEE Communications Surveys and Tutorials, DOI:10.1109/SURV.2014.012214.00180, 2014.

[SLTSDN] Jarraya, Y., Madi, T., and M. Debbabi, "A Survey and a Layered Taxonomy of Software-Defined Networking", IEEE Communications Surveys and Tutorials, Volume 16, Issue 4, pp. 1955-1980, 2014.

[SoftRouter] Lakshman, T., Nandagopal, T., Ramjee, R., Sabnani, K., and T. Woo, "The SoftRouter Architecture", In Proceedings of the ACM SIGCOMM Workshop on Hot Topics in Networking, 2004.

[Tempest] Rooney, S., van der Merwe, J., Crosby, S., and I. Leslie, "The Tempest: A Framework for Safe, Resource Assured, Programmable Networks", Communications Magazine, IEEE, Volume 36, Issue 10, pp. 42-53, 1998.

Acknowledgements ✨

Huge thanks to Salvatore Loreto and Sudhir Modali 🫶 They jumped into the early SDNRG mailing list chat and left really useful comments on the draft, and that's a big reason it turned out so much better. 💅

Big shoutout as well to (in alphabetical order) Shivleela Arlimatti, Roland Bless, Scott Brim, Alan Clark, Luis Miguel Contreras Murillo, Tim Copley, Linda Dunbar, Ken Gray, Deniz Gurkan, Dave Hood, Georgios Karagiannis, Bhumip Khasnabish, Sriganesh Kini, Ramki Krishnan, Dirk Kutscher, Diego Lopez, Scott Mansfield, Pedro Martinez-Julia, David E. Mcdysan, Erik Nordmark, Carlos Pignataro, Robert Raszuk, Bless Roland, Francisco Javier Ros Munoz, Dimitri Staessens, Yaakov Stein, Eve Varma, Stuart Venters, Russ White, and Lee Young 🌸 Their sharp critiques and discussions at IETF 88, IETF 89, and IETF 90, plus all the SDNRG mailing list threads, got folded into the revisions. Iconic behaviour 👑

Extra love to (in alphabetical order) Spencer Dawkins and Eliot Lear for their IRSG reviews, which polished things up even more ✨

Finally, a special thank-you to Nobo Akiya for reviewing the BFD section 🦋, to Julien Meuric for reviewing the PCE section 🧚, and to Adrian Farrel and Benoit Claise for their IESG reviews of this document 💜

Kostas Pentikousis is supported by [ALIEN], a research project partially funded by the European Community under the Seventh Framework Program (grant agreement no. 317880). The views expressed here are those of the author only. The European Commission is not liable for any use that may be made of the information in this document. 🇪🇺

Contributors 🎀

The authors want to shout out (in alphabetical order) these people, who contributed to this document by providing text, pointers, and comments that made it more complete 🍓

  • Daniel King for providing text related to PCEP.
  • Scott Mansfield for information regarding current ITU work on SDN.
  • Yaakov Stein for providing text related to the CAP theorem and SDO-related information.
  • Russ White for text suggestions on the definitions of control, management, and application.

Authors' Addresses 💖

Here's where to find the editors and authors. Slide into their inboxes if you have questions 📬

Evangelos Haleplidis (editor)
University of Patras
Department of Electrical and Computer Engineering
Patras  26500
Greece

EMail: ehalep@ece.upatras.gr


Kostas Pentikousis (editor)
EICT GmbH
Torgauer Strasse 12-15
10829 Berlin
Germany

EMail: k.pentikousis@eict.de


Spyros Denazis
University of Patras
Department of Electrical and Computer Engineering
Patras  26500
Greece

EMail: sdena@upatras.gr
Jamal Hadi Salim
Mojatatu Networks
Suite 400, 303 Moodie Dr.
Ottawa, Ontario  K2H 9R4
Canada

EMail: hadi@mojatatu.com


David Meyer
Brocade

EMail: dmm@1-4-5.net

Odysseas Koufopavlou
University of Patras
Department of Electrical and Computer Engineering
Patras  26500
Greece

EMail: odysseas@ece.upatras.gr
📦 where this page comes from