NFV and SDN: What’s the Difference?

NFV Network Functions Virtualization Overture Networks

Interested in learning more about network functions virtualization? Be sure to check out our pages on NFV MANO, ETSI ISG NFV, OPNFV, and virtual network function.

Interested in learning more about Network functions Virtualization (NFV)? Check out our NFV Topic page. It's filled with current NFV articles, white papers, videos and other resources curated by experts on SDNCentral.

Interested in learning more about Network functions Virtualization (NFV)? Check out our NFV Topic page. It’s filled with current NFV articles, white papers, videos and other resources curated by experts on SDNCentral.

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.

Network Functions Virtualisation Relationship with SDN

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.

Managed Router Service Today

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.

Managed Router Service Using NFV

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.

Managed Router Service Using NFV and SDN

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.


The table below provides a brief comparison of some of the key points of SDN and NFV.




Reason for Being Separation of control and data, centralization of control and programmability of network Relocation of network functions from dedicated appliances to generic servers
Target Location Campus, data center / cloud Service provider network
Target Devices Commodity servers and switches Commodity servers and switches
Initial Applications Cloud orchestration and networking Routers, firewalls, gateways, CDN, WAN accelerators, SLA assurance
New Protocols OpenFlow None yet
Formalization Open Networking Forum (ONF) ETSI NFV Working Group


[1]. Software-Defined Networking: The New Norm for Networks

[2]. Network Functions Virtualisation (NFV) – An Introduction, Benefits, Enablers, Challenges & Call for Action

[3]. Network Function Virtualization or NFV Explained

Contributed Article Disclaimer:

Statements and opinions expressed in articles, reviews and other materials herein are those of the authors; the editors and publishers.

While every care has been taken in the selection of this information and reasonable attempts are made to present up-to-date and accurate information, SDxCentral cannot guarantee that inaccuracies will not occur. SDxCentral will not be held responsible for any claim, loss, damage, or inconvenience caused as a result of any information within this site, or any information accessed through this site.

The content of any third-party website that you are linked to from the SDxCentral site is entirely out of the control of SDxCentral, and you proceed at your own risk. These links are provided purely for your convenience. They do not imply SDxCentral's endorsement or association. The copyright and any other intellectual property right, as well as any third-party content, belong to the author and/or other applicable third party.


  1. Philip Marquis says

    If you “Virtualize the Router function” in the network then does this mean that traffic on the customer WAN doubles since the NID is simply a demarc. Is this good for the Service Provider as they can then charge for more bandwidth to the customer. Also if the network interface then fails how does the customer do local routing or is he then left stranded ?

  2. Prayson Pate says

    Good question, Philip.

    There are two possible enhancements to the network diagrams that I showed:

    1) The customer may have their own simple router for intra-switching. This is the usual situation in an enterprise.

    2) The NID may have simple static routing and/or bridging for intra-switching.

    Either case removes the local traffic from the WAN and solves the network failure scenario.

    The virtual router would still handle the firewall and VPN functions for WAN traffic in both cases.


  3. Tanya Ruppell says

    I’m looking at your diagrams and I do not see any difference between Figure 2 (Managed Router Service Today) and Figure 4 (Managed Router Service Using NFV and SDN). What exactly are you trying to show?

    • Prayson Pate says


      Good catch!

      SDNCentral has been doing some maintenance and they somehow replaced the image for figure 2 with that for figure 4. I have asked them to repair the blog and use the correct figure 2.


  4. Prayson Pate says

    Here is short, simple and effective definition of SDN from the XOS project. See page 5 of

    The challenge is how to systematically transform such a diverse collection of devices into software running on commodity hardware. Our main insight is that there is a simple template for how each physical device is virtualized. It includes a combination of three elements: (1) merchant silicon, including both commodity servers and white-box switches; (2) a control plane function, which we refer to as the SDN element; and (3) a data plane function, which we refer to as the NFV element. While SDN and NFV are over-loaded terms, for our purposes, both are implemented by software running on commodity servers, where it is considered an NFV element if packet processing is entirely in software, and it is considered an SDN element if that software also controls a commodity switch through an open interface like OpenFlow. Said another way, NFV elements run oncommodity hardware, while SDN elements run on commodity hardware (servers) but also controlcommodity hardware (switches).

Leave a Reply