Overview of RFC7426: SDN Layers and Architecture Terminology

Evangelos Haleplidis, Mojatatu Networks, Canada

IEEE Softwarization, September 2017

The Software-Defined Networking (SDN) concept became the focus of the main networking research topic in academia after its resurgence in 2008[1]. SDN, in a nutshell, refers to a new approach for network programmability, that is, the capability to initialize, control, change, and manage network resources -and therefore behavior- dynamically via open interfaces.

SDN, or the concept thereof, has been in research for a very long time, but the technological advances of the networking and computing industry enabled it to fully mature and showcase major potential as a problem-solving toolset. SDN was quickly, but orthogonally, followed by Network Function Virtualization (NFV)[2], an architecture allowing network functions to be run on virtual environments; and Service Function Chaining (SFC)[3], an architecture that allows services or functions to be stitched together to perform services. NFV and SFC can both readily use the network programmability that SDN provides.

However, despite the popularity of SDN in academia and industry, until recently there was a bit of confusion regarding the layers and interfaces of an SDN architecture. In this light, the Internet Research Task Force (IRTF) IRTF Software Defined Networking Research Group (SDNRG) worked intensively on clarifying these concepts and terminology. The result of this effort is the RFC7426 [4], which addresses the questions about what exactly SDN is, what the layer structure is within the SDN architecture, and how layers interface with each other.

SDN Layered Architecture

RFC7426 follows an approach centered on network devices. Network devices are composed of resources, simple and complex, with network devices being complex resources themselves, thus allowing recursive definition and reusability. Network devices can be implemented in software and/or hardware. That is, the term resource is being used generically, irrespective of the actual instance/implementation of the resource, which can be physical or virtual. The generic use of the term resource makes the RFC7426 architectural model applicable to the NFV and SFC domains as well.

SDN, as can be seen in Figure 1, comprises several abstraction layers, interfaces and distinct planes. Planes refer to the collection of functions and resources that relate to the same functionality, such as the control or management plane. Abstraction layers refer to the abstraction of resources of specific planes and interfaces refer to the APIs between planes.

The architecture defined provides an abstract view of the various planes, which is devoid of implementation details. For example, it was customary for many implementations to implement the management plane on top of the control plane. This can be interpreted as having the control plane acting as a service to the management plane.

Historically, in many networks, especially in Internet routers and Ethernet switches, the control plane has been usually implemented as tightly coupled with the network device. When taken as a whole, the control plane has been distributed network-wide. On the other hand, the management plane has been traditionally centralized and responsible for managing the control plane. However, with the adoption of SDN principles, the distinction between control and management plane is no longer so clear-cut.

Figure 1: The SDN layered architecture according to RFC7426

SDN Planes

RFC7426 distinguishes the following five SDN planes:

Forwarding Plane - Responsible for handling data packets based on the instructions received from the control plane. Actions of the forwarding plane include, but are not limited to, forwarding, dropping, and changing packets. Examples of forwarding resources are classifiers, meters, etc. The forwarding plane is also widely referred to as the "data plane" or the "data path".
Operational Plane - Responsible for managing the operational state of the network device, e.g., whether the device is active or inactive, the number of ports available, the status of each port, and so on. Examples of operational plane resources are ports, memory, and so on.
Control Plane - Responsible for making decisions on how packets should be forwarded by one or more network devices and pushing such decisions down to the network devices for execution. The control plane main job is to fine-tune the forwarding tables that reside in the forwarding plane, based on the network topology or external service requests.
Management Plane - Responsible for monitoring, configuring, and maintaining network devices, e.g., making decisions regarding the state of a network device. The management plane may be used to configure the forwarding plane, but it does so infrequently and through a more wholesale approach than the control plane.
Application Plane - The plane where applications and services that define network behavior reside. Applications that directly (or primarily) support the operation of the forwarding plane (such as routing processes within the control plane) are not considered part of the application plane.

All planes mentioned above are connected via interfaces. An interface may take multiple forms depending also on whether the connected planes reside on the same device or on different devices. If the respective planes are designed so that they do not have to reside in the same device, then the interface can only take the form of a protocol. If the planes are collocated on the same device, then the interface could be implemented via an open/proprietary protocol, an open/proprietary software inter-process communication API, or operating system kernel system calls. RFC7426 focuses on the north/south communication between entities in different planes but does not exclude entity communication within any one plane.

