NFV: What You Should Consider in Your ADCs
Jim Frey is Vice President of Research, Network Management for Enterprise Management Associates (EMA) and is a featured guest blogger.
Network functions virtualization (NFV) is one of the best-accepted and most-understood spinoffs of the SDN craze that has taken root over the past few years. The concept is straightforward: take features and capabilities that are typically implemented in the network and repackage them in forms that can be invoked automatically, without requiring the deployment of new hardware. Since the “deploy once, reuse many” formula is one that is well understood by service providers, NFV is getting its strongest attention from that community. But the same capabilities are also relevant to enterprises – particularly those seeking to implement network-based optimizations and controls in mixed hybrid cloud environments.
A common focus for NFV has been application delivery controller (ADC) capabilities. This is in part because ADCs represent clear added value for improving application responsiveness and performance but also because ADCs have become essential added infrastructure for ensuring scalability and high availability of application servers and services. ADCs have also been extended to provide Layer 7 functions, such as content-based switching and content modification. The NFV approach clearly offers a chance to avoid the complexity of physical network element deployment, but which of functional capabilities are most important when considering an ADC implementation using an NFV approach?
Before considering that question fully, it’s worth mentioning a bit more about NFV and how it works. There are three important elements to NFV as outlined by ETSI, the telecoms industry standards organization. First, there are the virtualized network functions (VNF) themselves: in this case, the ADC feature capabilities that are implemented via software. Then there is the NFV infrastructure (NFVI), which is all of the hardware and software needed to host and execute VNFs. And finally, there is the management and orchestration (MANO) layer, which is used to connect the NFVI to the rest of the world so that VNFs can be invoked. The following list considers these three aspects of NFV solutions in the context of ADCs:
VNF: Not surprisingly, the more features the better when it comes to VNF. Ideally, all of the features that are available within a non-virtualized ADC should also be available within the NFV version. While this may seem obvious, some vendors struggle to deliver due to historical product architectures, hardware-specific feature implementations, or challenges in assuring adequate performance without purpose-build hardware.
NFVI: From an infrastructure perspective, the two most important ADC considerations are scalability (the more scalable the better) and hardware independence. It may still make sense to use a vendor’s ADC hardware to host/execute VNFs, but increasingly the demand is for accessing those features on whatever hardware is available, and generally that means multipurpose physical or virtual compute systems.
MANO layer: This layer is where the essential integration “glue” was historically applied, before the concept of NFV and standardization. What ADC solutions need is a well-formed and stable API that can connect directly to service provisioning and assurance systems. Support for OpenStack is a big plus, but other orchestration and cloud automation architectures should also be supported. Connection points with SDN controllers can also be very helpful as network paths and addresses are an important part of provisioning and operations.
Radware’s solution provides a useful example of what to look for in an NFV-based ADC. The Alteon VA for NFV offering provides full VNF parity with traditional hardware-based Alteon ADC products, in large part because the entire solution was shifted to Radware’s VADI virtualized architecture starting in late 2010. Radware has also provides specific advanced carrier features to its NFV solution, including transparent traffic steering and streamlined mobile delivery. From the NFVI perspective, the solution can run on existing Radware platforms but has also been certified to run on leading industry x86 platforms, such as Cisco UCS, Dell, and HP, while offering carrier-grade modular scalability up to 1 Tbps total throughput. Finally, from a MANO perspective, the solution offers RESTful APIs and the open, published vDirect interface, as well as certified drivers for OpenStack.
ADCs may be one of the best use cases for NFV, but all solutions are not created (or designed) equal. Make sure that any solution you choose has solid answers across all three dimensions of NFV, as well as a proven track record of viability and success.
