Network Functions Virtualization or NFV is a major transformation of telecom and cable operator networks where network services traditionally constructed with physical boxes and manual configuration/monitoring/management are changing to virtualized network functions (VNFs) with automated configuration/monitoring/management. Sounds like the holy grail, right? So why hasn't this happened in a broad sense?
I think there have been three major barriers:
1. Dataplane performance
2. Lack of cloud-optimized/native VNFs
3. Lack of network automation
Points 1 & 2 are outside the scope of this blog (maybe we can revisit some other day). Instead we will cover point 3.
While there have been many proprietary management and orchestration (MANO) solutions, they have been incomplete and lock customers into their software. Also, given the proprietary nature, these solutions have also not had the force of standardization (for VNFs, analytic applications etc.) that comes with a broad open source solution.
Given these deficiencies, AT&T developed an in-house network automation solution called ECOMP. In parallel China Mobile was working with vendors such as Huawei and others on an open source MANO project called Open-O. Fast forward, AT&T open sourced ECOMP and merged with Open-O to form a new Linux Foundation project called the Open Network Automation Platform or ONAP.
According to the ONAP website:
ONAP is a comprehensive platform for real-time, policy-driven orchestration and automation of physical and virtual network functions. 100% open source, part of Linux Foundation.
ONAP has strong momentum with 18 platinum members, out of which 7 are operators.
We still haven't answered what ONAP is: ONAP is a superset of ETSI MANO. At a high level, ETSI MANO's scope includes:
- NFV orchestration: Network service (NS) onboarding, lifecycle management, performance management, fault management and VNF forwarding graph management
- VNF management: VNF onboarding, lifecycle management, performance management, fault management and software image management
- Other: Security, VIM (virtualized infrastructure manager aka cloud software)/SDN controller
ONAP does everything required by the above list, but goes beyond by including:
- Unified design framework: The framework is used to onboard VNFs, design network services and recipes. More on recipes later.
- FCAPS: Fault, configuration, accounting, performance, security functionality.
The below figure shows the scope of ONAP and the other systems it interacts with i.e. OSS/BSS/big data applications, NFVI/VIM and vendor-provided VNFs.
Providing the design framework and FCAPS goes a long way towards closing the gaps present in current MANO systems.
Switching gears, ONAP uses three (it's actually more, this is my view on the top 3) relatively modern architectural principles:
- Model driven
- Cloud native
- DevOps
In the next blog, we will look at each of these architectural principles.
Until then:
Sign up for our 1/2 day ONAP100 in-person training course (offered jointly with Cloudify) in Santa Clara on November-10, 2017. This course will give you a complete picture of what ONAP is, its architecture and 29 constituent projects in the upcoming Amsterdam release. There's early-bird discounts and special discounts for CORD/TIP conference attendees.
If you are unable to make the class, you can also attend the "ONAP Overview: Navigating its Many Projects" webinar (jointly with Mirantis) scheduled for November-15, 2017.
