One of the outcomes of the recent meeting of NFV ISG members, hosted by CableLabs, was recognition of the value of open-source implementations of NFV and a need to harmonize efforts there. Ironically, it’s also been reported that four operators have formed their own open-source activity to develop a MANO implementation. It’s worth looking both at why that is and what these activities will have to address.
To a software guy, one of the big problems with the ETSI MANO concept is that like the rest of the framework defined in the model, it was synthesized from the bottom up instead of analyzed from the top down. One thing this has generated is too many explicit components and interfaces—it builds in its own complexity. The multiplicity of interfaces and the inefficient assignment of features to elements generates a lot of seemingly shared responsibilities. Look at the definition of what MANO does in the ETSI documents versus what a VNF Manager (VNFM) does and you’ll see the problem.
Operators have now started to hit the wall with the limitations of the specs because they’re starting to attempt to move beyond simple proof-of-technology PoCs into broader trials that demand benefits be proved. That exposes the NFV structure to a wide range of service needs and a broad requirement for integration with current and future equipment and operations practices and tools. I believe that what we are seeing today with our four operators, and others as well, is a growing understanding that the process isn’t working as it must. The question is whether they understand just how it must. The current model is wrong, but what’s the right one?
What I propose to do is try to bend the ETSI vision into something that might have come out of a proper top-down software design. I’ll reference THIS FIGURE to do this, so you might want to download it for reference as you read the rest of this.
What this figure shows is a kind of modernized view of the ETSI NFV model, trying to focus on the pieces and not all the implementation details that I think are inappropriate for the mission of the body. NFV starts with infrastructure (both network and server resources) that are represented in the NFV process through a series of Virtual Infrastructure Managers (VIMs). These VIMs assert a set of intent models that describe the functional capabilities of the infrastructure, to host virtual functions, connect things, etc. The intent models describe the connection points, the SLA parameters, and a set of generic functions that the models support, such as “deploy” “redeploy”, “scale”, etc.
The VIM intent models are referenced in a service model, and this model is decomposed and parsed for lifecycle management by what I’m calling Service Lifecycle Management but which is in ETSI divided into the VNF Manager (VNFM) and Management and Orchestration (MANO). VNFs contribute and consume management data through another intent-modeled interface, and they also can exercise some lifecycle management processes through this interface. This whole process links to current operations and management systems through a third intent-modeled interface.
In this framework, the role of what ETSI and the operators call “MANO” is fairly clear, providing you generalize “MANO” to my Service Lifecycle Management. It is the set of NFV software elements that mediate between the abstractions of resources presented by the VIM and by VNFs (which are software resources) and the operational framework of the operator. Operators build service models, and when they are ordered turns them over to MANO/SLM to instantiate them and sustain them.
If you look at things this way, then MANO/SLM is a pretty straightforward example of state/event programming. Every element in a service model has a state, and recognizes a set of events. Ordering something sets up the model of the instance in the ORDERED state and the activation of the order generates an ACTIVATE event (example names only!) to command the software to decompose the model, assign resources, connect things, etc. When the service is deployed it enters the OPERATING state, where it remains until something unusual occurs, or until the service term expires.
The process of lifecycle management described here and the intent-model interfaces shown allow you to say that as long as a piece of infrastructure 1) is represented by a VIM and 2) asserts one or more intent models to represent the services it represents, then that infrastructure can be used by any service model that references one of its intent models. If the operators, vendors, or standards groups create a number of standardized intent models (Service-Chain, for example), any implementation of that intent model should be fully interoperable.
Similarly, a VNF can be onboarded using a standard process if 1) it references, directly or indirectly, the state of its resources and the services of NFV through a standard intent model and 2) the VNFs and VNF PaaS Intent model is linked to a service model by the process of deployment. To make this work, a reference lifecycle state/event table is required. This could be provided by an operator or standards group as the template to be used for a given function (“Firewall”) or it could be offered by the vendor who supplied the VNF. In either case, the processes needed at the state/event intersections could either be drawn from a repertoire of “standard” NFV processes or provided by the vendor or operator.
The central piece of this is the service model, and here I offer a simple hypothesis. If the efficiencies and agility of NFV come from software automation of lifecycle processes, then there must be a model of what the desired state of a service is. NFV software must then use that model to achieve a desired state. The best of the cloud DevOps stuff works this way already. Besides showing that it was madness to start talking about NFV without defining a service model, this hypothesis says that no MANO/SLM implementation that doesn’t start with a model has any hope of providing service automation.
I would offer a second hypothesis: Service models allow for resources and service components to be represented and manipulated in an abstract implementation-independent form represented by a functionally derived intent model. Then whatever can realize a given abstraction can be used to deploy it. Integration of NFV can only be achieved by this abstraction/realization combination, again linked integrally with the service models. Thus, without both service and intent modeling, NFV integration can never really be standardized and NFV can never be truly open.
Here’s another interesting point. A service model builds services by assembling abstractions. One abstraction type is a set of virtual functions, another a set of virtual resources. Could a third kind of abstraction be a complete MANO implementation of another party? Why could we not create a “VIM” that talked not to resources but to the order/OSS/BSS intent model interface of another MANO? If that were the case, then an implementation of NFV could consist of service-modeled-and-connected MANO silos. So even if we had incompatible details on NFV implementations, we could harmonize them at a higher level.
Application of these principles creates an NFV model that has three broad elements (VIM, MANO/SLM, and VNFs) and has three intent-modeled interfaces. It is manageable to standardize these interfaces, but in some ways it’s less critical that be done because it’s not difficult to transform one abstraction into another. The service data model guides the software components through the service lifecycle, and everything that’s needed to deploy and manage services are simply “microservices” in cloud terms.
All of these points are, or should be, critical to these four operators looking at their own contribution to open-source MANO. If my two hypotheses are correct, and I believe very strongly that they are, then not only would further evolution of the existing MANO approach be a waste, everything that’s been done so far should be reconsidered in the light of the new reality. Or, truthfully, the reality that’s been there all along and is only now (and slowly) being accepted.
This is where operators can help their own cause. They complain that vendors have dragged their feet, and that’s generally true. They’ve complained that opportunistic vendor squabbling has derailed important progress, and that’s less true. The responsibility for insuring buyer requirements are met rests with the buyer. Operators, especially those now involved in open-source MANO, need to make it clear that something completely new is needed. Yes, that will be embarrassing, but all the time and effort in the world is not going to rehab the MANO notion. The operators say they aren’t tied to the ISG MANO process. OK, prove it.