ONAP Says Its Beijing Release Is Market-Ready
ONAP issues its second software release today, Beijing, and that release is focused on making the automation platform more deployable with enhancements aimed at improving usability, manageability, scalability and more practical and commercial aspects. (See ONAP Issues Beijing, Second Software Release.)
While multiple network operators -- AT&T Inc. (NYSE: T), BCE Inc. (Bell Canada) (NYSE/Toronto: BCE), China Mobile Ltd. (NYSE: CHL), China Telecom Corp. Ltd. (NYSE: CHA), Orange (NYSE: FTE), Verizon Communications Inc. (NYSE: VZ) and Vodafone Group plc (NYSE: VOD), to name the prominent players -- are deploying the Open Network Automation Platform (ONAP) software in whole or in part, the biggest challenge to this ambitious open source project has been the public perception that it's a massive effort that is not yet mature enough to be commercially deployed. With the Beijing release, ONAP is tackling that perception head-on.
"There's a lot of great work that has already been done by the carriers globally," says Arpit Joshipura, general manager of networking for the Linux Foundation . "With Beijing, we are bringing these things out in a very simplistic manner in terms of what does it really take to deploy? The team has been extensively focusing on these dimensions for all the 31 projects."
One of the architectural changes to Amsterdam on which Beijing focused is integration on the external northbound application programming interface (API), where ONAP is incorporating work done by TM Forum , and by MEF , as announced earlier this year. Ken Dilbeck, vice president of collaboration R&D at the Forum, says his group has adapted its timelines and ways of working to fit the faster open source pace and is providing updates in code regularly in response to requirements from its members who are also part of ONAP. (See Unknown Document 743855 and TM Forum Brings Open APIs to Linux Partnership.)
"There is an awareness at the Forum that we need to be moving at the pace of industry," Dilbeck says in an interview. "It's a cultural change, with the awareness they are working to a much faster timeline and we need to process things at a different speed. Everything is very pragmatic and practically oriented."
The practical result, according to Joshipura, is that ONAP can now standardize across multi-carrier operations support and business support systems. The ability to work in parallel with other standards development organizations (SDOs) is key to continuing the pace at which ONAP is evolving, he adds.
Heavy Reading Senior Analyst James Crawshaw credits the architecture and practicality advances in Beijing and sees more active participation by a broader base of members with this release and the next one, Casablanca.
"They seem to be making good progress here around architecture [TMF/MEF APIs and support for microservices/Kubernetes] and deployability, lowering the barriers to adoption and increasing the level of automation," he says in an email. "Code commits in 2Q18 still come overwhelmingly from AT&T, Huawei, Amdocs, ZTE and Intel, greater than 75% collectively. But more operators seem to be getting involved in trials. Outside of the ones that have been vocal ONAP supporters [AT&T, China Mobile, China Telecom, Orange, Bell Canada] it seems Verizon and Vodafone are now quite active. And Deutsche Telekom has been submitting uses cases and functional requirements for the next release. At the very least operators should be taking advantage of the free educational resources [see edx.org] available to learn about ONAP even if they can't commit to trialing it yet."
Seven dimensions of deployability
Joshipura references seven dimensions on which Beijing focuses including usability, security, manageability, stability, scalability, performance and resiliency. Beijing includes specific enhancements in each category, such as adding both Kubernetes and HEAT-based platform management, improving both usability processes and documentation/user guides, and adding 72-hour soak testing to validate system behavior under production use for all 31 projects.
All of this is intended to make it easier for ONAP to be used as a platform or consumed as separate modules, Joshipura notes, by tackling issues such as ease of scaling and improved security. The improvements are a combination of code, processes and certification, in addition to both architectural changes and functional additions that are part of Beijing.
"The architecture looks very much like Amsterdam except there are a lot of common functions and common things that we have extracted that cut across all the projects," he says. "So things like modeling, things like integration, things like VNF validation, et cetera."
Incorporating the northbound APIs was one architectural change. The second one deals with ONAP operations management or OOM, which now supports migration to microservices-based deployments on Kubernetes. A third change is around common services, Joshipura says, and involves both the ONAP Optimization Framework (OOF) project which allows for optimization based on policies, and a new project called Music which is focused on multi-site support for global deployments. The fourth change involves harmonization of industry models -- things such as Tosca, Yang and Heat -- so that information modeling, integration and VNF validation is done in a common way.
ONAP members will be meeting in Beijing -- the city -- June 19-22 for the Casablanca Release Developer Forum.
— Carol Wilson, Editor-at-Large, Light Reading