SDN vs NFV: what’s the difference?

Networking

by Amy-jo Crowley| 23 June 2014

Software defined networking and network function virtualisation both promise to make networking cheaper and less complex, but how?

There has been plenty of talk about software defined networking (SDN) and network function virtualisation (NFV) lately, especially as big vendors' architectures start to appear on the market.

And while both promise to reduce the cost, complexity and rigid nature of networking, there appears to be some confusion about the differences between these two.

How do they differ?

Coined back in 2005, the goal of SDN is to separate the control plane from the data forwarding plane of networking devices.

The control plane is the system that makes the decisions about where network traffic is sent, while the forwarding plane is the system that sends the traffic to the selected destination, according Shin Umeda, an analyst for NFV at Dell'Oro Group.

"The separated control plane provides a centralised view of the network and can be programmed to improve network efficiency, scalabiltiy and flexiblity when dealing with traffic flow and services," he explains.

The SDN controller is a piece of software similar to an operating system used to manage the software defined network. For example, network administrators could change data traffic rules on a case-by-case basis, allowing organisations to decrease their reliance on more expensive switches.

On the other hand, NFV originated from service providers who were looking to accelerate the deployment of network services after feeling the constraints of hardware-based appliances. The approach separates certain network functions from the specialised, dedicated networking devices or appliances that run these functions.

"The separated network functions become software-based applications that run on industry standard virtualisation technology - servers, switches, and storage - in a more efficient, scalable, and portable manner than is possible with appliances," explains Umeda.

How are they deployed?

Predominantly implemented in data centres, how you build and deploy SDN will vary according to each network and the use cases of that network. Some networks will use OpenFlow, while others may use Shortest Path Bridging (SPB), Trill or Open Shortest Path First (OSPF). Likewise, the SDN platform you deploy might use the OpenDaylight controller or a full stack approach, such as Juniper's Contrail or Nuage Network's VSP.

"Telecom networks tend to comprise equipment types that have a broad range of technology, age, physical distribution, and operational requirments. This breadth of equipment makes it difficult to transform telecom networks to an SDN architecture without a significant financial outlay in SDN compatible equipment," adds Umeda.

NFV is a higher priority for telecom operators because of the type of equipment and architectures of their network, which are designed to deliver a broad range of services.

"Many of the services have underlying technologies that are very robust, but inflexible. For example, voice, residential broadband, TV, business, and wireless services are based on very different sets of technology that are dispersed across hundreds or sometimes thousands of different locations," says Umeda.

Competition

Companies such as Cisco, Juniper Networks, HP, IBM all offer SDN controllers, while NFV's principal proponents include AT&T, BT, Deutsche Telekom, Orange and Verizon.

Both SDN and NFV can be implemented independently, meaning SDN does not require NFV, and NFV does not require SDN. However, they may offer even more efficiency and flexibility when the network (SDN) and the functions (NFV) are more tightly integrated and orchestrated, according to Umeda.

Comments
Post a comment

Comments may be moderated for spam, obscenities or defamation.
Privcy Policy

We have updated our privacy policy. In the latest update it explains what cookies are and how we use them on our site. To learn more about cookies and their benefits, please view our privacy policy. Please be aware that parts of this site will not function correctly if you disable cookies. By continuing to use this site, you consent to our use of cookies in accordance with our privacy policy unless you have disabled them.