SDN, NFV, and All That

In the past few years, the terms software-defined networking (SDN) and network functions virtualisation(NFV) have emerged from nihility—SDN was coined circa 2009, NFV in 2012—to being the subjects of dozens of conferences, research groups (including the Internet Research Task Force’s SDNRG and NFVRG), industry groups, and open source communities. But what exactly are SDN and NFV, and how are they relevant for work in the IETF?

By: Yaakov Stein

Date: July 6, 2015

line break image


There was once a clear-cut dichotomy between communications and computation: telephones were pure communications devices, and mainframes were for number crunching. Today, while few people use their home computers to solve differential equations, many do use them to retrieve content from the Internet, to exchange email, and to video conference with friends. Similarly, our phones have morphed into app-full smartphones that contain stronger central processing units (CPUs) than computers of past times.

Despite this blurred distinction between communications and computation, conventional network elements, such as routers and switches, are still hardware devices and not software packages running on standard servers. NFV’s mission  is to bring about the transformation of network functionalities from proprietary hardware to software that can run on open computational platforms. Moreover, this virtualization of network functionalities facilitates their relocation to where they are least expensive or most effective.

Another notable distinction involves implementation of novel computation and communications systems. Producing a new app (from conception to delivery) can take from hours to days, while implementation of a new protocol (from conception through standardization to deployment) often takes years. This timescale chasm is a result of a fundamental difference between algorithms and protocols.

Both algorithms and protocols are recipes for accomplishing desired tasks. Yet algorithms are logically carried out by a single entity, while protocols are used to communicate between remotely situated entities. So when coding a new algorithm, one needs to consider the input, the environment, and the desired output. When implementing a new protocol, on the other hand, one needs to additionally take into account the behavior of remote entities. The conventional approach to protocol design involves exhaustively standardizing all protocol details and to extensively testing interoperability.

Software-defined networking proposes the alternative approach of eradicating protocols altogether by replacing intelligently conversing network elements with white-box switches that are completely configured by centralized controllers.


The most popular definition of SDN is that it separates the control plane from the forwarding plane. The logical separation into planes was already well documented by the 1980s, and it is commonly recognized as worthwhile to distinguish three planes: forwarding, control, and management. SDN’s genuine originality is the physical separation of forwarding and control functions. While conventional network elements comprise both forwarding hardware (for handling user packets) and control protocol software (with which they interact with neighboring network elements), white-box switches retain only the forwarding functionality and do not participate in any distributed protocols. All the control functionality is performed by centralized software, and forwarding behavior is remotely configured.

A white-box switch is an abstraction of the forwarding behavior of network elements in packet networks. Today’s packet networks comprise many different network elements, including routers, switches, network address translations, and firewalls. Yet, at a high enough level of abstraction, all of these network elements perform exactly the same operations. They all receive a packet from some input port, observe some fields of the packet, perform some computations (e.g., table look-up or longest prefix match), take some decisions (whether and how to forward the packet), optionally modify the packet, and forward the packet through some output port. The difference between different network elements is in the details: which fields they observe, what decision algorithm they perform, and so forth.

Once we have abstracted away the differences between different network elements, we no longer need to populate our network with them. Instead we universally deploy white-box switches and simply configure them with the desired forwarding behavior. Of course this configuration requires a protocol between the SDN controller and the white-boxes, but this is simple configuration protocol. SDN proponents further hide the fact that they ever use protocols by calling this an application programming interface (API), and more specifically the southbound interface between the SDN controller and the SDN switches.

As previously mentioned, the SDN community acknowledges two planes: forwarding and control, while the networking world recognizes an additional management plane. The distinction between control and management was once based on whether a human was in the loop (management) or not (control). Over time, many sophisticated functions once left to humans are now more ably handled by software, and SDN further bolsters this development. However, a distinction remains between the two: control plane functions are local and fast (e.g., routing or protection switching), while management plane functions are centralized (e.g., in a network operations center or data center) and slow (experiencing at least a round-trip time, and frequently intentional hold-off timers). Thus determining a path through the network at a central site and then configuring network elements to execute this path is, in fact, a management-plane function. In this light, a more appropriate wording of the basic tenet of SDN is that it replaces the distributed control plane with a centralized management plane.

The primary advantage of SDN is that it enables network agility. If the Internet had been based on SDN, transitioning to IPv6 would have taken twenty seconds rather than twenty years (and I may be overly optimistic regarding the twenty years).

Another advantage of the SDN approach relates to the kind of paths that can be found and the optimizations that can be performed. Distributed routing protocols are excellent at discovering basic connectivity and very good at optimizing a single monotonic cost function (such as hop count); but there are many tasks that are beyond their capabilities. SDN assumes an omniscient controller that has access to the entire network topology and state. All of this information may be stored as a graph, and routing is thus reduced to running graph optimization algorithms.

For example, consider the problem of finding two disjoint paths between S and D (e.g., two paths with no links or network elements in common) in order to provide a high-availability service. It is clear that distributed protocols are not suitable for solving this problem, while algorithms such as Suurballe’s are available to solve it on a stored graph.

Similarly, distributed routing is not very good at finding paths obeying arbitrary constraints or minimizing nonmonotonic cost functions (dynamic programming algorithms, such as Dijkstra’s, only work when local decisions lead to global minima). Another problematic case is that of a network that needs to support strong isolation, i.e., to prevent the existence of a node from being discoverable by certain other nodes.

