Open source network tools compete with shrinking vendor equipment
Vendor equipment consolidation could limit network operator service automation efforts, but new open source network tools offer options and prevent lock-in.
There was a time when a dozen vendors offered a given piece of service provider network equipment. Vendor consolidation has pared that number to as few as three, and with vendors facing further profit pressure, it's likely the number will fall further.
Vendor equipment consolidation does a lot of things -- both good and bad -- to the service-provider buyer. It also affects network design and deployment -- including service automation and the tools that can make it happen -- and the potential for vendor lock-in, unless operators back open source network tools.
To start with the good, the first effect of network vendor equipment consolidation is a reduction in vendor costs, which is what drives consolidation in the first place. That lets prices fall. Obviously, the price-reduction effect of consolidation can't last forever, which means, eventually, other pressures could make network vendor equipment consolidation a net risk to operators.
The biggest of these pressures is the classic vendor lock-in risk, and consolidation increases that risk significantly. Networks made up of many different kinds of devices, each performing a different role, encourage network vendors to try to increase their own sales success by creating proprietary interaction among their own device types. Service providers like AT&T, with its Domain 2.0 strategy, sought to counter this by dividing network devices into multiple areas and requiring at least three competitors per area. AT&T then limited the number of areas in which a network vendor could respond, limiting the lock-in risk.
This strategy has worked well, up to the software and virtualization age. The problem now is complex systems of devices need software automation to generate operations efficiency and service agility. Efforts to guide competitive vendor development of all the software tools needed for this service lifecycle automation, or even to define a single and complete software architecture for that mission, have proven difficult to bring to a successful conclusion. That has created two consolidation risks.
Need for interoperable or open source network tools
The first and most obvious risk is everyone will create a service lifecycle automation product, but the multiple toolkits won't interoperate. Service providers point to the operational support systems (OSS) and business support systems (BSS), which they say are less open to multivendor interoperability than network devices are.
Software for service lifecycle automation, some fear, would end up like OSS and BSS and create not only a lock-in for the critical service automation piece of the puzzle, but possibly force service providers to buy both network vendor equipment and software from the same source in order to achieve their goals. That would create a far worse risk of lock-in than providers have faced for a generation.
AT&T has responded to the service lifecycle automation lock-in risk by turning its own software -- Enhanced Control, Orchestration, Management and Policy (ECOMP) -- over to the Linux Foundation. In turn, the Linux Foundation is bundling it with the Open-Orchestrator (Open-O) network functions virtualization management and network orchestration software promoted by service providers China Mobile and China Telecom. Together, these create the Open Network Automation Platform. ONAP could create an open source version of service lifecycle automation software that would be available to every service provider. That could force network equipment and software vendors to comply with ONAP interfaces, thereby generating the kind of openness service providers want.
Another initiative that could promote openness is the Open Networking Foundation's intent-based northbound interface. The goal is to create a functional model of network devices or device systems that can be applied to any piece of hardware or any hosted software feature interchangeably.
If ONAP-compatible software automation is paired with intent-modeled network hardware and software, then the network ecosystem is open enough to counter the risks that consolidation creates.
What is unclear is the pace at which this standardization play can develop and whether network vendors will support it. The fusion of ECOMP and Open-O isn't complete, and while ECOMP is being tested by several operators globally, it is far from universally accepted. Vendors could still promote their own approach, and if the open source ONAP is delayed long enough, a proprietary version of service automation software -- or even several incompatible versions -- could still emerge as market winners.
The need for open source network tools for service automation
If ONAP-compatible software automation is paired with intent-modeled network hardware and software, then the network ecosystem is open enough to counter the risks that consolidation creates.
The second risk is no one will create the proper service automation tools at all. This would leave service providers with equipment cost reductions that gradually fade away and without a means of continuing cost reductions through operations efficiency. They would also lack the ability to increase revenues through more market-responsive services. In open conferences, service providers have said they fear their vendors are all looking at their own near-term revenues and are reluctant to jump into a long-term software-automation-driven strategic shift.
Some signs point to the fact that this is already affecting the markets. Network vendors have so far failed to match the proposed scope of ONAP, and while some vendors support ONAP, not all have promised full support and interoperability. If vendors don't supply their own open service automation tools or fall in behind a specific open source network tools approach, then building future networks will depend on integration services.
ONAP, at least, may also be responding to consolidation and accepting its new role. AT&T's venture business is focusing on startups that will build on top of ONAP, and AT&T isn't shy in its aspirations for near-universal adoption. If ONAP can build its reputation as an effective ecosystem, then it can attract support not only from major network vendors, but perhaps from a new startup community that will add value in the service layer and not in the network itself.
New network service ecosystem to emerge
All of these paths seem to lead to more challenges in assembling a new network service ecosystem. Ironically, vendor consolidation seems certain to shift at least some service-provider spending to integration services. What integration services vendor equipment might have bundled into the cost in a proprietary silo will now have to be recovered as professional services. To make things even more complicated, the integration services will increasingly be at the level of software APIs, an area where service providers have relatively little experience even running projects.
In the end, it's likely the forces driving vendor equipment consolidation may be more important to service providers than the consolidation itself. A market is made up of sellers and buyers, and things that affect one will affect both in the end. One thing is certain: Vendor consolidation signals major changes ahead, and open source network tools will gain a footing, or vendor equipment integration may be the phrase of the day.
