One of the most interesting players in the NFV game is HP. Not only do they have a strong position in IT, the cloud, and the data center, they also have a strong OSS/BSS position and they’re prominent in all of the standards groups involved in network evolution. That includes NFV, of course, but also SDN. In a prior blog I had noted that operators thought their OpenNFV architecture was the strongest or one of the strongest in the market, but that it was still not fully delivered. HP was surprised at the view, and I spent some quality phone time with the key HP people to understand their perspective, and how that might relate to or contrast with the views expressed by the operators in my survey early this year.
OpenNFV is a suite and an architecture. HP explains it (not surprisingly) by referencing the NFV ISG’s architecture, and this is actually a good place to start because OpenNFV is surprisingly inclusive. In particular, HP is committed to both open infrastructure (NFVI) and open third-party VNFs. The latter point is critical in my view, though as you’ll see I still have some concerns about the details.
The heart of HP’s OpenNFV is the NFV Director, which provides the central MANO functionality outlined in the ISG’s E2E architecture diagram. HP’s Director can also support either external management (including the NFV’s Virtual Infrastructure Manager or VIM) and an internal version, so it’s a bit broader than the pure orchestration model of the ISG. The NFV Director developed out of HP’s Service Activator (an element of HP’s OSS solution), which is now used to deploy MPLS and GigE services, so it has the ability to control legacy deployment out of the box. In one of the current PoCs, HP says that only 20% of the configuration is NFV and the rest is legacy.
The OSS roots of the NFV Director mean that HP’s approach is “higher-level” orchestration in the sense that it can manipulate service-layer elements, but HP also extends orchestration downward to a low level using the same logic. Services are composed from service elements that can be “service-like” or “resource-like” in nature. The elements are structured in the Customer-Facing and Resource-Facing services approach that the TMF has used historically (they’re apparently moving away from it now), and also that both my CloudNFV and ExperiaSphere architecture employed.
Part of HP’s approach is a very state/event orientation. Service elements appear to have states and can be driven by events, and there’s policy logic that for example lets you decide where you are (state-wise) where you need to be, and how to get there. This approach molds a lot of service intelligence and policy management into the model itself, which is what I think is the right approach.
The Director supports multiple VIMs and so can orchestrate services that require different parts of the network be based on different vendors or technologies. HP embraces the notion of an infrastructure manager for non-NFV elements and for SDN services, which is how they can control legacy infrastructure. The “internal” VIMs work with the same plugin architecture used in OpenStack, and HP believes that it’s likely that multiple NFV data centers would mean multiple VIMs and cross-data-center orchestration. They’ve obviously thought through this aspect of NFV deployment pretty carefully.
If I have a quarrel with the HP approach it’s that they may be following the ISG E2E process very literally when there are aspects of the ISG model I’m concerned about. I don’t see any virtualization of management; HP follows the model of the ISG in presuming that management elements are composed into virtual functions and that resource MIBS are potentially directly accessed. A Director element called “agent-less monitoring” provides infrastructure event detection, something that seems like it could evolve into a more “virtualized” management approach, but HP isn’t yet there with respect to using Repositories and derived management views. I’m concerned, as I’ve noted in other blogs, about the scalability and security of the native ISG model.
The logical question here is whether HP can make the NFV business case, or at least do as good a job of making it as anyone can at this stage. The business case for NFV is complicated, and I think there’s no question that the V2 targets for NFV Director will be needed to drive NFV deployments in the real world, but it looks like HP has a good chance that its execution will live up to the architecture. One of the interesting things about NFV Director is that it evolved from a very different point than most NFV approaches. It’s an evolution of HP’s Service Activator, an OSS component, and that gives it a jump on others in two ways.
First, obviously, Service Activator can activate legacy services, which means that NFV Director can as well, so legacy and NFV can be comingled in deployments. Classic NFV considers the parts of the network not implemented as virtual functions to be out of scope, which can seriously limit the ability of an implementation to deliver meaningful overall gains in service agility and operations efficiency.
Second, Service Activator was always a high-level orchestrator, meaning that it was expected that there would be a second level of technical orchestration below it for most services. I’ve said from the first that NFV orchestration really had to be multi-leveled or specifics of network control would end up percolating into service definitions, creating major headaches when changes to infrastructure were made. Not only that, unless even current infrastructure is homogeneous, infrastructure-specific orchestration at the service level means that service models might have to accommodate different equipment in different places in the network. None of that makes any sense if you’re looking to reduce operations costs.
I noted in a prior blog that I had attended a carrier meeting where two operations types sitting next to each other had totally different visions of OSS evolution. HP heard that same thing, apparently, because they reflect the same two options—limit OSS impact or use NFV to restructure operations overall—in OpenNFV. They have a nice slide pair that describes how the Director can be essentially a siding down which NFV elements can drive before resuming the mainstream of operations, just to handle the virtualization issue. They also show that the Director could be used to drive lower-level processes from service models, essentially restructuring operations to be model-driven.
I’ve always liked the HP architecture, and while their current implementation hasn’t reached the V2 state that would bring full OSS/BSS and NMS integration to the table, I’m pretty comfortable they’ll get there. Given that their model seems far more likely to meet NFV service agility and operations efficiency goals than other more limited approaches, I think it’s fair to say that HP’s OpenNFV could be the best major-vendor offering out there for service modernization in an SDN and NFV world.