Essential Guide

SDN basics for service providers

A comprehensive collection of articles, videos and more, hand-picked by our editors

Understanding the relationship between SDN and NFV

SDN and NFV are not part and parcel to each other, but when the two sets of technology meet they advance each other's capabilities.

FROM THE ESSENTIAL GUIDE:

SDN basics for service providers

+ Show More

It's difficult to get an industry with a long depreciation cycle for capital equipment to support any sort of revolution, but networking is facing two at once. Both software-defined networking (SDN) and network functions virtualization (NFV) propose revolutionary developments, and the success of either in changing the network may depend on the technologies being somewhat harmonious, if not actually supportive of each other. Just where...

the points of harmony lie may explain our roadmap to the network of the future.

SDN and NFV are not part and parcel

SDN evolved out of two fairly different industry problems. First, building and managing large IP/Ethernet networks was becoming increasingly complex given the adaptive nature of packet forwarding for both protocols. Traffic management and operations efficiencies could be improved, many said, by exercising central control over forwarding. Early examples of SDN by players like Google seem to bear this out.

Adoption of network overlays for virtual function segregation could make NFV the largest consumer of cloud networking and SDN services.

Second, the promise of cloud computing creates a new model for application deployment where tenants must share public cloud data centers in a non-interfering way, and multi-component applications must be deployed on flexible resource pools without losing control over performance and security. Given two different missions, it's not surprising that there are at least three models of SDN being promoted. One model is based on centralized control using OpenFlow controllers, another depends on using SDN to provision and manage network virtualization using network overlays, and the third is a distributed model in which a higher layer of software communicates with the network and its existing protocols.

Network functions virtualization is a carrier-driven initiative to virtualize network functions and migrate them from purpose-built devices to generic servers. The express goals of NFV are to reduce deployment costs for services by reducing the reliance on proprietary devices and to improve service flexibility by using a more agile software-based framework for building service features. From the first white paper proposing NFV, innovators visualized a pool of virtual functions, a pool of resources, and a composition/orchestration process that links the former to the latter. That paper suggests that NFV and SDN have some overlap, but SDN is not a subset of NFV, or the other way around. So where do SDN and NFV intersect? And how will the interaction between SDN and NFV impact the evolution of both ideas?

SDN and NFV will meet to advance centralized control … down the road

It seems clear that NFV could define the central control functions of SDN as virtual functions, so, for example, OpenFlow switches could be directed by NFV software. In theory, the SDN controller could be implemented as a virtual function, which would make it conform to both SDN and NFV.

Firewall and load-balancing applications are also targets of NFV since they have an SDN-like segregation of forwarding and control behaviors. Indeed, if NFV addresses the general case of policy-managed forwarding, it could define a superset of SDN.

NFV could also define central control and administration of networks that operate through other protocols, such as BGP and MPLS, and even define configuration and management of optical-layer transport. However, none of these appear to be near-term priorities for the body, and so this direct overlap of SDN and NFV doesn't seem likely in the next few years.

NFV demands virtual network overlays … and thus SDN

While it may take some time before we see NFV play a key role in SDN architecture and vice versa, the use of network overlays in NFV will drive an intersection of the technologies in the shorter term.

NFV is likely to at least accept, if not mandate, a model of cloud-hosted virtual functions. Each collection of virtual functions that make up a user service could be viewed as a tenant on NFV infrastructure, which would mean that the cloud issues of multi-tenancy would likely influence NFV to adopt a software-overlay network model. This is where SDN comes into play.

This model, made up of tunnels and vSwitches, would segregate virtual functions to prevent accidental or malicious interaction, and it would link easily to current cloud computing virtual network interfaces like OpenStack's Quantum. The virtual networks would be provisioned and managed using SDN.

Adoption of network overlays for virtual function segregation could make NFV the largest consumer of cloud networking and SDN services. This would mean that NFV could shape product features and accelerate product deployment in the SDN space. That alone could have an impact on every cloud computing data center and application, including private and hybrid clouds.

How NFV will push SDN beyond the data center

NFV's use of virtual network overlays could also drive an expansion of this SDN model beyond the data center where it's focused most often today. If NFV allows services to be composed of virtual functions hosted in different data centers, that would require virtual networks to stretch across data centers and become end-to-end. An end-to-end virtual network would be far more interesting to enterprises than one limited to the data center. Building application-specific networks that extend to the branch locations might usher in a new model for application access control, application performance management and even application security.

Will NFV unify differing SDN models?

With the use of network overlays, NFV could also unify the two models of SDN infrastructure -- centralized and distributed. If connectivity control and application component or user isolation are managed by the network overlay, then the physical-network mission of SDN can be more constrained to traffic management. If SDN manages aggregated routes more than individual application flows, it could be more scalable.

Remember that the most commonly referenced SDN applications today -- data center LANs and Google's SDN IP core network -- are more route-driven than flow-driven. Unification of the SDN model might also make it easier to sort out SDN implementations. The lower physical network SDN in this two-layer model might easily be created using revisions to existing protocols, which has already been proposed. While it doesn't offer the kind of application connectivity control some would like, that requirement would be met by the higher software virtual network layer or overlay.

Despite all the conversations, SDN and NFV are still works in progress, and both could miss their targets. But if NFV succeeds in reaching its goals, it will solidify and propel SDN forward as well and create a common network revolution at last.

About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecom and data communications since 1982. He is the publisher of Netwatcher, a journal addressing advanced telecom strategy issues.

This was first published in June 2013

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Essential Guide

SDN basics for service providers

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close