I promised some of my blog readers that I’d do a deeper dive into the current state of NFV implementations. One of the challenges that poses is defining just what an NFV implementation is, because NFV means different things to different people and because there’s an ungodly amount of NFV hype out there. Another challenge is getting information on offerings, and when you combine these two things there aren’t many that pass the filters.
Network functions virtualization defines the way services can be created by taking software implementations of “network functions” and “virtualizing” them so that they can be orchestrated (deployed and interconnected) on various hardware platforms and managed in some efficient and cohesive way. Just from this simple statement you can see that there are two primary pieces—the functions themselves and the management and orchestration framework that runs them. Most NFV announcements to date have been announcements of network functions, but an “NFV implementation” has to do the management and orchestration stuff—what the NFV ISG calls “MANO”. These implementations are the ones I’ll talk about here, and to be fair I’ll go through the small list in alphabetical order. If you are one of the vendors listed here, or if you purport to have a complete NFV implementation including MANO and can provide public document references for it, we’ll take a briefing on your solution and report on it in detail.
Don’t expect a nice clean column chart here. Even MANO is a bit fuzzy. First, it includes both the processes needed to deploy and interconnect functional components and the processes needed to manage them. Second, the specifications aren’t final at this point, so just what ETSI might call for here is still a bit up in the air. Third, and perhaps most important, the mission of NFV as it’s perceived by the operators themselves has evolved from one of simple capex reduction to one of enhancements in service agility and reductions in operations costs. These points have been true, and largely visible, almost from the first and so “NFV implementations” could be expected to have some variability of features depending on how they deal with each of them.
I’ll start with Alcatel-Lucent CloudBand. CloudBand is a cloud computing architecture that has been enhanced to support NFV. One diagram Alcatel-Lucent showed at one point told the story nicely by showing CloudBand as a block, with a right-side component for cloud services and a left-side component for NFV. The left-side component was based on what Alcatel-Lucent calls “Carrier Platform as a Service”, a set of APIs that provide virtual functions with access to orchestration and management services.
CloudBand uses cloud software (OpenStack or CloudStack) to deploy both cloud components and virtual functions and there appears to be at least a level of dualism possible between them; in theory you should be able to author “cloud applications” that would use CPAS and thus look like virtual functions. In theory you could also deploy VNFs as cloud components bypassing CPAS, which would appear to open CloudBand to a wider range of VNF resources but at the expense of some management and orchestration integration.
Deployment and orchestration at the high level is the responsible of the CloudBand Management System, which provides for deployment using DevOps-like “recipes”. These tools can be accessed through a console or via the CPAS API set, so management can be deployed as a part of the VNF service/application or in a more centralized way. There are no details on the nature of management integration but operators report it to be handled fairly traditionally, consistent generally with the ETSI NFV specifications as they’re evolving.
CloudBand gets a lot of points for credibility from the operators, and also from me, but I’m still not confident in their management approach. One concern is that for NFV to work, VNFs have to be off-the-shelf and not part of any vendor ecosystem, meaning they can’t use custom APIs. Another is that I don’t agree with the ISG notion of VNF management, which is what Alcatel-Lucent seems to be following. I think there are issues with performance, security and integration that CloudBand management still needs to answer.
Cisco, not surprisingly, has a different slant but one that in some ways is harmonious with that of Alcatel-Lucent. Both companies have what is effectively a PaaS API set that defines their MANO capabilities and provides for integration of service components. Both have a developer program that’s based on this ecosystem. Where Cisco has a different slant is in the basic framework. Alcatel-Lucent’s CloudBand is a cloud architecture adapted to NFV. Cisco’s Evolved Services Platform is essentially a Cisco-proprietary service-layer hosting framework for “service modules” that can envelop an arbitrary set of logical elements. You deploy service modules, and that deployment uses whatever tools are necessary. The modules are a form of a packaged service, with management and orchestration elements built in. This structure means that Cisco can envelop its current offerings into its ESP/NFV approach without changes. Since ESP consumes the Evolved Services Network (ESN) which envelops both Cisco’s SDN APIs and legacy APIs, ESP is also compatible with current and evolving networks.
How this fits with NFV is a matter of some interpretation. It’s our view that Cisco will provide tools that will build service modules from virtual functions and will use sanctioned NFVI to deploy on. It would appear that Cisco’s approach would allow service modules to deploy on NFVI even if the modules were based on something other than ISG-sanctioned VNFs or used non-standard orchestration. It would also appear that there is a basic set of orchestration tools that can deploy services based on multiple service modules. Cisco could likely resolve the management integration issues with their service-module approach, but it might take custom code from someone, so that issue is still a question for me.
A more problematic provider of NFV is Dell, who has recently said it would be offering NFV solutions and is also a sponsor of the CloudNFV project and a PoC (with Red Hat) that’s based purely on OpenStack. The “problem” part here is that while I obviously believe that CloudNFV is a complete and responsive NFV approach (I architected the concept and served as Chief Architect through late January), Dell does not appear to have productized it yet nor have we found a commitment to productize it at all. There are, as of today, no mentions of CloudNFV found using Dell’s search function on its website. There is one press release that indicates that Dell has taken over leadership of the project, but no specific product commitment. Thus, it’s not clear whether Dell’s commitment to leadership translates into actually offering CloudNFV as a product, and I can’t rate their capabilities without some specific product documentation. You can refer to the CloudNFV website for information on how it works, and the architecture described is open and available without restriction as the site says, but I still can’t name a commercial source for it and so can’t rate it as an implementation. Dell is showing signs of wanting to be simply an infrastructure (NFVI) player rather than someone who offers a complete solution. Am I wrong? Then set up a briefing, Dell, and tell me what’s up.
The next NFV player on our list is HP, with its OpenNFV architecture. HP has extensive material on OpenNFV available on its website, and that material suggests that it has the two-level model of functional/structural orchestration that I think is the right answer. Obviously, HP’s approach is based on OpenStack, and HP provides an HP NFV Director for orchestration and management integration. The whole story is spelled out in what HP calls its “OpenNFV Reference Architecture (NFV RA), and the architecture includes all of the pieces needed for a credible NFV story, including OSS/BSS integration. I have some reservations about the dependency of the HP management approach on the ETSI model of “VNF Managers” but HP enhances it by providing some default VNF management tools inside the Director to augment or replace embedded VNF Managers where they aren’t found or are incomplete. This is better than “naked ISG-style management” but in my view it’s not good enough. Still, if you roll all of the RA into a product you have the most complete picture of NFV implementation presented by any vendor.
The problem is that the RA is an RA not a product, at least as far as operators have reported to us. HP doesn’t have all the pieces yet and at least some operators are indicating that HP is looking to ecosystem partners for some of the pieces so they won’t be doing everything themselves. I’m told that HP will undertake professional services contracts to deploy the RA, but the word is that this won’t be fully available much before year-end.
Oracle also has a potential issue with NFV “productiziation”. They’ve made at least some presentations on their NFV approach, and I’ve listened to them and find a lot of merit in what they’re proposing. The problem is that at the moment they don’t have an “NFV product” per se. Their NFV story is made up of an alignment between ETSI E2E diagrams and Oracle elements, but it’s not clear whether all these elements are available in suitable form, and it’s not clear what the specific mission and features of each are. There are things in their repertoire that are clearly suitable VNFs, and there are things that are definitely candidates for some element or another of MANO. What I can’t find after a review of their website is a solution brief on NFV or something that takes the block diagrams they show in their presentations and aligns them with specific Oracle product elements.
On the plus side, Oracle is talking explicitly about both the notion of multi-layer orchestration and that of data collection, abstraction, and distribution. That kind of discussion isn’t in the material I could find from Alcatel-Lucent, Cisco, or HP and both these points are critical to successful NFV in my view. You could spin a compliant management story off Oracle’s approach as it stands; the only question would be whether they implemented it. With the proper pieces implemented, Oracle could be a strong NFV contender. Operators tell me they believe they will be able to trial Oracle strategies late in 2014 or early in 2015, but I can’t confirm that yet.
So that’s the NFV situation as I see it now. You can see from this that NFV is still in the tire-kicking stage overall, and so I can’t really evaluate which of these strategies is best or even which is complete. Management is the big issue for NFV because it’s management that has to bridge current ISG work to current operator goals for operations efficiency and service agility. I think it’s going to be hard to say that any NFV approach is sound until the management issues are fully resolved. One driver for that might be the TMF NFV Catalyst activity that’s scheduled to result in demos in Nice in early June, and another could be a TMF draft on an evolved OSS/BSS model for the virtual age—I can’t speculate on when the latter might happen. Given that service agility and operations efficiency are the two primary operator goals for NFV as of our fall survey, and that operationalization is critical to meeting those goals, it’s also possible that somebody will step up with a solution—maybe even one of the vendors I’ve named here. I’ll report on things as they develop.