This third installment of our NFV interview series features Eric Carmès, CEO of 6WIND. Be sure to check out the previous interviews in the series, with Margaret Chiosi of AT&T and Christos Kolias of Orange.
Can you provide a quick overview of 6WIND and where you fit in the NFV ecosystem?
Carmès: 6WIND is the only commercial software company focused on solving the critical data plane performance challenges associated with NFV, while most software companies active in the NFV space are working on management and orchestration problems.
We’re uniquely positioned to provide data-plane solutions for NFV because our 6WINDGate™ networking software is already widely used in physical networking equipment deployed in telecom infrastructure worldwide. Through high-performance packet processing, 6WINDGate enables service providers to maximize the number of subscribers supported per blade, in applications such as LTE Evolved Packet Core (EPC) equipment.
Over the past couple of years, we’ve extended our technology to incorporate solutions for networking performance bottlenecks associated with virtualization elements such as hypervisors and virtual switches, so that TEMs and service providers can now adopt our software, already proven in physical networking implementations, to maximize the performance of their virtual networking functions (VNFs) in NFV deployments.
6WINDGate fits in two places within the NFV ecosystem: First, it maximizes the switching performance of the virtual switch that provides high-bandwidth network traffic to the VNFs running in virtual machines (VMs), thereby increasing the aggregated bandwidth delivered to the VMs. Second, it accelerates the data plane performance of each VNF.
There’s certainly a lot of buzz around NFV these days. In your view, what tangible benefits does NFV provide for service providers?
Carmès: In terms of the business benefits of NFV, most of the discussion to date appears to be around saving money. Significant capex and opex savings are expected through the virtualization of functions that have traditionally been implemented as standalone, dedicated, fixed-function equipment.
There are essentially two categories of use case. In the first case, for example, a virtual CPE or Cloud RAN [radio access network], NFV enables the relocation of resources from distributed physical equipment into consolidated, virtualized resource pools, leading to cost reductions through improved resource utilization. In the second case, such as EPC [evolved packet core] equipment, virtualizing these functions brings improved flexibility and scalability.
From the perspective of the service providers, though, top-line P&L growth ultimately comes from making money, and specifically from increasing their average revenue per user (ARPU). Increasing ARPU means extracting more money from subscribers, both enterprises and also consumers. In fact a recent study by Infonetics, “SDNs, 40G/100G, and MPLS Control Plane Strategies: Global Service Provider Strategy, July 2013” indicated that 48 percent of carriers want SDN/NFV in order to “create network services not possible with existing technologies/protocols”.
NFV reduces the risks associated with introducing new services. Traditionally, a service provider had to deploy specific infrastructure without any guarantee that the new service would be successful, representing a significant ROI risk. With NFV, the service can be deployed for a limited number of users on generic infrastructure. If it’s successful, it can then be rolled out on a large scale. If not, the generic infrastructure can be reused for another service.
As the NFV network-level architecture details and deployment strategies firm up, so that the service providers have confidence about the new capabilities of the infrastructure, we’d expect to see a lot more discussions about interesting new services that will raise our monthly bills as subscribers and boost the service providers’ top line revenue.
And what do you see as the bottlenecks to making NFV feasible in the short term?
Carmès: At this point in the evolution of NFV, the ETSI ISG working groups and “expert groups,” and the CloudNFV initiative, are mainly focused on topics relating to network management and orchestration. This makes perfect sense given the extreme complexity of legacy telecom networks and the challenge of migrating these control-related systems to a new architecture.
Before too long, though, we expect attention to shift to a fundamental data-plane issue that must be addressed in order for any NFV implementation to be cost-effective.
Packet processing is a key function that dominates the processing workload for many telecom network subsystems, including critical Cloud RAN, customer premises equipment (CPE) and EPC functions. In the case of traditional physical equipment, standard operating system networking stacks provide poor performance for packet processing because of overheads and latencies within the kernel, so many equipment suppliers have adopted solutions such as our software, which solves that problem through a fast-path architecture.
Virtualized implementations present additional challenges for packet processing. Virtualizing hundreds of Cloud RAN, CPE or complex EPC functions on a single server requires high-performance network bandwidth to be distributed to the virtualized functions. Standard virtualized architectures that work well for computing applications are unable to deliver the required performance for these demanding network applications. Bottlenecks in the hypervisor, the virtual switch, and the VMs themselves can degrade overall networking performance by an order of magnitude compared to physical implementations. This is a potential showstopper in terms of the cost-effectiveness of NFV architectures, for which cost-per-subscriber will be a critical metric.
Fortunately, these problems can be solved, as we’ll summarize below.
Of those bottlenecks, which would you characterize as a significant bottleneck, and how would 6WIND address it?
Carmès: There are significant bottlenecks in data plane performance, illustrated in the diagram.
The first bottleneck is the software virtual switch (vSwitch) running on the COTS platform or server. This vSwitch must provide sustained, aggregated high-bandwidth network traffic to the VNFs. At the same time, the performance of secure VM-to-VM communications must be maximized. Both of these factors are necessary to ensure that NFV deployments are cost-effective when compared with traditional network infrastructure based on physical switches.
Unfortunately, standard virtual switches such as Open vSwitch (OVS) do not deliver adequate performance or scalability to address these needs.
The second bottleneck is the performance of the VNFs themselves. Service providers will need their VNFs to deliver cost-performance that is comparable to that achieved by equivalent physical implementations. Otherwise, there will be no ROI justification for a transition to NFV.
VNF performance, though, is constrained by two factors. One is the poor performance and limited scalability of standard operating-system networking stacks. The other is the limitation on bandwidth for communication outside the VM that is imposed by standard hypervisors.
The 6WINDGate networking software addresses these two bottlenecks.
First, 6WINDGate can accelerate the standard Open vSwitch (OVS) by a factor of 10x. This typically results in at least a 3x improvement in the number of VMs that can be instantiated per blade, with even greater improvements achieved when the VNFs require sustained high-bandwidth traffic.
6WINDGate also accelerates the secure tunneling protocols such as IPsec, GRE, NVGRE, VLAN and VxLAN which are required OVS features for supporting high-bandwidth, secure VM-to-VM traffic.
Second, 6WINDGate accelerates the performance of VNFs. Thanks to its fast-path data plane architecture, 6WINDGate typically delivers 10x the performance of a standard Linux networking stack with no changes required to the kernel. This performance scales linearly with the number of cores configured to run the fast path. 6WINDGate includes a comprehensive set of networking protocols — for example PPP (used in a virtual Broadband Access Server), firewall, and IKE (used in security gateways) and TCP termination (used in WAN Optimization appliances).
As a result of optimizations for virtualized environments, 6WINDGate delivers comparable performance to that achieved when running in a physical implementation. This enables service providers to obtain best-in-class cost-performance from their VNFs, such as firewalls and security gateways.
In both environments (physical or virtual), 6WINDGate runs within the hypervisor, under the control of an orchestration layer such as OpenStack.
One of the core principles of NFV is its openness and standards-based approach. Would going down a 6WIND path violate that principle?
Carmès: One of the key benefits of our solution is that it’s fully compatible with all the appropriate standards.
When 6WINDGate used to accelerate Open vSwitch (the first bottleneck described above), no changes are required to the OVS code itself. 6WINDGate intercepts packets that would normally be processed in the (slow) OVS data plane, processing them in the 6WINDGate data plane instead.
It’s worth mentioning that we demonstrated our acceleration of the standard, unmodified OVS at the Open Networking Summit (ONS) in April and will be showing similar demos at two upcoming conferences over the next few months: the Intel Developer Forum and SDN & OpenFlow World Congress.
In the case of VNF acceleration (bottleneck No. 2), 6WINDGate is fully compatible with standard Linux networking APIs (Netfilter, Netlink etc.). This means that no modifications are required to the VNF applications themselves in order to take advantage of the performance improvement provided by 6WINDGate.
Besides this compatibility with the standard OVS and Linux APIs, 6WINDGate supports a wide range of industry-standard Linux distributions (e.g. Red Hat) and hypervisors (ESX, KVM and Xen).
Finally, 6WINDGate is fully compatible with the OpenFlow protocol. Our OVS demo at ONS was controlled by the industry-standard Floodlight controller from Big Switch Networks.
What’s your view on all NFV on the cloud on Day One? Is that realistic? If not, what’s a realistic path?
Carmès: We posed this question as an audience poll during a webinar that we presented jointly with Red Hat, “The first open software platform for network functions virtualization” on June 25. [You can watch the archived version here].
When we asked, “What will be the initial configuration of NFV deployments?”, 54 out of 76 respondents (that’s 71 percent) predicted that VNFs would initially be instantiated either on COTS hardware or in data centers.
Only 17 respondents (22 percent) expected initial VNF deployments to be on proprietary hardware, reflecting a clear trend away from proprietary implementations and towards standardized platforms. This trend is enabled by high-performance merchant multicore processors, 40G technology, and commercial software solutions.
The combination of COTS hardware and virtualization provides the flexibility required for NVF deployments. And, as we’ve discussed here, high-performance software such as 6WINDGate facilitates the transition away from proprietary platforms.
For example, implementing a CPE on generic, non-virtualized hardware accelerates the transition of the CPE function into the infrastructure where it can then be instantiated as a VNF running on the same generic processor architecture (though likely with a more powerful processor). Similarly, if a core network function is already available running on generic hardware, then the risk of implementing a virtualized version (a VNF) is significantly reduced.
Of course, the performance bottlenecks that we’ve discussed above must be addressed in order for this migration to be viable. As explained, that’s where 6WIND fits.
We expect that service providers will start by implementing VNFs on dedicated COTS platforms to realize immediate capex and opex benefits through better workload consolidation and improved resource utilization. Then, once the necessary management and orchestration solutions are in place, they can carefully and gradually take the next step represented by full data center deployments.
What should service providers being doing today to get themselves ready for the NFV wave? How does 6WIND help?
Carmès: Besides participating in the ETSI ISG initiatives aimed at defining NFV architectures and requirements, we think it’s important for service providers to “get their feet wet” via suitable proof-of-concepts (PoCs). Many of the questions relating to network performance, reliability, manageability and resiliency will only be addressed through real-world testing and analysis. We’re interested to see the results of the CloudNFV work to develop actual prototype implementations.
Of course, the value chains and go-to-market strategies will change for both telecom equipment providers (TEMs) and service providers. TEMs have the opportunity to transition from a hardware-dominated business to a software-dominated business, likely complemented by system integration capabilities (more on this later). Service providers will become technology integrators in addition to purchasers of fixed-function equipment.
From the 6WIND perspective, we’re well positioned to help TEMs and service providers with their initial trials. Our baseline packet processing technology has been proven through adoption by multiple tier-1 TEMs for traditional physical equipment. Given all the LTE networks in which our software is now deployed, it you have an LTE device then there’s a better than 50 percent chance that your traffic is being processed by our software.
Early on, we identified and solved the hypervisor- and vSwitch-related problems that constrain networking performance in virtualized environments. We’ve demonstrated that our software can help to address the complex data plane performance and scalability challenges that must be met in order for virtualized networking solutions to be cost-competitive with physical equipment.
What should networking functions vendors be doing today to prevent themselves from being rendered obsolete by the NFV wave? How can 6WIND help?
Carmès: NFV presents a couple of compelling opportunities for suppliers. The first, and probably most obvious, is to help service providers achieve their objectives in deploying NFV.
As we mentioned earlier, sustained business growth requires more than just capex and opex reductions: it requires the delivery of new services that being value to both enterprises and consumers, which raise APRU and contribute to top-line growth. So if we were a networking function vendor, we would be asking ourselves, “How can I be first to market with new solutions that will help my service provider customers gain market share through profitable growth?” And it would be a very cloud-focused conversation, because we firmly believe that the winning solutions and services not only will be cloud-hosted but will leverage the cloud to deliver capabilities and experiences that can’t be achieved otherwise.
Second, we believe that suppliers of networking functions will see new opportunities in system integration. Traditionally, service providers have been very comfortable with a business model whereby they acquire fixed-function networking equipment from their vendors. In the world of NFV, however, and especially NFV deployed in the cloud, service providers become licensees of software components that require integration, management and debugging, all in a virtual environment. This should create interesting opportunities for those networking function suppliers who can provide a wide range of services, starting with system integration but extending deep into the operation, maintenance, and optimization of complex networks where all the resources are virtualized. This sounds like an interesting business opportunity for companies with the right blend of technology and skills.
In terms of how 6WIND can help, we have solutions that solve the key problems of performance, scalability and reliability both for the virtual switch and the VNFs. By adopting our software as their standard data plane platform, suppliers of networking functions can accelerate their time-to-market (one of our customers told us that they saved 100 man-years of development time through using 6WINDGate) and focus their own engineering resources on their unique value-add. Our engineers have a deep understanding of how to solve the data plane challenges in virtualized networking systems, so we can bring that expertise to networking function suppliers as core technology and enable them to innovate in their own areas of differentiation.