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? Are you new to SDN or NFV? Check out SDNCentral’s SDN and NFV Essentials to learn the basics.

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 the need to change the software in 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 lead to a formalization of the principle 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) [1] 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. [Editor’s Note (11/6/14): In addition to ONF, the OpenDaylight Project also aims to advance open standards and SDN adoption. Announced in April 2013 by the Linux Foundation, the OpenDaylight Project’s goal is to offer a functional SDN platform that gives users directly deployed 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. [Editor’s Note (11/6/14): Service providers attempted to speed up deployment of new network services in order to advance their revenue and growth plans, and they found that hardware-based appliances limited their ability to achieve these goals. They looked to 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 [2] 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 virtualisation technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which could be located in Datacentres, 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.

[Editor’s Note (11/6/14): ETSI continues to address NFV innovation. In September 2014, the Linux Foundation announced another open source reference platform — the Open Platform for NFV Project (OPNFV). OPNFV will work 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 [2] gives an overview of the relationship between SDN and NFV:

As shown in Figure 1, 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 a SDN being required, although the two concepts and solutions can be combined and potentially greater value accrued.

Figure 1. Network Functions Virtualisation Relationship with SDN

Network Functions Virtualisation goals can be achieved using non-SDN mechanisms, relying on the techniques currently in use in many datacentres. 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.

SDN and NFV – Working Together?

Let’s look at an example of how SDN and NFV could work together. First, Figure 2 shows how a managed router service is implemented today, using a router at the customer site.

Figure 2: Managed Router Service Today

NFV would be applied to this situation by virtualizing the router function, as shown in Figure 3. All that is left at the customer site is a Network Interface Device (NID) for providing a point of demarcation as well as for measuring performance.

Figure 3: Managed Router Service Using NFV

Finally, SDN is introduced to separate the control and data, as shown in Figure 4. Now, the data packets are forwarded by an optimized data plane, while the routing (control plane) function is running in a virtual machine running in a rack mount server.

Figure 4: Managed Router Service Using NFV and SDN

The combination of SDN and NFV shown in Figure 4 provides an optimum solution:

• An expensive and dedicated appliance is replaced by generic hardware and advanced software.
• The software control plane is moved from an expensive location (in dedicated platform) to an optimized location (server in a data center or POP).
• The control of the data plane has been abstracted and standardized, allowing for network and application evolution without the need for upgrades of network devices.
  

Summary

The table below provides a brief comparison of some of the key points: