As the first ONAP training provider that has trained around 60 participants on ONAP (and OPNFV) and created the LF online ONAP/OPNFV courses, we have definitely learned a few lessons!

Here are some observations:

• Covering the entire ONAP project in half-day of lectures is definitely packing in a lot. There is a lot to digest; however, participants seem to be able to keep up. Areas such as VNF onboarding, OSS/BSS interfaces, closed-loop automation seem to generate the most questions.  
• Creating labs was challenging for us. ONAP + OPNFV require more resources that a laptop can provide. To make self-service labs possible for online LF courses, we had to install both these software stacks on one VM in a public cloud. This took multiple man-months of effort. Also, we had to create numerous workarounds for issues with the ONAP Amsterdam OOM release. I'm confident all of this will be a lot simpler with the Beijing release.  
• We initially thought that the vFW demo -- from ONAP+OPNFV deployment to vFW network service deployment could be completed in 0.5 day. We were so wrong! The entire lab end-to-end is more like 1.5 days which would make the overall course a 2 day course instead of 1 (given 1/2 day of training). We had to cut the lab down twice to make everything fit in 1 day. And based on the ONS training experience, we will need to trim the lab a little more.

Being a pioneer around ONAP has been both challenging and fun! If you are interested in ONAP/OPNFV training or professional services, do not hesitate to contact us.

It's Friday, I couldn't resist the urge to try out some alliteration!

Akraino is a brand new Linux Foundation Edge Stack project with the seed code coming from AT&T. The move is very similar to what happened almost exactly an year ago with OpenECOMP (now ONAP), and ONAP has had a very successful first year.

There aren't many details available on Akraino, my guess is more will be made available at the Open Networking Summit later in March'18.

I have no inside knowledge of what Akraino is, but I was fortunate enough to attend a presentation by Kandan & Rodolfo from AT&T at OpenDev 2017 where they presented the various AT&T open source efforts around edge computing. Let me describe what I heard then, since this might be pertinent to Akraino.

While OpenStack and Kubernetes (NFVI/VIM) are available as underlying edge stack technologies, there's nothing available to deploy and manage the lifecycle of these stacks at scale. With tens of thousands of central offices i.e. edge locations, and even more possible through radio tower colocation, on the side of the highway or even at customer premises, manual orchestration of the edge stack is simply not an option.

The challenges laid out by AT&T during OpenDev for an edge stack are:

1. The deployment and lifecycle management needs to be fully automated

2. The automated process needs to support a very large scale -- tens or hundreds of thousand edge stacks if not millions

3. The stack needs to be modular to allow for different sizes/capabilities depending on how constrained the edge environment is

4. The stack needs to support new hardware acceleration technologies ranging from GPU, TPU, NPU, FPGA etc.

5. Finally, the edge stack needs to support integration with ONAP and other related software stacks

Given these requirements, AT&T talked about 6 open source software projects. These are all edge related and have been started by AT&T:

The git repositories are at: OpenStack Helm, Promenade, Shipyard, Drydock, Armada, Deckhand.

