HP’s Saar Gillai explores the differences and relationship between NFV and SDN
Networking is about getting data from point A to point B. Networks are like road systems, where cars are driven around (data forwarding) and use turning directions (network control) to move from the origin to the destination. Navigation systems help drivers by providing turning directions at each road junction.
In traditional networking, those “turning directions” are tightly coupled with data forwarding (the underlying hardware that is moving data through the network device) and offered as integrated systems – switches, routers, etc. This coupling means network operators may not have as much say about how data gets shuffled through the network as they might like.
To illustrate: suppose you have a car with a built-in navigation system but you prefer to use Google Maps, Waze, or some other navigation software. What you’ve done is separate data forwarding (you driving your car) from network control (turning directions from the navigation tool). This gives you the flexibility to use any navigation tool you like without having to buy a new car to get it.
Separating network control and data forwarding is the central idea of software-defined networking (SDN). Just as with the car navigation system, a network that uses SDN gives you more flexibility, letting you break free from any inherent limitations with vertically-integrated products and have more control over the forwarding activities in your network.
While SDN provides a new approach for networking as a whole, Network Functions Virtualization (NFV) relates specifically to telco/carrier networks. These types of networks are unique because they must provide a very wide range of ‘functions’ (in addition to doing the basics of getting data from point A to point B) and deliver unquestioned reliability and performance.
Historically, telcos have built these networks using purpose-built, integrated systems. These systems are designed with highly-specialized hardware and system-specific software, packaged to provide a particular network function. Every time a new function is needed another system has to be deployed, each having its own unique power, space, and management requirements. As Don Clarke points out, this presents huge barriers to innovation.
Back to our road system analogy: let’s say you not only want a navigation system, but also roadside assistance, to be able to find the nearest Starbucks, listen to internet radio, check your email, and keep up on the latest news. These days a single smartphone and a pile of apps can do everything you want to do. If, instead, you had to buy a separate device to do each of those things you’d be following in the footsteps of how service providers have had to build their networks up until now – one integrated platform at a time.
In essence, NFV does for service providers what smartphones and applications have done for us as individuals. It lets them pick and choose the network function software packages they want (apps) and host multiple packages on a consolidated set of hardware platforms (smartphone).
At its core, NFV separates network functions software from the hardware platforms used to host them. This means the decisions regarding which network functions are needed can be made without getting stuck with pre-packaged hardware. This gives telcos more options on how to build their networks. This approach offers another benefit; instead of having to rely on expensive specialized hardware, telcos can use ordinary, much more cost-effective, industry-standard hardware (e.g. processor-based servers). In the process, telcos can standardize hardware across the network to simplify maintenance and reduce management overhead. Going one more step, this means that telcos can use server virtualization software to let them host multiple network function software instances on a single hardware platform.
But how would a telco be able to make sure a network base on ordinary hardware platforms is still reliable and performs as expected? In the old model, telcos met stringent service level agreements (SLAs) by leaning on the inherent reliability of the purpose-built hardware used in traditional integrated systems. Instead, NFV relies on a cloud approach; meet SLAs by ensuring the reliability of the overall hardware/software environment. Modern large-scale cloud deployments, typically built using ordinary hardware platforms, don’t depend on the reliability of any single system to stay up-and-running. Instead, they are built to make sure applications can keep running if/when any individual platform fails. In our road system analogy it would be like having a car with a bunch of small, cheap engines working together instead of a single highly-reliable one.
So, how does NFV relate to SDN? Short answer: They can be used together, but as Dan Pitt notes, they produce different results.
An NFV-based deployment can be built using traditional networking gear (that integrates network control and data forwarding in a single system)…and use SDN when and where it makes sense. For a telco deploying NFV, SDN is a tool –a way to more tightly align networking control and forwarding with the NFV deployment where it will enhance how services are delivered and managed. This means that service providers have many more options than they did before. Using NFV (with or without SDN) allows carriers to drive down costs, take advantage of open market competition, and increase flexibility, agility, and innovation...all the things they need to do to succeed.
- Saar Gillai, Senior Vice President & General Manager, NFV and Global Leader Telecommunications Business, Hewlett-Packard
