NFV or SDN the Difference
Software-Defined Networking (SDN), Network Functions Virtualization (NFV) and Network Virtualization (NV) are giving us new ways to design, build and operate networks. Over the past two decades, we have seen tons of innovation in the devices we use to access the network, the applications and services we depend on to run our lives, and the computing and storage solutions we rely on to hold all that “big data” for us, however, the underlying network that connects all of these things has remained virtually unchanged. The reality is the demands of the exploding number of people and devices using the network are stretching its limits. It’s time for a change.
The Time for Changes in Networking is Now
Thanks to the advances in today’s off-the-shelf hardware, developer tools and standards, a seismic technology shift in networking to software can finally take place. It’s this shift that underlies all SDN, NFV and NV technologies –software can finally be decoupled from the hardware, so that it’s no longer constrained by the box that delivers it. This is the key to building networks that can:
- Reduce CapEx: allowing network functions to run on off-the-shelf hardware.
- Reduce OpEX: supporting automation and algorithm control through increased programmability of network elements to make it simple to design, deploy, manage and scale networks.
- Deliver Agility and Flexibility: helping organizations rapidly deploy new applications, services and infrastructure to quickly meet their changing requirements.
- Enable Innovation: enabling organizations to create new types of applications, services and business models.
SDN(Software Defined Networking)
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.
NFV – Created by Service Providers
Whereas SDN was created by researchers and data center architects, NFV was created by a consortium of service providers. The original NFV white paper <http://www.tid.es/es/Documents/NFV_White_PaperV2.pdf > 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.
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:
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 Virtualization 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 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.
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?
NFV demands virtual network overlays
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.
SDN and NFV will meet to advance centralized control
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.
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.
SDN and NFV – Working Together?
Let’s look at an example of how SDN and NFV could work together. First, how a managed router service is implemented today, using a router at the customer site.
NFV would be applied to this situation by virtualizing the router function, 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.
Finally, SDN is introduced to separate the control and data,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.
Summary
The table below provides a brief comparison of some of the key points of SDN and NFV.
Category
|
SDN
|
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
|
http://searchsdn.techtarget.com/essentialguide/SDN-use-cases-emerge-across-the-LAN-WAN-and-data-center
