What NFV Needs is “Deep Orchestration”!

If my speculation is correct and operations vendors may take the lead in NFV, what happens to all the grand plans the technology has spawned?  Remember that my numbers show the ROI on an OSS/BSS modernization to improve operations efficiency and service agility is much better than network modernization based on NFV.  Would we strand the network?  The answer may depend on what we could call “deep orchestration”.

“Orchestration” is the term that’s used today to describe the software-driven coordination of complex service processes.  In NFV, the term has been applied to the process of making VNF deployment and connection decisions.  The problem in the NFV sense is that a “service” includes a lot more stuff than VNFs, and in many cases operators tell me that some services that they’d want to “orchestrate” might include no VNFs at all in some areas, and so for some customers.

There is also an orchestration process associated with service-layer automation.  The TMF defines (in its Enhanced Telecommunications Operations Map) a complex model of processes associated with service offerings.  It even (in GB942, the business-layer stuff), offered a model to associate events to processes using CORBA that qualifies as orchestration via a data model (the contract).  There were very few implementations of GB942, though.

The negligible commitment to data-model orchestration TMF style meant that NFV orchestration could have branched out to address the full spectrum of service and resource orchestration.  This approach has been supported at the product level by the six vendors I’ve been citing as those who could make the NFV business case (ADVA, Ciena, HPE, Huawei, Nokia, and Oracle after M&As are accounted for).  However, these six have not made enormous progress in actually building that uniform orchestration model.  Now Amdocs and Ericsson seem to be attacking orchestration at the service level, and because that could produce most of the benefits of NFV at a better ROI, these guys could end up not accelerating NFV but stalling it.

In theory we could see vendors at the OSS/BSS level actually add effective NFV orchestration to their model, meaning that they could extend their service-layer orchestration downward.  Amdocs has been looking for NFV test engineers, which suggest that they might want to do that.  However, the OSS/BSS guys are as hampered as the NFV vendors were by a single powerful force—organizational politics.  In an operator, the OSS/BSS stuff is run by the CIO and the network stuff run by the Network Operations group, with the CTO group being the major sponsor of NFV.  That’s a lot of organizational musical chairs to chant to and fill if you want an integrated approach.  So what could be done to save actual network modernization?

This is where “deep orchestration” comes in.  If there’s going to be service orchestration at a high level, through an OSS/BSS player, then at this point it will be difficult to convince CIOs to accept NFV-style orchestration of operations processes.  That means that getting CIO backing (and maybe CEO/CFO backing) will require tying into the OSS/BSS orchestration process in some way.

Right now, OSS/BSS systems manage devices.  The prevailing wisdom (??) for NFV is to make NFV look like a virtual device, which is why I call the approach the “virtual device model”.  The idea is that if you deploy virtual functions that mimic the behavior of devices, then you could present OSS/BSS systems with the virtual form of these devices and they’d be none the wiser.  This approach would work fine for both NFV and OSS/BSS so what’s wrong with it?

The answer is that it doesn’t promote NFV in any way.  Virtual devices accommodate NFV, they don’t facilitate it.  What we need to do, if we want NFV-driven modernization, is one of two things.  First, NFV vendors who can orchestrate operations processes could advance that notion aggressively and beat back the new efforts of the OSS/BSS players.  That, frankly, isn’t likely to happen because few of the NFV Super Six who can do full-spectrum orchestration have the credibility and connections to influence OSS/BSS decisions.  Those who do haven’t done it well up to now, and it’s unrealistic to think that’s going to change.  Way two is to structure NFV orchestration to complement service orchestration.

Everything I’ve done on NFV (CloudNFV and ExperiaSphere) has recognized what operators have told me, which is that “services” and “resources” are two different domains, even politically.  The guiding principle of deep orchestration is recognizing that and providing a suitable boundary interface between the two that lets service orchestration have a more modern and (dare I say) intimate relationship with lower-level orchestration, including NFV.  But what’s different between deep orchestration and virtual devices?  The best place to start is what’s wrong with virtual devices.

The first problem with a virtual device model is that it represents a device.  In classic networks, you create services by coercing cooperative device behavior, but when devices are virtual they don’t have explicit behaviors.  Forgetting for a moment what happens as virtual is assigned to resources and becomes real, virtual devices limit operations because they are derived from appliances, which optimum new-age devices are not and should not be.

The virtual-device link to a real device creates the second problem, which is that of reflectivity.  If you have an issue in a real device you can assume it’s a real-device issue.  If it’s an issue in a virtual device you have to map the issue to a real-device MIB, which may not be easy if you’ve virtualized the resources and your firewalls now contain servers and IP networks.

The solution to the problem is to present not fixed devices but flexible abstractions to the OSS/BSS.  That means developing a more agile model than a “device”, a model that can represent an arbitrary set of features and connections, and an arbitrary set of SLA properties.  One way to model this sort of thing is the “intent model” concept I’ve supported in other blogs, but it’s not the only way.  The key is to insure that the OSS/BSS boundary with SDN and NFV be generalized so that old-network behaviors aren’t imposed on the new network.

I still believe that the best approach to orchestration in the long run is to define a single modeling approach from the top to the bottom.  This would let service architects and resource architects build services downward from needs or upward from capabilities with the assurance that the operations and management practices could be integrated throughout.  The next-best thing would be to define a boundary point, which I think is the “service/resource” boundary that naturally fits between service (OSS/BSS/CIO) and network (NMS/NOC/COO) activities, and codify that in as general a way as possible.

Speed is also important.  Operators can realize about 80% of the agility and efficiency benefits of NFV simply by orchestrating service processes optimally.  That leaves a very small chunk of operations benefit to justify a network modernization, forcing you to define services with features not currently supported by network devices if you want to justify changing infrastructure.  We’ve not really worked on how those service/feature relationships would develop and we don’t know whether regulators and lobbyists will cooperate.  I think that this year is critical, because I think that this year will mark the point where operations takes the initiative, if true NFV vendors don’t do something to recapture it, or at least ride the service orchestration wave.  Deep orchestration may be essential in NFV vendor survival.