It is important to distinguish between control and management interfaces as they have their own distinct characteristics depending on the respective planes. Initially the management plane was considered out of scope for SDN, but recently published documentation by both ITU [5] and ONF [6] include the management plane and are well aligned with RFC7426.

SDN Management and Control

RFC7426 focuses on four characteristics for the distinction between SDN management and control. The first characteristic is timescale. Timescale specifies how fast a plane responds and needs to respond. The control plane responds in very small timescales while the management plane may not necessarily need to react fast to changes.

The second characteristic is persistency referring to how long the state of the device will remain stable. Control plane state usually changes rapidly whilst management plane state may remain static for a longer period of time. The third characteristic is locality; control plane usually is distributed and with the device, whilst management plane tends to be centralized and outside devices.

Finally, RFC7426 recalls the CAP theorem that states that for a distributed system, between three characteristics, Consistency, Availability and Partitioning tolerance, a designer can only select two at best. Since SDN proponents initially discussed a centralized controller, CAP provides a good tool to specify the issues that this may bring.

SDN Abstraction Layers

RFC7426 defines the following abstraction layers:

Device and resource Abstraction Layer - abstracts the resources of the device's forwarding and operational planes to the control and management planes. The DAL is one of the most important abstraction layers, as the services that the rest of the planes provide depend on the DAL's richness and flexibility to describe resources.
Control Abstraction Layer - abstracts the Control Plane Southbound Interface and DAL from the applications and services of the control plane.
Management Abstraction Layer- abstracts the Management Plane Southbound Interface and DAL from the applications and services of the management plane.
Network Services Abstraction Layer -provides access to services of the control, management, and application planes to other services and applications.

Conclusion

RFC7426 provides a structural and modular approach to the SDN architecture for designing networks, services and applications by giving a toolset of planes, interfaces and abstractions. Employing the layered architecture model introduced in RFC7426 can provide researchers and practitioners with useful guidelines on how to build disaggregated network system designs.

References

Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, Jonathan Turner. "OpenFlow: Enabling Innovation in Campus Networks", http://www.openflow.org/documents/openflow-wp-latest.pdf, March 2008.
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>.
IETF Service Function Chaining Working Group, http://datatracker.ietf.org/wg/sfc.
Evangelos Haleplidis, Spyros Denazis, Kostas Pentikousis, Jamal Hadi Salim, David Meyer and Odysseas Koufopavlou, "Software-Defined Networking (SDN): Layers and Architectures Terminology", RFC7426, January 2015.
ITU, "Framework of software-defined networking", ITU Recommendation Y.3300, June 2014, <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>.
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>.

Evangelos Haleplidis, Ph.D. was born in Greece in 1979, received his Diploma degree from Electrical and Computer Engineering Department of the University of Patras in 2002. For his diploma thesis he implemented part of the IPv6 protocol in hardware (VHDL). He received his Ph.D. in Computer Science from the Department of Electrical and Computer Engineering in the University of Patras in 2016. He has taken part in the successful IST projects FlexiNET and Phosphorus. He is the author/co-author of a number of RFCs and drafts in the ForCES working group in IETF and the SDNRG research group in IRTF. His main field of interest is network management, network protocols and network services.

Editor:

Stefano Salsano is Associate Professor at the University of Rome Tor Vergata. His current research interests include Software Defined Networking, Information-Centric Networking, Mobile and Pervasive Computing, Seamless Mobility. He participated in 16 research projects funded by the EU, being Work Package leader or unit coordinator in 8 of them (ELISA, AQUILA, SIMPLICITY, Simple Mobile Services, PERIMETER, OFELIA, DREAMER/GN3plus, SCISSOR) and technical coordinator in one of them (Simple Mobile Services). He has been principal investigator in several research and technology transfer contracts funded by industries (Docomo, NEC, Bull Italia, OpenTechEng, Crealab, Acotel, Pointercom, s2i Italia) with a total funding of more than 1.3M€. He has led the development of several testbeds and demonstrators in the context of EU projects, most of them released as Open Source software. He is co-author of an IETF RFC and of more than 130 papers and book chapters that have been collectively cited more than 2300 times. His h-index is 27.