Why it makes sense to open-source ECOMP
Open source is well established in the IT world, and it’s coming to telecom
From its inception, AT&T’s ECOMP platform for NFV automation has attracted attention because the project has been led by a service provider rather than a vendor or a standardization body. The recent decision to convert ECOMP to an open source project and irrevocably hand the majority of its code to the Linux Foundation has put it back in the spotlight.
Well-established in the IT world, the open source model remains something of an alien concept in telecoms. You could say that its ethos of free licensing, open collaboration and fast-paced development is diametrically opposed to our industry, which is built on proprietary solutions, ring-fenced Intellectual Property and lengthy design cycles.
Yet, as cloud and virtualization technology grows its foothold in telecoms, and service providers become more like their Cloud counterparts, they – and everyone else in the industry – need to review their business models and modus operandi.
All hands on deck for standardization
AT&T realized that ‘cracking’ VNF orchestration and automating lifecycle processes would be crucial to reaching its target of virtualizing 75% of its network by 2020. Its decision to recruit telecom operators and blue chip vendors as founding members of ECOMP established the collaborative direction that would eventually see the project converted to an entirely open-source initiative.
Amdocs was one of the early contributors, and it was clear to us that this approach would ring in fundamental changes to how our industry works.
By involving the global open source developer community and encouraging broader industry involvement in the open source project – from other operators, system integrators and VNF vendors – work can be spread across a much wider group. Sharing the burden across an ecosystem of contributors will result in accelerated development cycles and allow organizations to reduce their individual cost base. This has the potential to move open source ECOMP closer to becoming the de-facto ‘gold standard’ in orchestration. It is already being recognized by service providers like Bell Canada and Orange. I have full confidence that we will see more operators joining and committing resources to developing the code base.
Video courtesy of Light Reading
Another early insight was that it did not make sense to rely on a proprietary solution for an end-to-end MANO (Management, Automation and Network Orchestration) solution, which would have been the traditional approach.
The cost of a developing, maintaining and constantly updating the code for a proprietary solution singlehandedly incurred by any given vendor – would be prohibitive. Vendors would ultimately extend the cost to their customers, and service providers would have to bear the brunt of it.
Another issue is that tweaking VNFs to work with an orchestration platform is a costly and time-intensive undertaking. When operators introduce a VNF into their network this typically involves a lot of changes and alterations to code. This means going back and forth to the vendor, discussing requirements with various teams – from tech support to product management – and initiating functional requests for the vendor’s R&D department to come up with a solution.
This process can easily take several months and tie up multiple teams – equating to a huge loss of time and unnecessary labor costs. Conservative estimates put the overall impact of these iterations at around 35% of the overall project cost. This runs counter to the budget pressures service providers are under, and the fast pace of innovation required to stay competitive.
Establishing greater transparency
By tapping into the open source community, the path from designing to rolling out new services can be streamlined, resulting in dramatic reductions to the operator’s cost base – and materially shorter time-to-market.
With open-source code, vendors can not only pre-configure VNFs, they can also make changes to the orchestrator itself should a technical issue arise during the test phase of a given VNF. This will avoid interminable to-ing and fro-ing between vendors and operators, as well as cutting down on the cost of customization.
Another substantial benefit is that having direct access to the VNF code reduces the operators’ dependence on vendors. This has obvious time and cost implications, and will also transform the operators-vendor’s relationship to become much more collaborative in nature.
More fundamentally, though, I believe that having visibility and full control of the code which powers an operator network is essential if operators are to fulfil their obligations as trustees of critical infrastructure: without this high level of transparency they cannot effectively protect their infrastructure against cyber-attacks and other risks.
Furthermore, it is only within an open source environment that you get a healthy and vibrant community of ‘white hats.’ White hats are ethical hackers who constantly review and test the code of open source infrastructure to fix vulnerabilities and improve the resiliency of the code. This is essential for protecting an attack-prone code base effectively.