It has always been my view that NFV would be better and more efficient if there were a common modeling approach from the top layer of services to the bottom layer of infrastructure. I still feel that way, but I have serious doubts on whether such a happy situation can now arise. The service-centric advance to NFV now seems the only path, and that advance almost guarantees a multiplicity of modeling approaches. They might be harmonized, though, by adopting some of the principles outlined in the Verizon paper I’ve blogged about, and that’s the topic of the day.
A model is an abstraction that represents a complex interior configuration. In NFV, the decomposition of a model into that internal complexity is the responsibility of the orchestration process. Everywhere you have a model, you have an orchestrator, and of course of you have different modeling approaches then you have multiple orchestrators. I’ve always felt that introduced complexity and inefficiency, which is why I favored a single one—but we’ve already noted that’s probably no longer practical.
A generalized NFV architecture should, and likely would have, contained a single modeling/orchestration implementation, but the ETSI work hasn’t defined all the layers and only a few (six) vendors have a unified architecture to date. Further, there’s been little (well, let’s be honest, no) progress toward a full-scope NFV business case. That’s what got us on a service-driven path, and service-driven approaches rarely develop holistic modeling/orchestration visions. That’s because individual services don’t expose the full set of issues.
There are two pieces of good news in this. First, most service-driven NFV starts at the bottom and goes no higher than necessary—which isn’t very far. Second, a proper modeling and orchestration approach at a higher level can envelope and harmonize the layers below even if they’re not based on the same approach. This is one of the features of Verizon’s End-to-End Orchestration or EEO approach, but it also applies down deeper, and it’s the basis for coercing order from service-specific NFV chaos. But it’s not without effort and issues.
Let’s suppose we have a “classic ISG” implementation of NFV, which means that we have some sort of model that represents the VNF deployment requirements of a service, which means we have individual VNFs and the “forwarding graph” that somehow connects them. This combination, represented using something like YANG, represents a specific model at a low level. It’s the sort of thing you might find in a vCPE business service deployment.
Now let’s suppose we want to incorporate this in a broader service vision, one that for example includes some legacy service elements that the first model/orchestration didn’t support. We could add a new layer of model/orchestration above the first. If our first model is M0 we could call this second one M1 to show its relationship. The M1 model would have to be able to properly decompose requests for legacy provisioning, and it would have to be able to recognize a model element that represented an M0 structure and decompose that structure into a request to pass a low-level model to the appropriate low-level orchestrator. This is a hierarchical decomposition—one model can reference another as an interior element.
In my example, I assumed that the M1 model had orchestration that would directly process legacy deployments, but you could just as easily have had a second M0 level, this one for legacy, and had the M1 level reference the models of either of the two options below. Thus, even if you assumed that you had two different ways of implementing NFV (deploying VNFs) you could still envelope them both in a higher-level model, as long as each of the two options below could be identified. Either give them a different model element, or have the decomposition logic determine which of the two was needed.
What this shows is that layered modeling and orchestration can accomplish all sorts of useful stuff, including harmonizing different implementations or addressing the deployment of things that a given model doesn’t include/support. And it can be carried on to any number of layers, meaning that you could orchestrate a dozen different model layers. This (sorry to beat a dead horse here!) is another reason I liked the idea of a single model/orchestration approach. It would have let us decompose a model using recursive processing by a single piece of software. But, onward!
Verizon’s paper calls for two layers of service modeling, one representing the retail view of the service as it might be seen by a customer or the OSS/BSS, and the second representing the input to a connection controller (SDN controller with legacy capability). I think it would be helpful to generalize this to allow any number of layers, and to recognize that each “leaf/branch” on the tree of a service hierarchy would pass from service-abstract to resource-abstract in its own way at its own time, subject to the higher-layer service/process synchronization needed to insure pieces get set up in the right order (which Verizon’s paper includes as a requirement).
How about Verizon’s EEO? The Verizon paper has an interesting point in its section on E2E service descriptors:
Apart from some work in ETSI/NFV, which will be discussed below, there has not been much progress in the industry on standardizing EENSDs. That is not considered an impediment, for the following reasons:
- EEO functionality and sophistication will improve over time
- Operators can start using EEO solutions in the absence of standard EENSDs
Since an EENSD is essentially a service model, what Verizon is saying is that you could hope that the industry would converge on a standard approach there, but if it didn’t operators could still use proprietary or service-specific EEO strategies. True, but they could also simply overlay their “EEO” models with a “super-EEO” model and harmonize that way.
I said earlier that this wasn’t necessarily a slam-dunk approach, and the reason should be obvious. If a given Mx is to superset a lower-level model then the decomposition to that lower-level model and the invocation of its orchestration process has to be incorporated into the modeling/orchestration at the Mx level. Somebody would have to write the code to do this, and even if we assume that the orchestrator at our Mx level is open-source, there’s still work to be done. If it isn’t, then only the owner of the software could do the modification unless there was a kind of plug-in hook mechanism provided.
To make this kind of model-accommodation easier, the first requirement is that all modeling approaches provide the documentation (and if needed, licensing) to allow their model to be enveloped in one at a higher layer. The second requirement is that any modeling layer have that plug-in hook or open-source structure such that it can be expanded to include the decomposition of new lower-level models.
All of this could be accomplished in two broad ways. First, any of the six vendors with a comprehensive implantation could focus on “de-siloing” and service harmonization in their development and positioning. Second, some standards group or open-source activity could address it as an explicit goal. I think AT&T and Verizon have both made the goal implicit in their announced approaches, but real progress here is going to depend on somebody picking up the standard of harmonization and making a commitment.
A final interesting point is that this approach appears to offer an opportunity to offer “modeling-and-orchestration-as-a-service”. Higher level models could be linked to cloud service portals, passing off lower-level provisioning and lifecycle management to operators’ own implementations. This could create a whole new set of NFV opportunities and competition among model providers could move the whole service-first approach ahead, to the benefit of all.