JNT Visual - Fotolia
What is ONAP, and how does it tie into NFV architecture?
Network expert Lee Doyle looks at ONAP, its role in NFV architecture and its progress in becoming the standard platform for NFV management and orchestration.
Open Network Automation Platform is the leading open source option for network functions virtualization management, orchestration and automation. But before it can effectively influence NFV architecture, ONAP will need to streamline its code base and improve its production readiness. In the long term, ONAP is well-positioned to help service providers and operators deploy NFV at scale and integrate virtual applications as they modernize their back-office systems.
ONAP is a Linux Foundation community open source project that promotes standardization with NFV management and orchestration (MANO). It is currently working to merge 8 million lines of code from various contributions, including AT&T's Enhanced Control, Orchestration, Management and Policy (ECOMP) and the Open-Orchestrator (Open-O) project. ONAP expects to release its third version of software in late 2018.
The goal of ONAP is to provide the capabilities needed for orchestration and full lifecycle management of NFV deployments. ONAP facilitates service providers' ability to deploy virtual network functions (VNFs) in an automated manner, and its architecture consists of a number of modular components -- or software subsystems -- that service providers can deploy in a flexible manner to meet specific requirements.
Status of MANO for NFV
This year, NFV deployments are moving beyond single-function network virtualization to broad-scale NFV architecture. These complex deployments require multivendor interoperability, performance at scale and sophisticated orchestration. The immaturity of MANO options continues to hinder these more complex NFV implementations.
Service providers are still working on their plans for their NFV architectures and are considering many MANO options -- both open source and vendor-supplied. They also must integrate virtual functions with modernized operations and business support systems (OSS/BSS).
ONAP modules and use cases
ONAP has a large code base, with many different modules that can be deployed for various use cases. No service provider is likely to implement all, or even a majority, of the code base directly. Service providers will have to modify the ONAP modules to fit their individual NFV infrastructures and back-office systems. ONAP modules include the following:
- Service Design and Creation
- Master Service Orchestrator
- SDN controller
- NFV orchestration
- Active and Available Inventory
- Data Collection, Analytics and Events
- Policy and Security Framework
ONAP use cases are quite varied, including Voice over Long Term Evolution, virtual customer premises equipment, VNF lifecycle management, distributed firewalls, multi-tenancy, network management, analytics and elements of 5G.
ONAP evolution and maturity
ONAP has a huge code base, with overlapping elements as a result of the ECOMP and Open-O combination. The initial releases are focused on rationalizing the code base and making it operationally efficient, reliable and secure, with high performance.
Another key goal for the ONAP community is to provide clear and comprehensive documentation. ONAP overlaps with many other standards-based MANO options, and the Linux Foundation hopes to increase interaction among its often competing organizations. Many service providers will combine ONAP architecture with OpenDaylight, OpenStack and Open Platform for NFV (OPNFV) for comprehensive open source NFV architecture.
Service provider and supplier support
ONAP has broad support from multiple service providers. AT&T and China Mobile have provided much of the initial code base for the project. Bell Canada implemented ONAP modular components to automate its data center tenant network provisioning. Other service providers supporting ONAP include Verizon, Vodafone, Orange, Colt, Reliance Communications, China Telecom, China Unicom and Comcast.
A number of suppliers are part of the ONAP project and have plans to commercially support ONAP implementation through software releases, professional services and support services. Below are a couple examples:
Amdocs. Amdocs, an OSS/BSS provider, has been involved with ECOMP for many years, given its custom work for AT&T. In 2017, Amdocs announced an ECOMP-based offering designed to assist network operators in their virtualization efforts. Its offerings include a portfolio of modules and related professional services. Amdocs assisted Bell Canada with its ONAP implementation.
Red Hat. Red Hat is a contributor to many of the upstream open source projects that make up ONAP -- OpenDaylight, Kubernetes, OPNFV and Linux, for example. Red Hat's focus is on architectural evolution and the integration of ONAP elements with open platforms -- like OpenStack, OpenShift, Ansible and JBoss -- that enable service providers to deliver innovative new applications and network services.
Other significant suppliers heavily involved in ONAP include Nokia, Ericsson, Ciena, Intel, Microsoft, Tech Mahindra, VMware, Huawei, ZTE and IBM.
The final analysis
ONAP's goal is to become the NFV MANO standard, similar to OpenStack's influence in cloud computing. ONAP's maturation will take many years, and most service providers will need to continue to rely on vendor-specific NFV MANO options in the short term.
Service providers should architect a comprehensive vision for network virtualization, but remain flexible to adjust their infrastructure due to the fluidity of MANO technology. ONAP will help service providers operationalize multivendor NFV deployments and provide for service assurance. Longer term, ONAP will be a part of service providers' NFV architecture and plans to modernize their back-office systems.