OPNFV, the Linux Foundation open-source project for NFV, is getting ready to release its first preliminary code. Everyone, including me, is rooting for a success in creating first a reference implementation of NFV that’s functionally complete and second an open-source framework for that implementation. My concern is as it’s always been; do we know that “reference implementation” is “functionally complete?” I’d like to offer some comments to OPNFV and its members on what is needed, which I’ll call “principles”.
First and foremost, I think operators globally would agree that NFV should embrace any and all hosting resources. We are advancing server technology with low-power and edge-deployed technology, and we’re optimizing virtualization with things like containers. It’s less desirable to standardize on a platform than to standardize a way to accommodate whatever platforms operators find helpful. The key to achieving this is what I’ll call an open infrastructure management model, and it has four requirements:
- The implementation must support multiple VIMs, with the VIM to be specified by the model used to drive management and orchestration (MANO). All VIMs must accept a common “input” from MANO to describe what is to be deployed so that all VIMs are portable across all implementations of MANO.
- Resources to be used for hosting/connecting VNFs as part of NFV Infrastructure (NFVI) must be represented by a VIM that supports the common input structure described above.
- If it is determined that some hosting options may not be available for all NFVI choices, then the VIM must be capable of returning a response to MANO indicating that a deployment request cannot be executed because one or more features are unsupported by the specified VIM.
- Operators will need NFV to control legacy connection resources either within the NFVI data centers or in the non-NFV portion of a service. This means that there should be “network managers” (to use a term that’s been suggested in the ETSI ISG) that should look in most ways as VIMs look but support connection requests rather than both connection and hosting. I suggest that given the similarity, the concept of an Infrastructure Manager with two (current) subclasses—VIM and Network Manager—is appropriate
We should be viewing these IMs as “black boxes”, with defined interfaces but flexibility in assigning the processes internally. What goes on inside an IM is, I think, opaque to the process of standardization. Yes, we need one or more reference implementations, but if the goal of an IM is to represent an arbitrary set of controllable resources, we have to give the IM latitude in how it achieves that goal.
With these requirements at the bottom layer, we can now move upward to management and orchestration. Here, I believe that it’s important to recognize that the ISG’s work has defined MANO and VNFM separately, but if you read through the material it’s fairly clear that the two are features of a common implementation. At one time (and even now, for some members) the ETSI ISG used the term “package” to describe a deployed unit. A package might be a complete service or service element or just a convenient piece of one. For my second principle, I think that OPNFV has to recognize that MANO and VNFM operate collectively on packages, and that the definition of a package must provide not only how the package is deployed on resources but how the management connections are made. I also think that “packages” are fractal, meaning that you can create a package of packages or a package of VNFs/VNFCs.
The question at the MANO/VNFM level is how the package is modeled. It seems to be possible, based on my experience at least, to model any package by defining a connection model and then identifying nodes that are so connected. We have LINEs, LANs, and TREEs as generally accepted connection models. A package might then be two NODEs and a LINE, or some number of NODES on a LAN or in a TREE. With the right modeling approach, though, we could define another model, “CHAIN” that would be a linear list of nodes. Thus, a connection model could represent any generally useful relationship between nodes.
There are a lot of ways to define this kind of model. Some vendors already use XML, which I’ve also used on a project. Others prefer TOSCA or YANG. I think it would be helpful to have a dialog to determine whether operators think that their services would be defined hierarchically as a package tree using a single standard modeling semantic, or whether they’d be happy to use anything that works. I suspect that the answer might lie in whether operators thought service definitions could/should be shared among operators.
If a standard model approach is suitable, then I think that models could be the input to IMs. If it’s desired to support multiple model options, then IMs will need some standard API to receive parameters from MANO. Otherwise IMs would not be portable across MANO implementations.
Going back to the VNFM issue, I believe in the concept I’ve called “derived operations” where each package defines its own MIB and the relationship between that MIB and subordinate package or resource MIBs. I still think this is the way to go because it moves management derivation into the model rather than requiring “manager” elements. I’m willing to be shown that other ways will work, but my third principle is that OPNFV has to define and provide a reference implementation for a rational management vision.
A related point is lifecycle management, a responsibility of the VNFM in the ETSI spec. There is simply no way to get a complicated system to progress in an orderly way from service order to operations without recognizing operating states by package and events to signal changes. Principle number four is that OPNFV has to provide a means of describing lifecycle processes in terms of package state/event progressions.
The final principle is simple. Operators build services today in a variety of ways—they may start with opportunities and dive downward to realization, or they may build upward from capabilities to services. The “service lifecycle” to an operator is more than the deployment-to-operations progression, it’s the concept-to-realization progression. OPNFV has to demonstrate that any service lifecycle process from conception to delivery can be supported by their reference implementation. That means we have to define not only the baseline model for example, but also the tools that will be used to build and validate the models.
I think that all of this is possible, and some at least seems to be consistent with the direction that the ETSI ISG is taking for their second-phase activity. I also think that all of this, in some form at least, is necessary. A reference implementation that actually does what’s needed is enormously useful, but one that fails to support the goals of NFV will be far worse than no implementation at all. It could freeze progress for so long that operators are forced to look elsewhere for solutions to their revenue/cost per bit problems. We may not have the time for that.