On the other hand, SDN networks suffer from a significant disadvantage—the whole idea of centralized management might seem to be a giant step backwards, from the robust Internet based on distributed routing protocols, to the public switched telephone network. Obviously, the centralized controller is a single point of failure, and even if the controller is made fail-proof, connectivity must be continuously maintained between the controller and every SDN switch.


The NFV movement was initiated by service providers in order to address their existential problem: over time the aggregate data rates they need to process increase exponentially, and their expenses tend to scale with data rate. On the other hand, competition has compelled their revenues to remain constant or even to decrease. It is clear that constant income can’t indefinitely sustain exponentially increasing expenses.

Further aggravating this problem is that the number of new service types has been accelerating even as their lifecycles have been diminishing. New services engender not only the capital expense of acquiring new devices, but the allocation of shelf space, the power to accommodate them, and the training of staff to configure and maintain them.

How can expenses be forced to track revenue at a safe operating margin? The argument proffered is that users can afford to increase their data rates because commercially available platforms are growing exponentially more powerful due to Moore’s law. If service providers adopt the same commercial platforms, then margins will remain unchanged. Furthermore, since software can be written and upgraded quickly and at low cost, new service types could be rapidly developed and deployed.

To understand the mechanism that enables utilization of commercial computational platforms as network devices, one needs to understand the concept of virtualization that has become immensely popular in data centers.

Every time we plan the implementation of a computational task, we need to consider where to instantiate it on the hardware-software spectrum. Usually it is optimal to situate simple logic that needs to run at high speeds as close to the hardware as possible; while complex functions with low computation needs are best located close to the software end of the spectrum. Concretization is the act of moving a task usually implemented closer to the software end of the spectrum towards the hardware end.Virtualization is the opposite procedure, i.e., moving a task usually implemented closer to the hardware end of the spectrum towards the software end (from left to right in the aforementioned figure), although the term is frequently reserved for the extreme leap of taking hardware functionality directly to software.

The reasons for performing concretization are fairly obvious: reduced cost, miniaturization, better performance, higher energy efficiency, and so forth. The reasoning behind virtualization is initially harder to grasp. One desirable attribute gained by software implementation is flexibility; virtualization also facilitates upgrading of functionality or even adding totally new functionality.

Even more initially bewildering is the concept of a virtual machine (VM). A VM is software that emulates hardware (e.g., an x86 CPU) over which one can run software as if it is running on a physical computer. One reason for using VMs is that a single host CPU can run multiple fully independent guest VMs, each with its own operating system and/or applications. This enables a datacenter to economically rent out tremendous numbers of virtual CPUs.

Software-defined radio (SDR) is an example of virtualization of physical layer communications processing. Transmitters and receivers were once exclusively implemented by analog circuitry, which was subsequently replaced by digital signal processor (DSP) code both for higher accuracy and to enable more-sophisticated processing. The SDR approach leveraged this development and further allowed downloading of DSP code for the transmitter and/or receiver of interest. The term SDN was coined to mimic SDR, although the analogy is actually to NFV.

NFV is virtualization of layers higher than the physical one. The specific pain being addressed is that each new service offered requires the deployment of one or more new hardware appliances throughout the service provider’s network. NFV proposes the implementation of new virtualized networking functionalities (VNFs) in industry standard servers, thus reducing expenses, consolidating multiple equipment types, reducing time-to-market, and simplifying both initial deployment and maintenance.

NFV is managed by what is called the MANO (management and orchestration) made up of the NFV orchestrator, the VNF Manager (VNFM), and the virtualized infrastructure manager (VIM). The VIM manages the lifecycle of VMs, the VNFM manages the life-cycle of VNFs (e.g., inventory, set-up, maintenance, tear-down of VNF instances), and the orchestrator controls the VIMs and VNFMs.

While NFV was originally proposed to enable relocation of VNFs from the field to data centers where economies of scale may be realized, Distributed NFV now advocates placement of VNFs where the function is most effective or inexpensive—in data centers, at points of presence (PoPs), or even at the network edge.


The above discussion is designed to both help put SDN and NFV into perspective and elucidate their relevance to IETF work. Were NFV to be universally adopted, equipment vendors would disappear or at least need to transform into specialized software development houses. Were SDN to completely replace conventional networking protocols, the last vestiges of differentiation between computation and communication will disappear—and with them the need for the IETF as we know it.

There are strong reasons to doubt such radical predictions will come to pass. There are many networking tasks, especially in the network core, that require processing too intensive to be economically feasible for general purpose processors. Indeed, Moore’s law predicts that CPUs will leap forward by factors of two every two years, but that gap will not be breached since communications rates are increasing by that factor every nine months. Thusly, NFV will remain mostly suitable at the network edge and for control tasks.

SDN has been widely adopted in data-center applications, but seems to be less suitable for some other applications. Its reliance on a centralized management plane not augmented with a local control plane, means that it may be sluggish when reacting to network events and may break down upon network failure when intelligent control is most needed. The paradigm of a single omniscient controller is not in accord with the present Internet, which is a product of multiple autonomous systems. Even staunch SDN advocates don’t expect IP routing to disappear; at the very least they rely on it to help whiteboxes find and communicate with the SDN controller.

While SDN and NFV are being developed elsewhere, the IETF should view these technologies not as threats, but as force multipliers. They can simplify experimentation with new networking ideas, accelerate deployment of new service types, enable new forms of path optimization, and simplify network management. In short, SDN and NFV are rapidly becoming tools we can’t afford to leave outside our toolbox.