The Answer To Disaggregation: Network Functions Virtualization
When disconnecting hardware from software, the first thing a network engineer thinks about is routers and switches—because these are the basic building blocks of the network itself. However, there is another, more interesting, place to start when considering disaggregation in network engineering. If you traced the path of any packet from one edge of the network to another, you would find that it passes through a series of appliances that perform operations beyond just forwarding packets, as shown in the illustration below.
What sorts of operations? A few examples might be in order, such as:
- Classification for Quality of Service at Router B
- Network Address Translation (NAT) at Firewall C
- Stateful Packet Inspection and Filtering at Firewall C
- Checking for viruses or other malicious content at Firewall C
- Determining which server among a set of servers should handle the request at Load Bal D
Some of these rely on examining only the outer header and potentially some stored state, while others involve deep packet inspection, or rather examining what is normally considered data being carried within the packet. The appliances are considered a part of the network because their operations are (generally) transparent to the two devices communicating through the network. In the network illustrated above, Host A and whichever server Host A is communicating with—say Server F—have no idea that the routers, firewalls, and load balancers are in the middle of their conversation. Because these appliances are in the middle of the conversation, in fact they’re often called middle boxes.
One of the primary complaints about these middle boxes is that they are, in fact, appliances—which means they are physical hardware which must be purchased, rack mounted, powered, configured, upgraded, and generally maintained over time. When the manufacturer decides a particular model of appliance is no longer supportable, these middle boxes must be physically removed from the network, and replaced with a newer model.
What if, instead of purchasing custom designed and built appliances, the firewall service could be moved onto some form of standard server software, and hence managed like any other server? This is precisely what Network Function Virtualization (NFV) aims to do. Another way of putting this is that NFV disaggregates the appliance hardware from the appliance software (to return to a theme from my last post here).
Just replacing the appliances in the network above with standard hardware might not seem all that exciting, but NFV has generated a lot of excitement. Why?
First, using standard hardware unties the lifecycle of the hardware from the lifecycle of the software.
Second, Standard “off the shelf” servers are a lot less expensive than hardware purpose built for use in an appliance.
These two factors alone can make a virtualized network function a lot less expensive to deploy and maintain. But there’s a third factor at work here that makes the potential for NFV even more interesting. Once these appliances have been moved into software, they can also be configured to run on shared hardware that can be used for a lot of different functions. For instance, the load balancer and firewall in the network above can actually be run on a single set of hardware resources. This turns network appliances into virtual machines that can be scaled by adding more parallel processes, rather than only by adding a larger appliance.
But NFV idea can be taken one step farther. You might note its Network Function Virtualization, not Network Appliance Virtualization. There is a subtle, but important, difference between the two concepts. A firewall, for instance, normally serves multiple purposes—in the network above three were noted. The firewall translates IP address (NAT), performs stateful filtering, and examines the contents of each packet for malicious content. Each of these are actually services, or functions, running on a single appliance.
What if these three services could run independently? Now the network operator can not only scale the appliance, they can scale each service independently. While most NFV applications are not at this point, there is a definite trend in this direction.
NFV, then, provides a way to more smoothly and economically scale the services a provider offers to its customers. Further, with NFV the network operator can provision new services without installing a new appliance, or even changing cabling. NFV makes it possible to unbundle services by disaggregating the software service from the appliance hardware—opening a myriad of new opportunities for services and efficiency.
There’s one final thing NFV allows a network operator to do: move the services into a large scale data center environment, where they can be efficiently deployed and managed. This requires that traffic be brought to the service, rather than bringing the service to the traffic—something to consider in the next post on this topic.