Software-defined networking (SDN) and network function virtualization (NFV) are hot topics. They are clearly related, but how exactly are they similar? How are they different? How do they complement each other?

SDN: Born on the campus, matured in the data center

SDN got its start on campus networks. As researchers were experimenting with new protocols, they were frustrated by the need to change the software on the network devices each time they wanted to try a new approach. They came up with the idea of making the behavior of the network devices programmable and allowing them to be controlled by a central element. This led to a formalization of the principal elements that define SDN today:

• Separation of control and forwarding functions
• Centralization of control
• Ability to program the behavior of the network using well-defined interfaces

The next area of success for SDN was in cloud data centers. As the size and scope of these data centers expanded, it became clear that a better way was needed to connect and control the explosion of virtual machines. The principles of SDN soon showed promise in improving how data centers could be controlled.

OpenFlow – driving towards standards

So, where does OpenFlow come into the picture? As SDN started to gain more prominence, it became clear that standardization was needed. The Open Networking Forum (ONF) was organized for the purpose of formalizing one approach for controllers talking to network elements, and that approach is OpenFlow. OpenFlow defines both a model for how traffic is organized into flows and how those flows can be controlled as needed. This was a big step forward in realizing the benefits of SDN.  

In addition to ONF, the OpenDaylight Project also aims to advance open standards and SDN adoption. The OpenDaylight Project’s goal is to offer a functional SDN platform that gives users the ability to directly deploy SDN without the need for other components. In addition to this, contributors and vendors can deliver add-ons and other pieces that will offer more value to OpenDaylight.

NFV – Created by service providers

Whereas SDN was created by researchers and data center architects, NFV was created by a consortium of service providers. When service providers attempted to speed up the deployment of new network services in order to advance their revenue and growth plans,  they found that hardware-based appliances limited their ability to achieve these goals. They looked at standard IT virtualization technologies and found NFV helped accelerate service innovation and provisioning. With this, several providers banded together and created the European Telecommunications Standards Institute (ETSI). The creation of ETSI resulted in the foundation of NFV’s basic requirements and architecture. The original NFV white paper describes the problems that they are facing, along with their proposed solution:

"Network Operators’ networks are populated with a large and increasing variety of proprietary hardware appliances.

To launch a new network service often requires yet another variety, and finding the space and power to accommodate these boxes is becoming increasingly difficult, compounded by the increasing costs of energy, capital investment challenges, and the rarity of skills necessary to design, integrate, and operate increasingly complex hardware-based appliances. Moreover, hardware-based appliances rapidly reach end of life, requiring much of the procure-design-integrate-deploy cycle to be repeated with little or no revenue benefit.

Network Functions Virtualisation aims to address these problems by leveraging standard IT virtualization technology to consolidate many network equipment types onto industry-standard high-volume servers, switches, and storage, which could be located in data centers, network nodes, and in the end-user premises.

We believe Network Functions Virtualisation is applicable to any data plane packet processing and control plane function in fixed and mobile network infrastructures."

ETSI continues to address NFV innovation. The Linux Foundation offers another open source reference platform -- the Open Platform for NFV Project (OPNFV). OPNFV works closely with ETSI and others to press for consistent implementation of open standards.

SDN versus NFV

Now, let’s turn to the relationship between you, SDN, and NFV. The original NFV white paper gives an overview of the relationship between SDN and NFV:

Network Functions Virtualization is highly complementary to Software-Defined Networking (SDN) but not dependent on it (or vice-versa). Network Functions Virtualization can be implemented without an SDN being required, although the two concepts and solutions can be combined, and potentially greater value can be accrued.

Network Functions Virtualization goals can be achieved using non-SDN mechanisms, relying on the techniques currently in use in many data centers. But approaches relying on the separation of the control and data forwarding planes, as proposed by SDN, can enhance performance, simplify compatibility with existing deployments, and facilitate operation and maintenance procedures. Network Functions Virtualization is able to support SDN by providing the infrastructure upon which the SDN software can be run. Furthermore, Network Functions Virtualization aligns closely with the SDN objectives to use commodity servers and switches.