Shehzad MerchantAs the buzz around network function virtualization (NFV) continues to grow, particularly within the mobile service provider market, carriers are in trials to virtualize key functions within the evolved packet core (EPC), such as the serving gateway (SGW), PDN gateway (PGW), and mobility management entity (MME). By leveraging off-the-shelf x86 platforms for running these functions, they can de-couple the software trajectory from the hardware systems and achieve a degree of vendor independence. Well, at least in principle.
The challenge becomes scalability. While some functions are relatively low bandwidth and do not require high-capacity and high-processing capabilities, others do. And for those functions, the allure of the x86 platform is ease of scalability and elastic provisioning capacity. But this is where things start to get a little murky.
In many cases, scaling performance in a virtualized environment requires special handling of packets—for example, when performing hypervisor and virtual switch bypass with technologies like single root input/output virtualization (SR-IOV). Typically, organizations will use specialized Network Interface Cards (NICs) accompanied by hardware acceleration or NIC-level offloading to enhance performance. But to take advantage of these technologies for acceleration and improved performance, organizations need to work with those specific cards, which, in turn, brings a certain amount of lock-in both on the software and hardware side.
In other words, once carriers deploy technologies for acceleration, they can’t simply swap out a server for any other x86-based server. Rather, they are required to stick with the same vendor that provides the hardware acceleration and NIC cards and, perhaps, even seek buy-in from that vendor to ensure their software is easily portable to the newer generations of NIC cards with hardware-assist functions.
Next, and once every ounce of performance has been extracted using NIC offload, hypervisor/kernel bypass, and other techniques, it’s time to scale out performance through multiple servers. If the network functions being virtualized are stateless, it’s a relatively easy process. However, if it’s necessary to maintain state and load balance across a scaled-out NFV solution, the process becomes a bit more complex. In this latter case, organizations will need a load balancer that can understand the protocols associated with the network functions, correlate the traffic across the various interfaces (if needed), and then intelligently load balance across the scaled-out instances of the virtualized EPC functions.
It’s a process that reminds me of the early days of e-commerce and the commercial Internet, which also began with web servers running on x86. As traffic to websites and web applications grew, those web servers and applications needed to scale. That required traffic to be load-balanced across a scaled-out solution. For e-commerce traffic, that requires things like stateful load balancers to track sessions, and cookies, as well as sending the right traffic to the right instance of the web application or server. While this could initially be achieved with a software-based load balancer, and as traffic volumes grew, the process required a dedicated appliance that could perform a variety of tasks, including load balancing, health checks, and load re-distribution. In time, this led to dedicated load balancers with field programmable gate arrays (FPGAs) and hardware-assist functions and, ultimately, application delivery controllers.
Is the NFV world headed in that same direction? If so, who will build the load balancers for all the different virtualized network functions? If every vendor were to provide a solution with different virtualized network functions (VNFs) for load balancing in a scaled out environment, will there be vendor-specific load balancers for each virtualized EPC function?
Adding together the two scenarios (i.e., the use of specialized acceleration engines and NICs for performance improvements within the server plus the use of dedicated, stateful load-balancer appliances to distribute traffic across servers), begs the question: Could NFV be headed down a path of tighter vendor lock-in rather than vendor independence? In its current trajectory, it certainly seems so.
Originally published in SDX Central
