I am always trying to explore issues that could impact network transformation, especially relating to adopting NFV. NFV offers a potentially radical shift in capex and architecture, after all. I had a couple emails in response to some of my prior blogs that have stimulated me to think of the problem from a different angle. What’s the biggest issue for operators? According to them, it’s “openness”. What are the barriers to achieving that? That’s a hard topic to survey because not everyone has a useful response, so I’ve gathered some insight from what I call the “literati”, people who are unusually insightful about the technical issues of transformation.
The literati aren’t C-level executives or even VPs and so they don’t directly set policy, but they are a group who have convinced me that they’ve looked long and hard at the technical issues and business challenges of NFV. Their view may not be decisive, but it’s certainly informed.
According to the literati, the issues of orchestration and management are important but also have demonstrated solutions. The number of fully operational, productized, solutions ranges from five to eight depending on who you talk with, but the point is that these people believe that we have already solved the problems there, we just need to apply what we have effectively. That’s not true in other areas, though. The literati think we’ve focused so much on “orchestration” we’ve forgotten to make things orchestrable.
NFV is an interplay of three as-a-service capabilities, according to the literati. One is hosting as a service to deploy virtual functions, one is connection as a service to build the inter-function connectivity and then tie everything to network endpoints for delivery, and one is function as a service which relates to implementations of network functions with virtual network functions (VNFs). The common problem with these things is that we don’t base them on a master functional model for each service/function, so let’s take the three elements in the order I introduced them to see how that could be done.
All hosting solutions, no matter what the hardware platform is, or hypervisor, or whether we’re VMs or containers, should be represented as a single abstract HaaS model. The goal of this model is to provide a point of convergence between diverse implementations of hosting from below and the composition of hosting into orchestrable service models above. That creates an open point where different technologies and implementations can be combined, a kind of a buffer zone. According to the literati, we should be able to define a service in terms of virtual functions and then, in essence, say “DEPLOY!” and have the orchestration of the deployment and lifecycle management then harmonize to a single model no matter what actual infrastructure gets selected.
Connection-as-a-service, or NaaS if you prefer, is similar. The goal has to be to present a single NaaS abstraction that gets instantiated on whatever happens to be there. This is particularly important for network connectivity services because we’re going to be dealing with infrastructure that evolves at some uncontrollable and probably highly variable pace, and we don’t want service definitions to have to reflect the continuous state of transition. One abstraction fits all.
The common issue that these two requirements address is that of “brittleness”. Service definitions, however you actually model them in structure/language terms, have to describe the transition from an order to a deployment to the operational state, and other lifecycle phases that then are involved with maintaining that state. The service-level stuff, if it has to reference specific deployment and connection technology, would have to be changed whenever that technology changed, and if new technologies like SDN and NFV were deployed randomly across infrastructure as they matured, it’s possible that every service definition would have to be multifaceted to reflect how the deployment/management rules would change depending on where the service was offered.
The as-a-service goal says that if you have an abstraction to represent hosting or connection, you can require that vendors who supply equipment supply the necessary software (a “Virtual Infrastructure Manager” for example, in ETSI ISG terms) to rationalize their products to the abstractions of the as-a-service elements their stuff is intended to support. Now services are insulated from changes in resources.
The literati say that this approach could be inferred from the ETSI material but it’s not clearly mandated, nor are the necessary abstractions defined. That means that any higher-level orchestration process and model would have to be customized to resources, which is not a very “open” situation.
On the VNF side we have a similar problem with a different manifestation. Everyone hears, or reads, constantly about the problem of VNF onboarding, meaning the process of taking software and making it into a virtual function that NFV orchestration and management can deploy and sustain. The difficulty, says the literati, is that the goal is undefined in a technical sense. If we have two implementations of a “firewall” function, we can almost be sure that each will have a different onboarding requirement. Thus, even if we have multiple products, we don’t have an open market opportunity to use them.
What my contacts say should have been done, and still could be done, is that virtual functions should be divided into function classes, like “Firewall”, and each class should then have an associated abstraction—a model. The onboarding process would then begin by having the associated software vendor (or somebody) harmonize the software with the relevant function class model. Once that is done, then any service models that reference that function class would deploy the set of deployment instructions/steps that the model decomposed to—no matter what software was actually used.
The problem here is that while we have a software element in NFV that is at least loosely associated with this abstract-to-real translation (though it lacks the rigorous model definitions needed and a full lifecycle management feature set built into the abstraction) we have nothing like that on the VNF side. The closest thing we have is the notion of the specialized VNF Manager (VNFM), but while this component could in theory be tasked with making all VNFs of a function class look the same to the rest of NFV software, it isn’t tasked that way now.
There are similarities between the view of the literati and my own, but they’re not completely congruent. I favor a single modeling language and orchestration approach from the top to the bottom, and the literati believe that there’s nothing whatsoever wrong with having different models and orchestration at the service layer and to decompose the abstractions I’ve been talking about. They also tend to put service modeling up in the OSS/BSS and the model decomposition outside/below it, where I tend to integrate both OSS/BSS and network operations into a common model set. But even in these areas, I think I’ve indicated that I can see the case for the other approach.
One point the literati and I agree on is that orchestration and software automation of service processes is the fundamental goal here, not infrastructure change. Most of them don’t believe that servers and hosting will account for more than about 25% of infrastructure spending even in the long run. They believe that if opex could be improved through automation, some of the spending pressure (that for example resulted in a Cisco downgrade on Wall Street) would be relieved. SDN and NFV, they say, aren’t responsible for less spending—the profit compression of the converging cost/price per bit curve is doing that. The literati think that the as-a-service abstraction of connection resources would let operators gain cost management benefits without massive changes in infrastructure, but it would then lead in those changes where they make sense.
It seems to me that no matter who I talk with in network operator organizations, they end up at the same place but by taking different routes. I guess I think that I’ve done that too. The point, though, is that there is a profit issue to be addressed that is suppressing network spending and shifting power to price leaders like Huawei. Everyone seems to think that service automation is the solution, but they’re all seeing the specific path to achieving it in a different light. Perhaps it’s the responsibility of vendors here to create some momentum.