If you are a communications service provider (CSP), you are already grappling with OpenStack, SDN controllers (such as OpenContrail and OpenDaylight), Linux, KVM, Docker and presumably many more open source projects. You are probably thinking, do I really need to deal with ONAP? It’s actually a good question, and the answer is yes, you do need to embrace ONAP — but the timing could vary depending on your situation.
First let’s look at what ONAP is. Then we’ll discuss why it might be important for your organization.
What is ONAP?
The Open Network Automation Platform (ONAP) is a new Linux Foundation project resulting from the merger of AT&T’s open source ECOMP software and the Linux Foundation NFV Management and Orchestration (MANO) software called Open-O which was started by China Mobile, Huawei and others. The ONAP website describes the open source project this way:
ONAP is a comprehensive platform for real-time, policy-driven orchestration and automation of physical and virtual network functions.
ONAP has both strong momentum and a solid base in real world network automation issues. The project has 18 platinum members, of which 7 are operators that support 55 percent of the world’s mobile subscribers. ONAP provides three major functions in an NFV architecture:
- Network service design
- NFV orchestration (NFVO) and VNF management (VNFM)
- FCAPS (fault, configuration, accounting, performance, security)
ONAP functionality and relationship with other software components
To understand this better, let us first look at the steps of NFV transformation.
What is the NFV transformation?
Taking advantage of NFV typically involves three separate phases:
Each phase of the NFV transformation offers different advantages:
|Benefit||Step 1||Step 2||Step 3|
|Increased Revenue||New services||✓||✓||✓|
|Improved customer satisfaction||Self service||✓|
|Reduced CapEx||Industry standard servers||✓||✓||✓|
Each step of the NFV transformation journey offers an incremental set of benefits over the previous step, and which step you need today depends on your requirements.
For example, if all you care about is standardizing on industry standard hardware, then Step 1 is good enough. If you want a multi-tenant infrastructure layer that enables you to decouple the role of service designer from ops, then Step 2 is fine. However, if you want to enjoy all the benefits of NFV, then you need to jump to Step 3.
Needless to say, the organizational complexity around each step increases as you progress, so Step 1 is the easiest and Step 3 the hardest.
No matter which step you choose, by the time 5G and edge computing roll out, you will need to be at Step 3 for self-service, agile services including network slicing.
And that’s why ONAP not a question of ‘if’ but rather ‘when’.
Curious to learn more about what ONAP is and what its constituent projects are? Register for our “ONAP Overview: Navigating its Many Projects” webinar on next Wednesday, November 15, 2017 at 10:00AM Pacific Standard Time.