JNT Visual - Fotolia
Eight months after its inception, the Open Network Automation Platform project released its first code, dubbed Amsterdam. The ONAP architecture is a combination of two former open source projects -- AT&T's Enhanced Control, Orchestration, Management and Policy and the Open-Orchestrator project.
ONAP's November release targets carriers and service providers by creating a network automation platform. It includes two blueprints -- one for Voice over Long Term Evolution and one governing virtual customer premises equipment. Additionally, Amsterdam focuses on automating the service lifecycle management for virtual network functions (VNFs), said Arpit Joshipura, general manager of networking and orchestration at The Linux Foundation, which hosts the ONAP project.
The ONAP architecture includes three main components: design time, run time and the managed environment. Users can package VNFs according to their individual requirements, but Amsterdam also offers a VNF software developer kit (SDK) to incorporate third-party VNFs, Joshipura said.
Once services are live, the code -- a combination of existing Enhanced Control, Orchestration, Management and Policy, or ECOMP, and Open-O with new software -- can manage physical and virtual network functions, hypervisors, operating systems and cloud environments. The ONAP architecture integrates with existing operational and billing support systems through an external API framework.
VNF automation is a key component, Joshipura said.
"The network is constantly collecting data, analytics, events, security, scalability -- all the things relevant to closed-loop automation -- and then it feeds it [the data] back to the service lifecycle management," he said. "If a VNF needs more VMs [virtual machines] or more memory or a change in priority or quality of service, all that is automatically done -- no human touch required."
Because ONAP is a collection of individual open source projects, some industry observers and potential users expressed doubts about how easy it would be to put Amsterdam to use -- particularly since AT&T was originally the main ECOMP contributor. But Joshipura said ONAP reworked the code to reduce the complexity and make Amsterdam usable for the majority of users, not just specific contributors.
"Originally, yes, it was complex because it was a set of two monolithic codes. One was Open-O and the other was ECOMP," he said. "Then, what we did was we decoupled and modularized it and we removed all the open source components. We refactored a lot of code when we added new code."
The result is a modular platform -- not a product, he said -- that has many parts doing several different things. This modularity means carriers and service providers can pick and choose from the Amsterdam code or use the platform as a whole.
ONAP's next release -- Beijing, expected in 2018 -- will focus on support for enterprise workloads, including 5G and internet of things (IoT).
MEF releases 3.0 framework aimed at automation, orchestration
MEF has released a new framework governing how service providers deploy network automation and orchestration.
MEF 3.0 Transformational Global Services Framework is the latest effort by the organization to move beyond its carrier Ethernet roots. MEF is shifting its focus toward creating a foundation that service provider members can use as they move toward cloud-native environments.
MEF 3.0 is developed around four main components: standardized and orchestrated services, open lifecycle service orchestration (LSO) APIs, certification programs and community collaboration.
With the new framework, MEF is defining network services, like wavelength, IP and security, to help service providers move to cloud environments and network automation, according to Pascal Menezes, CTO at MEF, based in Los Angeles.
"A service is defined like a language that everybody can understand, whether it be a subscriber ordering it or a provider implementing it. They all agree on that language," he said. "But how they actually implement it and what technology they use is independent and was never really defined in any specs. It defines SLA objectives, performance objectives and different classes of performances, but it doesn't tell you how to implement."
MEF has previously worked on orchestrating connectivity services, like wavelength and IP, and intends to deliver that work early next year, Menezes said. MEF has started developing SD-WAN orchestration standards, as well, citing its role as a bridge between connectivity layer services and other services, like security as a service and application performance, he added.
These services are automated and orchestrated via MEF LSO APIs. MEF released two LSO APIs earlier this year and will continue to develop more within MEF's LSO reference orchestration framework. The certification programs will correlate with upcoming releases and are subscription-based, he said.
The fourth MEF 3.0 component involves what MEF calls community collaboration. This involves open source contributions, an enterprise advisory council, hackathons and partnerships with other industry groups. MEF and ONAP, for example, announced earlier this year they are working together to standardize automation and orchestration for service provider networks.
In a separate announcement this week, MEF said it plans to combine its efforts to determine how cloud applications connect with networks with work conducted by the International Multimedia Telecommunications Consortium (IMTC) to define application performance. According to Menezes, MEF will integrate existing IMTC work into its new applications committee and will take over any active projects as part of the MEF 3.0 framework.
"IMTC has been focused on real-time media application performance and interoperability. It made a lot of sense to bring that work into MEF," Menezes said.