We keep hearing about SDN and NFV in various debates. Are they related? How would they compare to standard networking? How do they differ from one another? Let me put my thoughts in this post.

Software Defined Networking

SDN has started its journey using normal network devices like switches and routers. As people were trying to use different protocols on different devices they were irritated to keep changing the software on the devices [Switch / Router / Hub]. They thought of changing the behavior of the device in a programmatic manner controlled by a central component. This brought the concepts of SDN with these features:

  • Dividing the functions of the Control Plane and the Forwarding Plane

  • Have a centralized controller which will be acting as required

  • Programming the network behavior with well-defined interfaces

The next accomplishment for SDN was to implement it in data centers. As the size and need of these data centers have expanded, a good path was expected to associate and control the virtual machines. The standards of SDN soon indicated in enhancing how to control data centers.

Why is OpenFlow needed ?

So how does OpenFlow become part of the picture? As SDN started to gain importance it required standardization and its maintenance. The Open Networking Forum (ONF) was created to make the central controller talk to the network elements. So one approach of standardization for network elements is to use OpenFlow. OpenFlow defines the model on how to organize the traffic in flows and how to control the flows as required. It helped to understand and  gain the benefits of SDN. In addition to ONF, the OpenDaylight project also aims to gain the advantages of open standards and SDN adoption. This project’s goal is to give a functional SDN platform which will give the users a directly deployed SDN without requiring other components. Apart from that contributors and vendors can deliver add-ons that will add more value to OpenDaylight.

Network Functions Virtualization

While researchers and datacenter people created SDN, carrier providers created NFV. It was necessary for the service providers to deploy their new network services quickly and increase their revenue and growth plans. They realized that hardware-based appliances limited their ability to achieve this goal. They looked at the standard IT virtualization technologies and thought that NFV could help to speed up their service innovation and provisioning. With this thought many service providers banded together and created the European Telecommunications Standards Institute (ETSI).

ETSI created the foundation for NFV’s basic requirements and architecture. The original NFV white paper gives the solution for the problems that are faced by many network providers like AT&T, Deutsche Telekom etc. In brief the solution is as follows:

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.

NFV addresses these issues by using the standard IT virtualization method to harden the network devices into standard high volume servers, switches and storage required for Data Centres, Network Nodes and client premises. NFV is relevant for packet processing in Data Plane and the Control Plane functionality of system configuration, management, and exchange of routing table information. The Linux Foundation had set up another open source reference platform called as Open Platform for NFV Project (OPNFV). OPNFV will work closely with ETSI and others for a consistent implementation of open standards.

SDN vs NFV

SDNvsNFV

Both NFV and SDN are corresponding to and independent of each other. NFV is executable even without an SDN despite the fact that these two can be consolidated into a single implementation and can gain more prominence. We can accomplish the NFV objectives using non-SDN components on the server systems used as a part of datacentres. The methodologies needed on the partition of the control and data forwarding planes as proposed by SDN can increase the performance, be similar to the existing deployments, operation and support systems.

A combination of SDN and NFV as one solution can give the following features:

  • The Control Plane can be moved to a normal hardware device instead of implementing it on a dedicated costlier device.

  • The Data Plane is software standardized by taking into account the system and application upgrades needed on network devices.

  • So as a result the needed costly and committed device can be replaced with a generic device which is programmed to give advanced services.

 

NFV_SDN

Ref: https://goo.gl/NHvK4a

Comparison between SDN and NFV

SDN

NFV

Focus

Data Center

Service Providers

Strategy

Split Control and Data forwarding planes

Replace network devices with software

Protocol

OpenFlow

Undefined but supports OpenFlow

Applications

On standard servers or switches

On standard servers

Benefit

Drives down complexity

Increases agility

Drives down complexity

Increases agility

Initial Supporters

Software and Hardware vendors

Telecom Service providers

Initiator

Corporate IT

Service Provider

References:

https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf

https://portal.etsi.org/nfv/nfv_white_paper.pdf

http://wikibon.org/wiki/v/Network_Function_Virtualization_or_NFV_Explained