Earlier this week in my blog I talked about a model-driven open approach to NFV that focused on deployment elements, meaning infrastructure. I introduced the notion of virtual function classes as the framework for VNF openness too, and I want to follow up on that today.
The general point of my earlier blog was that for openness to happen, you had to define a series of abstractions or functional models that represented the base class of capabilities you wanted, then define the various ways that those capabilities could actually be decomposed onto infrastructure. You assemble functional models into services in a generic way, then commit functional models to infrastructure in whatever way the infrastructure demands.
This same approach can be applied to Virtual Network Functions. The high-level functional model (“Firewall”) might be decomposed into one of two technology-based models—“RealDevice” and “FirewallVNF”. The latter is the combination of the VNF software and the hosting of that software on infrastructure. We talked about the latter yesterday, and so it’s the VNF software we’re going to address today.
All firewall VNFs should be equivalent, meaning that all the ways of instantiating a virtual network function of a given functional class should be interchangeable and identical when looked at from the outside. Clearly all the software that might be used for a firewall VNF doesn’t take the same parameters, expose the same interfaces, or have the same management capabilities, so the harmonization of those differences has to be framed in some way.
That harmonization has to start, as the whole modeling approach had to start, with an abstraction that represents the function class—“FirewallVNF” in this case. It’s my view that this function class would be an extension (for software types, think of a Java Class that “Extends” a base class) of the base class of “AnyVNF”. If we adapt this approach to the ETSI ISG’s approach, the base class would define the scope of the necessary APIs that were exposed by the centralized part of the VNF Manager (VNFM). This base class might expose a parameter port, a management port, a map of “internal ports” to interconnect elements, and a set of “service ports” that will connect outside.
The goal of onboarding a given VNF is now to map to that FirewallVNF template (and by inference to the AnyVNF set). The responsibility for that, again using ETSI’s concepts loosely, devolves on the “distributed” part of the VNF manager. You have a VNF that’s a firewall implementation. You add to that VNF the necessary custom logic to make it appear in all respects as an instance of FirewallVNF, which means that all of the management, deployment, and functional characteristics of that implementation are mapped to the common model. Once that’s done, you can deploy any of those implementations.
There are five beauties to this approach, IMHO. The first is that it solidifies what I think has been an incredibly fuzzy concept—the VNFM. Second, it defines a very specific goal for openness—which is to harmonize something to a function class. Third, it makes the validation of a given function’s adherence to the open model a simple matter to test. You could build a test jig into which instances of the function class (implementations of FirewallVNF in our example) could be inserted and validated. Fourth, all of the integration happens in matching the implementation to the function class, so it’s the responsibility of the VNF vendor or an agent thereof. What’s handed off is a complete, open, useful, package. Finally, anyone can run these tests in the same framework and get the same result. Vendors and operators can do testing for themselves, and any “lab” can recreate the “experiment” just like science generally requires. We don’t have to establish or accept some central body as responsible for testing.
Vendors should like this model because it makes their own labs and integration testing easier because it provides them an explicit target to hit—matching to the functional class. Operators should like it because most of their own onboarding efforts would be expended for new functional classes; basic testing or certification of vendor labs would cover the specific integration issues. VNF vendors should like it because it could simplify their own integration.
I emphasize the “could” here because the question of who defines the functional classes remains. This would be a worthy activity for some group like the OMG or even the ETSI NFV ISG, with the cooperation of operators and vendors. I suspect that at least the “AnyVNF” base class would have to be defined by the NFV ISG because its requirements relate to the interface between VNFs and the rest of the NFV world. The management stuff would also have to be integrated here.
This might prove to be the big hole in the functional class approach for VNFs. There are, IMHO, a lot of open questions on management for NFV. I suggested in an earlier blog that the ISG needed to incorporate the notion of Infrastructure-as-Code from the cloud, and that notion has at least the potential for defining the use of events to link services and resources when linkage is required for service lifecycle management. That poses two challenges; what events get generated under what conditions, and how do you reflect events in the ETSI model in the first place.
This issue can be finessed (and probably should be) in part by saying that resource events are directed to the functional models for the service and not to the VNFs. If that’s done, then all we need to worry about is how to harmonize the failure of a real device versus its equivalent virtual function. If a firewall device fails, we need to communicate that to the service level. If a FirewallVNF fails, the same has to be true if we follow the precepts of our open model. That means that part of the base class AnyVNF stuff has to be able to recognize the state of the VNF just as a management system would recognize the state of firewall hardware. One path to that is to use the SNMP MIBsets for the basic “real” devices as the foundation data. That would work even if we didn’t assume “event generation” to drive service changes and instead relied on testing the state of resources and VNFs.
I think all of this demonstrates that the techniques for creating open VNFs or facilitating the integration and onboarding of VNFs has to be based on the same notion of a functional-class model set that can be composed from above and instantiated below. That way, it integrates with resource allocation during deployment, redeployment, and other lifecycle stages. In VNF onboarding and integration, as in network infrastructure accommodation, we’re trying to resolve detailed issues without a suitable architecture framework to guide us.
This is where I think vendors and operators need to guide things. The architecture models for next-gen networks promulgated by operators in various parts of the world demonstrate (and in some cases explicitly say) that the ISG framework for NFV and the ONF framework for SDN aren’t sufficient. You can’t just cobble together standards at a low level and expect them to add up to something optimal, or even useful, at a high level. Harmonizing the architecture of VNFs is critical and I’d love to see vendors present their approaches, and base them more on the cloud than on abstract interfaces. A good one could form the basis for broad deployment.