NFV Automation Standards Picture Remains Murky
Leading telecom operators aren't waiting for orchestration standards before pushing ahead with NFV, but their longer-term goals of automating many basic processes will require some standardization, and it's not yet clear where that happens, Heavy Reading Senior Analyst Roz Roseboro writes in a new report.
In an interview regarding her report released this week, "MANO and the Future of CSP Automation," Roseboro says the industry has now moved beyond proofs of concept that are data center-focused and into actual production, which requires a broader view that encompasses physical elements of the network. After spending considerable time worrying that OpenStack might not work as NFV's Virtualized Infrastructure Manager (VIM), the industry has now accepted that it will and moved on.
"Now that you are trying to get into production, you have to go back to address how you assure it, identify faults, do all the FCAPS stuff," she says. "That wasn't necessarily addressed fully at the beginning and now they are having to work through all those issues."
For the uninitiated, FCAPS is an ISO network management model, and the acronym stands for fault, configuration, accounting, performance, security.
The work on all this is going on in multiple places: The European Telecommunications Standards Institute (ETSI) , where all this originated, is doing work on its own, and there are two open-source groups -- Open Network Automation Platform (ONAP) and Open Source MANO Community (OSM) -- addressing this as well. And then there are traditional standards development organizations.
"One of the big issues is having a common information model -- it is not clear who is going to drive that," Roseboro says. "The TM Forum thinks they should be doing it. If I ask someone from OSM who should do it, they'll say it's ETSI. And the Linux Foundation folks will tell you that ONAP should do it. It is still TBD -- I wouldn’t want to place a bet at this point, but I think whoever gets critical mass first will have the advantage."
An open-source approach may have the upper hand here, because those efforts are based on generating code -- "something concrete," Roseboro says -- and once it's out there and being used, an open-source option can become a standard. But even at that point, every operator will have to do some adaptation of its own, because each one has different OSS and BSS systems.
As CenturyLink Inc. (NYSE: CTL) CTO Aamir Hussain said last week, when admitting his company is considering joining ONAP, that open-source solution only lays the groundwork for what CenturyLink must develop to integrate its existing systems.
Still another approach would be to emulate the cloud giants, which are developing their own approaches to orchestration and automation at massive scale. The complication there, Roseboro notes, is that systems developed for the cloud giants don't take into account the massive legacy operating and billing support systems that every telecom operator has.
The vanguard of network operators in the virtualization space, such as AT&T, Verizon and Telefonica, are definitely not waiting for all the MANO questions to be answered before proceeding. But other operators will wait until they see more standards-based approaches develop, to make sure they have vendor options, interoperability, and cost-effective pricing at scale, she says.
Operators know they need to automate -- that's nothing new, Roseboro notes -- and virtualization will make that easier.
"But if you still have to manually configure everything and manually stitch together all of your services and go into each of these systems to troubleshoot, you're not really gaining a whole lot," she says.
One interesting thing that emerged in her research is that while telecom network operators know they need automation, they are also a little bit scared of it.
"Telco folks are control freaks," she said. "The idea that something is just going to do something for them without their direct knowledge is a scary proposition, and they want to be able to verify this all happened the way they wanted it to. For the boring stuff, it's fine -- get it done once and it's over. But automated service creation and fixing faults and reprovisioning bandwidth and adding capacity based on demand would be very scary for a telco."
That's why, when the current standards issues are worked out, she expects to see telcos starting with something small, with minimal impact from failure, and expand from there.
— Carol Wilson, Editor-at-Large, Light Reading