If Akraino has anything to do with these initiatives, I think it is a huge move towards the enablement of edge computing and making the edge stack open source (It's hard to imagine a proprietary edge stack with something like this on the horizon). Like you, I'm looking forward to finding out more.

And oh by the way, if you are attending ONS, do sign up for ONAP or OPNFV training courses conducted by my colleagues and me.

‍

Verizon joined ONAP as a platinum member today. This is actually a very big deal. This means that the two of the largest US and two of the largest Chinese communications service providers (CSPs) back ONAP (along with the leading operators from France, UK, India, Turkey and Canada). In the case of AT&T and Verizon, these are two traditional competitors putting their collective wood behind the ONAP arrow.

The diversity, vibrancy and will of a community generally ensures the success of an open source project. Seems like we have all of those ingredients with ONAP.

I have no doubt ONAP will be the default SDN/NFV automation engine. It will also be the default MEC management and orchestration engine. If you are a CSP or a telecommunications vendor, you can't hold off looking at ONAP any more.

Want to learn more? Join the Aarna-Cloudify "An Introduction to ONAP" webinar or request our ONAP onsite training.

I have been talking about ONAP via a blog series (last blog here).  It's perhaps useful to take a break and discuss the latest Amsterdam release. I think this release is important for three reasons:

1. It shows that the mega-merger of ECOMP and Open-O actually works. Perhaps more important that the codebase merger is collaboration between people and that they were able to get a release out, when they said they would. This is a strong confidence building indicator.

2. It proves that the key architectural principles of ONAP such as model drive, cloud native, DevOps, real-time, closed loop automation etc. actually work in real-life. These are new and rather futuristic concepts that help move operators from a break-fix mindset to plan-build one. And with Amsterdam, the future is here.

3. It shows that the release is useful through two concrete use case blueprints: VoLTE and residential vCPE. Of course, you can create any service using ONAP; it's a general purpose platform not restricted to these narrow services, but having these two use cases shows that ONAP can do something useful. It also provides potential users with a concrete step-by-step example of how to extract value from ONAP.

So now we get to the key question:

For operators:

Telecom operators should be thinking about an ONAP POC with the residential vCPE use case. The residential vCPE use case is 100% open source, so there are no vendor dependencies. Doing a POC will expose you to all the architectural concepts of ONAP.

For VNF vendors:

Maybe you don't have a strong enough business case to package your VNF for ONAP yet, but we all know that sooner or later you will have to bite the bullet on this. It's a matter of time. An ONAP POC with the residential vCPE use case can help you understand how ONAP works and how you could package up your VNF for ONAP in the future. You can even start thinking about how you might differentiate your VNF for ONAP.

Looking for help? Feel free to contact us for training,  deployment services and VNF packaging around ONAP.

‍

In the previous ONAP blog from this series, we looked at a high level view of what the new Linux Foundation Open Networking Automation Platform or ONAP project is all about, and what you can do with it. We also looked superficially at the three key architectural principles that, according to me, are Model Driven, Cloud Native and DevOps. In this blog, we will discuss the principle of Model Driven design in more detail.

As the name suggests, ONAP is all about automation. Instead of creating network services and the OAM (operations, administration and management) mechanisms manually, which results in large amounts of wasted effort and different results each time, a model driven approach allows the use of templates or models to quickly assemble network services, OAM recipes and the underlying infrastructure. A model driven approach results in the same outcome every single time! There is a another major benefit -- models do not require programmers, so a CSP does not have to hire an army of programmers to enable this automation.

The diagram below shows an analogy to better explain model driven.

Instead of the manual, custom and non-repeatable design on the left, a model driven approach on the right uses pre-designed and tested components to quickly assemble a design, that is automatically deployed in exactly the same manner each time. Additionally, models are service and vendor agnostic (unless of course they describe the VNF) making re-use even easier.

ONAP supports a model driven approach at three different levels -- 1) standard definition of models across all components of ONAP, 2) building blocks created by using these definitions and 3) a guided design studio to assemble these building blocks into a higher level design.  

Model definitions in ONAP include structural models such as products (created by using one or more network service along with business data e.g. pricing), network services (e.g. VoLTE, vCPE etc.), VNFs (e.g. virtual Firewall), modules (that make up a VNF), virtual function components (or VFCs that make up a module), virtual links (VLs) that provide connectivity, ports etc. Of course new models can be defined, so this list is by no means exhaustive. ONAP also defines management data models such as VNF descriptors, licenses, engineering rules (e.g. only place VNF-a on a machine that supports DPDK) and recipe models such as policies, analytic microservices (e.g. string matching) or workflows (e.g. network service upgrade workflow).

These standard models can be used to create building blocks such as populated product definitions, network services, policies, closed-loop automation recipes, APIs, analytic apps and so on. And finally the guided design tool allows a designer to combine different models to create network services, closed-loop automation and other higher level design artifacts.

In summary, the architectural principles of ONAP are indeed elegant. Depending on who you talk to, he/she might highlight different principles. My top#3 list is Model Driven, Cloud Native and DevOps. In this blog we saw how a model driven approach promotes extreme automation without having to write a single line of code. We will look at cloud native and DevOps in subsequent blogs.

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.

‍

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.