One of the positive signs emerging from the ETSI NFV ISG is recent interest in multiple orchestration layers. The notion of a “split orchestration” model that separates traditional NFV Management and Orchestration (MANO) from “resource orchestration” could be a powerful enhancement to the basic NFV mode, and perhaps even a step toward embracing a full and practical vision of top-down service orchestration. It could also lead to issues.
The original NFV end-to-end model, which is largely unchanged today, called for a MANO function to control the deployment of the virtual network functions and components needed for a given feature or set of features. From the first, it has been clear that there are serious complications associated with this simple single-layer orchestration model. It doesn’t go high enough to envelop operations processes, it doesn’t go wide enough to cover the service end-to-end, and it doesn’t go deep enough to describe technology-specific requirements of various cloud or network platforms.
The cloud has confronted a similar problem. OpenStack’s Quantum networking, which was renamed “Neutron”, is a very simple build-a-subnet-and-connect approach to cloud deployment that works fine as long as you’re deploying a single set of application components in a subnet, but creaks unmercifully when you try to scale it to lots of tenants or complex applications with shifting, dynamic, component structures. In the cloud DevOps deployment and lifecycle scripting area, there are increasing signs of convergence on a more sophisticated, modular, approach.
The split of MANO orchestration creates a “Network Service Orchestrator” that talks to operations processes above and the VNF Manager (VNFM) below. The VNFM talks with the Resource Orchestrator (RO), which in turn talks to various (presumably) “Virtual” Infrastructure Managers (VIMs, which since I don’t think will always be managing “virtual” infrastructure, I call Infrastructure Managers or IMs). The RO, in effect, orchestrates (V)IMs.
If we extrapolate this view, what we get is that VIMs are designed to be the abstractions of resources (what does a RO orchestrate if not a resource?) In order for this to work, we need to have some overall model concept for a resource and a way of representing it in an RO structure. That overall model would be composed of representations created by the VIMs. By inference, there must be more than one VIM and VIMs presumably represent (individually or collectively) a set of models above and real resources below.
This approach is a step forward for the simple reason that anything that makes orchestration a multi-layered structure is positive. It conforms to what I think is basic logic, and it also conforms to published operator views of the structure of service orchestration overall. It does pose some questions and raise some issues.
The first is those model representations for a VIM. The goal of any abstraction model is to avoid brittle behavior, meaning exposing details within the model to the outside world. That would mean that a change in the implementation (which is supposed to be opaque) is in fact resource-specific. Change resources, and you have to change all the models. Logically, VIMs should be intent models in every sense.
This raises the question of what’s inside a VIM. Normally you’d think that OpenStack was a model for a VIM, and that Nova deployed instances and Neutron did connections. Leaving aside the point that Neutron isn’t ideal for the connection mission, the point is that in most real implementations you’d use a language like HEAT to orchestrate those processes. That would place HEAT orchestration inside the VIM. Does the ISG propose to use HEAT as the RO, or is there another hidden layer of orchestration inside the VIM?
Every time we establish a layer of orchestration, we commit in a very real sense to defining a set of abstractions that the layer orchestrates, a process for adding to that list as needed, an organization to administer the list and insure consistency and lack of overlap, and so forth. That’s not a problem unique to the ISG’s split agenda, but it’s one that has to be addressed and that so far is still not being handled. Without such a process we end up with a virtual world even more complicated than the real world we’re trying to simplify.
The second issue is one of “coupling”. The split in orchestration adds elements, and the elements in the ETSI E2E model are connected by interfaces, which implies interactivity. Can a VNF, and an Element Management System as separate software components that may exist separately for each service, “interface” with a common function like a VNFM, which must also interface with an RO? At a given point in time, there could be thousands of deployed VNF-instanced services, each of which might be trying to tell a VNF function something. The RO might be working on another service or a set of them. How do all these threads connect with each other? Multiple threads? If so, how do you make sure that you can block and unblock threads correctly, that you don’t end up starting a process and having it die forever because it’s dependent on something that’s in turn dependent on it?
An issue that unites these roles is that of functional separation. “Too many chefs spoil the broth,” is the old saw. If you have two or three or more places to orchestrate, there’s a major question about just what gets orchestrated where, and what technology is used. In my view, orchestration layers should be based on logical functional subdivisions of the process of deployment. There is no question that the highest level is the “service level”, which in the ETSI model (and in my view, and the view of operators) lives somewhere in operations software above the NFV implementation. There’s no question that the bottom layer is what I’ll call “domain-specific resource orchestration”, meaning the stuff that’s needed to implement a specific model of deployment based on what you’re deploying on. The stuff in the middle is a little more complicated.
I think that there’s ample proof in the industry, ranging from the structuring supported by the TMF SID to that of TOSCA, that anything above the domain-specific resource orchestration layer should be structured hierarchically, so that a model shows service element relationships and carries parameters. This structure also lends itself to intent models. There are also clear signs that we need to launch a serious effort to define the high-level abstractions on which intent models would be based. For example, we should define what a “VPN” exposes as properties and parameters, and similarly what a “FunctionHostingPoint” (VM or container or even vCPE) has to expose.
I am hopeful that we’re seeing signs of convergence between the buyers and the standards in this space. The bad news for the vendors is that this probably means the opportunities for differentiation are going to pass them by unless they get out in front of the trends, establish credible product ecosystems, and make the business case for NFV in a compelling way. Events are overtaking everyone here, and though the pace is slow at present, it could be accelerating.