By Mike Hicks, Senior Product Manager for Network Performance Monitoring
September 24, 2015 – I was recently having a discussion with one of my clients about the concept of network virtualization. During the conversation, in attempting to explain the business case, I referred to data center virtualization. This was met with some confusion, with the customer explaining that when he heard that term, his immediate thought was of server and desktop virtualization; that had already been done, hadn’t it? So this is a fair call, and I asked him: “What would be a better umbrella term for the network virtualization business cases?” He suggested that, for him at least, it made more sense to use the term software defined data center (SDDC). The reasoning was that the virtualizing of the network was more than just virtualizing the network within a private cloud environment. This made sense as the whole concept of SDDC goes way beyond simple virtualization, offering both more control and ultimately flexibility to delivering an organization’s applications.
Before diving into the SDDC architecture, let’s define exactly what we’re talking about when we use the term. I’m sure there are many people who were using the term earlier, but it began to elevate into the general consciousness at VMware’s annual conference (VMworld) in 2012, where it was (of course) touted as “the next big thing”. In very simple terms, a SDDC can be defined as a data center in which all elements of the infrastructure, including networking, compute, and storage, although technically you could probably also throw security into the mix, are virtualized and delivered as a service. In addition the SDDC, while separated in terms of configuration from the underlying infrastructure to enable automated provisioning, deployment and configuration, is ultimately dependent on that infrastructure, both physical and virtual. Consider the SDDC as sharing a common pool of resources with the ultimate goal of agile service delivery.
The Network part of the SDDC
So that’s the whole data center. For now I want to abstract just the network element from that. Network Virtualization represents arguably the most difficult of all areas contributing to SDDC solutions. The virtualization of network resources combines the available network resources (services, bandwidth, LAN, WAN, VLANs, security, etc.) into a resource pool that provides subsets of the whole to virtual machines, just as the physical networks provide these resources to physical servers.
This is where we’re plunged into even more acronyms. It’s well known that we love three-letter acronyms, and the virtualization of the network has provided us with yet another opportunity. The two main ones thrown around in this space are software defined networking (SDN) and network function virtualization (NFV).
Let’s dispel the first myth; these are not interchangeable terms, and while they can be quite complementary in terms of network virtualization, they carry different connotations. SDN in its simplest form is something of an umbrella term encompassing several types of network technologies, with the prime purpose of separating the control plane (intelligence, configuration etc.) and data plane (actual data, packets etc.). In a classic SDN environment a centralized controller will make decisions on which path packets should take through the network. It does this via a southbound API used to relay this information to the switches and routers, defining how the data plane should forward the packets. One way to do this in a SDN environment is via OpenFlow. This leads us onto a second point of confusion; SDN is not OpenFlow. OpenFlow is an open standard protocol that the control plane can use to manage traffic flow in the data plane.
NFV works in a similar manner in as much as it is an approach to design, deploy and mange network services. It also decouples functions, but in this case it decouples network functions from hardware. It also uses a controller to configure and deploy the network virtualization (NV).
In the case of NFV, NV is an overlay technology; that is to say it utilizes tunnels to connect domains in a network. In the strictest terms, NV is the creation, enablement and deployment of tunnels to interconnect domains. The actual NFV part is then the creation and deployment of specific network services, such as load balancers and firewalls, that will use those overlay tunnels to interact with the hosts and applications.
Many different technologies can be used to build an NFV data center. NFV OpenStack is one of a handful of popular open source technologies that are used to build a virtualized architecture.
NFV was initially conceived by the telecommunications industry, and was essentially defined by service providers as a framework to assist in expediting deploying, managing and controlling network services. However, many of today’s enterprise networks are not that dissimilar from a service provider’s environment. As more enterprises move more of their workloads to the cloud, the virtualized services of NFV can be used to integrate and support the network service needs of those cloud architectures. This is why we are starting to see enterprises adopt NFV solutions, particularly those looking to reduce costs by consolidating functionality on common, industry-standard platforms and quickly roll out services to their users.
OK, this all sounds good. But the network and associated protocols have been around for a long while and have done a good job in terms of delivering applications to the end user, so is this really all necessary?
Historically, the best networks are built with custom silicon (ASICs) and purpose-built hardware. Because it takes a significant investment to build custom silicon and hardware, such solutions tend to be proprietary, requiring individual and custom configuration. This means adding new features ad hoc is virtually impossible, and that is exactly what is required for today’s agile networks.
Summary
So in summary NFV is complementary to SDN, but each have slightly different goals and rely on different methods to achieve them. SDN separates the control and forwarding planes to offer a centralized view of the network, while NFV primarily focuses on optimizing the network services themselves. While potentially viewed as conflicting, having SDN technology enables the flexible routing of traffic within an NFV infrastructure to improve the efficiency and maximize the overall agility of the network.
That is obviously a very high level overview of SDN and NFV, and how and what you seek to deploy is going to be dependent on not only your requirements, but also your current investments and roadmap going forward; that is really a subject for another blog. But the key I point wanted to make is that whatever option you choose to take (or have already taken) there will be an element of network virtualization that will become a standard part of your network deployment.
That itself is nothing major; after all network virtualization in itself is nothing new and has been practiced in one form or another for a number of years predating SDN and NFV. The difference in today’s environments is the requirement to retain visibility into this “new” metadata; in part 2 of this blog, I’ll cover some of the visibility challenges and approaches you might want to consider.
