Network operators have accepted open source software. Or, sort of accepted. I don’t want to minimize the fact that operators have indeed made the culture shift necessary to consider the adoption of open-source software, but that’s Step One. There are other steps to be taken, and you can see some of the early attempts at those other steps emerging now.
The decisive driver for Step One here seems to have been the fact that cost reduction needs were far outpacing any possible, credible, path to a software-driven revolution. Operators see a much higher probability that they’ll adopt open hardware models like that of the Open Compute Project. If more and more of the data center iron is an open commodity, how many vendors who are denied the big hardware revenues will then jump out to address software needs? Open source, like it or not, may be the only option.
No operator is naïve enough to think that they can just run out into the marketplace and say “InstallOpenSourceBusiness” and have it happen. There are literally millions of open-source packages, and even narrowing the field to the possible packages that operators could adopt probably wouldn’t cut the number below a million. Operators are used to buying solutions to problems, usually specific problems and not huge ones like “Make Me Profitable”, so one of the issues that has been facing operators is finding the components to their solution suites. Hopefully from a single provider, but certainly at least a set of open-source tools that combine properly.
All of the operators I talked with in the last two years agree on two things. First, they need to transform their business to be leaner and meaner and to open the opportunity for new revenues. Second, achieving the first goal will surely mean becoming more software-centric rather than device-centric in their planning. That’s not easy, and it’s only Step Two.
I had a nice talk with an operator a couple months ago, and they indicated that their planners had divided their technology processes into an operations layer, a service feature layer, and a virtual infrastructure layer. The first focused on OSS/BSS modernization, the second on adding software instances of features to the current appliances/devices in use, and the last on the platform used to host and connect those software features.
In the first area, this operator said that while there were in theory open-source tools for OSS/BSS, they did not believe these tools could possibly do their job, or that transforming to use them could be managed without significant disruption. That means that they have to confront a stark choice of either discarding the traditional OSS/BSS model completely and building up operations features by area, or staying with (likely their current) proprietary OSS/BSS strategy.
In the second area, which is the software feature-building process, this operator confesses that their current focus in NFV has been entirely on proprietary virtual functions. They offered two reasons for that. First, many on the marketing side told the operators that picking virtual functions from “familiar” vendors would grease the sales skids on NFV service offerings. Second, everyone they found offering virtual functions were offering only proprietary ones. The argument was that there was no unified approach to creating open-source virtual functions.
The final area has been the most perplexing for this particular operator. They had envisioned, when they started, that both SDN and NFV would create virtual devices through a process of feature lifecycle management that lived within the third, infrastructure or platform, area. Early on, this operator felt that cloud tools like OpenStack and some DevOps solution would build this virtual device, but they accepted quickly that management and orchestration processes would also be needed. That’s because OpenStack doesn’t do everything operators need.
To make matters worse in this last area, this operator realized that by staying with legacy OSS/BSS systems, they couldn’t do much to ensure that management of these new services would be possible within the OSS/BSS. That requirement had to be added elsewhere, and the only place that seemed to fit was that third area of infrastructure or platform. What this has done is to concentrate a lot of change in a single space, while leaving the issues of the other two largely unresolved, especially with regard to open source.
There are really three layers of “infrastructure”. At the bottom is the physical resources and cloud deployment stuff, including OpenStack, SDN control, and legacy device management. In the middle are the things that drive deployment below, which would be DevOps and orchestration tools, and at the top are the mystical orchestration processes that create the virtual devices that have to be presented upward.
OpenStack has issues, especially in terms of networking, even for cloud computing. While there are initiatives to harden it for carrier NFV use, these are aimed more at the deployment side than at broader concerns of performance and scalability limits, or at network constraints. All of these could be resolved outside OpenStack by the next layer up, and probably should be. OpenNFV seems likely to harmonize this layer a bit, but its role in organizing the next one up is unclear and so is how it would treat legacy elements.
In that next layer, we have current DevOps technology that could control deployment, but today’s DevOps isn’t rich in network configuration and control features. NFV has at least two MANO projects underway. Open-Source MANO (OSM) seems to me to be aimed at the limited mission of deploying virtual functions and service chains. OPEN-O also wants to control legacy elements and orchestrate higher processes. Neither of them are fully developed at this point.
In the top, final, layer, the only specific contribution we have is OPEN-O, but I think you could argue that whatever happens here would probably be based on a service modeling architecture. Some like TOSCA, which is in my view very generalized and very suitable. There is a basic open-source TOSCA implementation, and there’s been some university work building service deployment based on it and on the Linked USDL XML variant.
There is nothing I know of underway that suitably links the management chains through all of this, allowing for higher-level elements to control what happens below and allowing lower-level elements to pass status upward for action. There is also no accepted architecture to tie this all together.
You can see how “open source” is challenged in Step Two, and we’ve not even gotten to the last step, where we can actually field an integrated suite of software elements. We’ve also not addressed the question of how virtual functions could be authored in open source without them all becoming what one operator has characterized as “snowflakes”, every one unique and demanding custom integration.
Operators like AT&T and Verizon are trying to create models to address the whole next-gen ecosystem, but even they are risking falling into the same trap that has hurt the ETSI NFV efforts and the ONF’s SDN. In the name of simplification and acceleration, and in the name of showing results quickly to sustain interest, they make assumptions without following the tried-and-true top-down modeling from goals to logic. I’m hopeful that the operators can avoid this trap, but it’s not a done deal yet.
Still, it’s these operator architectures that will likely carry the open-source banner as far forward as it gets. Other open-source SDN and NFV elements will be relevant to the extent they can map into one or both of these carrier models. The reason for their primacy is simple; they represent the only real ecosystem definitions available. All of the issues I’ve noted above will have to be addressed within these architectures, and so they’ll be a proving-ground for whether any open-source solution can make a complete business case.