I’ve pointed out in a number of my past blogs that of all the things needed from an SDN or NFV implementation to make the business case, none tops an effective service management automation approach. I’ve also noted that the NFV ISG initially put end-to-end management out of scope, and that they also ignored the issues of federation of services across management domains. The ISG seems to be reversing itself on these issues, but the architecture was laid out without them and retrofitting to put them in could take quite a while. Other bodies might have to take up the slack.
The most logical would seem to be the TMF, which launched an activity called ZOOM (Zero-touch Orchestration, Operations & Management) to deal in part with SDN/NFV impact and in part with the broader issue of “modernizing” OSS/BSS. That duality of mission, as you’ll see, carries over into even some vendor Catalyst presentations made in Dallas early in November.
HP’s Catalyst presentation has what should be the tag line for the whole topic: “Combining NFV, SDN and OSS is not easy”, which it surely isn’t. The presentation identifies three specific issues (paraphrasing):
- Today’s OSSs are process silos that lack procedures to automate responses to service events, particularly fulfillment and assurance
- ETSI NFV specifications don’t consider ‘hybrid’ services that extend over both legacy and SDN/NFV infrastructure.
- The general approach taken by the TMF and by OSS/BSS vendors is based on linear “waterfall” workflows that are more suitable for manual processes than for service automation.
HP’s Catalyst augments “standard” OSS/BSS service processes with NFV processes. The effect of this appears to be the creation of a multi-level orchestration model that allows operators to orchestrate aspects of OSS/BSS while NFV MANO remains as the standard for NFV elements. They don’t go into the details on how this is done, which is a pity in my view because HP has the most mature modeling approach for services and resources. A key point that I think could have been made is that their service modeling would enable them to either model services as two interdependent classes—legacy and NFV—or as a single integrated class.
Huawei also presented a Catalyst, and there are some common threads between the two presentations. One is that it’s critical to extend models for services across both legacy and SDN/NFV elements. Another is that a closed-loop process for automating service lifecycles (both a normal and accelerated one) is critical.
The realization of these goals is described a bit more clearly in Huawei’s material. They define a Management Control Continuum (MCC), which includes all of the components of OSS/BSS, NMS, and SDN/NFV management elements. This (I think) is essentially the structure I suggested in my ExperiaSphere project, where all of the processes that support a service lifecycle are orchestrated explicitly, through a model. Huawei appears to be calling all these little elements “microservices”.
It would appear that you could visualize a service as a model (my term: intent model) that is associated with a series of “function chains” that do specific things, and also (likely) policies that establish self-managed behavior of the stuff underneath the model.
If you link Huawei’s material with other presentations made by the TMF as a body, what you get is the impression that they see services as a series of intent models (which the TMF would say are nested customer- and resource-facing services) that can express SLA-and-lifecycle handling in terms of either policies or function chains. Here’s the relevant quote from the Huawei presentation: “Goal based policy is an important way of specifying the desired network states in systems that are largely autonomic, working in conjunction with standard ECA policy.” Translating, this seems to me to say that service components are modeled as intent models and that policies define the way their SLA is met. While HP doesn’t say as much about the detail, I think based on my analysis of their modeling that they could do this as well.
So what does this mean? First, the TMF does have a program (ZOOM) that addresses the key factors in making a service/network management and operations driver work for NFV. Second, there are demonstrations (Catalysts) roughly equivalent to the NFV ISG’s PoCs that address many of the points needed. Third, ZOOM isn’t fully baked, and so the Catalysts are exploring what it might/should look like rather than what it currently does. Finally, there’s still the question of implementation/evolution.
To my eye, HP and Huawei are both supporting a model of future services that fits the “intent model” structure I’ve blogged about. They’re augmenting the basic notion that an SLA is an attribute of an intent model with the notion that policies (that are perhaps logically part of that SLA) are at least a means of communicating intent downward to influence resource behaviors. In all of this, at least according to Huawei’s presentation, “we simply are following the likely evolution of ZOOM”.
Which means the TMF hasn’t slid across the plate yet, but they may be rounding third (if you care for US baseball analogies). There are three barriers, in my view, to the TMF reaching its goal.
The first barrier is constituency. The TMF is primarily an organization of OSS/BSS types. On the vendor side, it’s arguably even more ossified than the network vendors are. On the buyer/operator side, there’s as much consensus for the view that OSS/BSS systems need to be tossed out and something new created as there is for the view that they need to be modernized. That’s not exactly a cheering crowd.
The second barrier is communication. As a body, the TMF is almost a subculture. They have their own terms, acronyms, issues, sacred cows, heroes, villains, and documents. Most of their good stuff is not available to the public. Because they try to describe the new (like ZOOM) in terms of the old (all their Frameworx stuff) rather than in current industry terms, they can’t communicate easily outside their own subculture, and that means they don’t have good PR. Even within operator organizations, TMF/CIO types often have problems talking with the rest of the company.
The final barrier is containment. The desire to preserve the old, the primary framework of the TMF’s work, leads it to try to limit the impact of new stuff. SDN and NFV can be viewed as an alternative way to implement device functionality. That could be accommodated simply by adding SDN/NFV processes below current device-level OSS/BSS processes—the “virtual device” model I’ve mentioned before. The problem with that is that it encourages vendors to separate SDN/NFV virtual-device realization (which is what the NFV ISG MANO function focuses on) from the orchestration of the service overall.
You can perhaps see this in HP’s presentation charts, and it resolves potential conflicts between what the NFV ISG or the ONF might do for “management” or “operations” and what the TMF might do. It creates two layers of orchestration, and the separation leads to the conclusion that you need to modernize OSS/BSS systems along event-driven or policy lines, and also implement SDN and NFV deployment and management that way. From many, two. Or maybe three, because if there are two levels of orchestration how do these levels then combine?
Modernization of OSS/BSS was one of the goals of the NGOSS Contract and GB942 work I’ve cited many times, work that was the foundation for both my CloudNFV and ExperiaSphere projects. I didn’t see any reference to it in the Catalyst material, and since NGOSS Contract work is explicitly about using data models to steer events to processes, it would seem it should have been seminal. It may be that componentized, event-coupled, OSS/BSS isn’t in the interest of the OSS/BSS vendors.
I think that the TMF has all the pieces of the solution to SDN and NFV’s problems. I think that the real goal of ZOOM was (based on the goals document) and remains a form of fundamental OSS/BSS modernization. Will OSS/BSS vendors and the operator CIOs drive that kind of change? Would it have been easier to orchestrate both OSS/BSS and SDN/NFV with a common element external to both? These questions probably can’t be answered at this point, and we also don’t know how long this process will take, either in the TMF or outside it in the NFV ISG, the OPNFV group, or whatever.
I’m mostly heartened by the TMF Catalysts, because we’re at least getting some field experience at the layer of the problem where the SDN and NFV business case have to live. The next big TMF event is in Europe in the spring, and there we may finally see something broad enough and deep enough to be convincing.