Many 0f you like ONAP. ONAP's architecture is game changing. Plus the fact that it is open source and vendor-agnostic is icing on the cake. But if you're worried about commercial support, wait no more. We announced the Aarna.ml ONAP Distribution (ANOD) 3.0 earlier today that comes with commercial support (this is our first version with support). ANOD 3.0 also includes an easy to use installer called Aarna OOM or A-OOM.

ANOD 3.0 is a 100% pure play open source distribution of ONAP Dublin. There are two levels of support—basic that is more suitable for dev/test and premium that is recommended for production environments or situations where more stringent SLAs are required.

On top of the ONAP platform, there are artifacts, apps, and dashboards. These include workflows, directed graphs, policies, analytics apps, collectors etc. This collection of components is offered under the name AarnaStream™ and requires a separate support subscription from the underlying ONAP platform.

In addition to support, ANOD 3.0 also includes an easy to use GUI based ONAP installer. This cuts down 3-4 weeks of effort in installing ONAP to just a few hours. The installer, based on the ONAP Operations Manager (OOM) project, is called A-OOM.

What's next:

• Get more information on ANOD 3.0 or see a demo video (<2 min)
• Join us for a ANOD 3.0 demo webinar on October 23 at 8:30AM Pacific Time
• Sign up for our our upcoming ONAP training in Bangalore (Nov 12-14)

If there is any way we can help you on ONAP—support, training, or custom engineering, please feel free to contact us.

I will be at ONS EU 2019 in Antwerp next week. Here is a quick summary of Aarna activities:

1. We are participating in the Linux Foundation booth to demo the OPNFV Verification Program (OVP)—an open source, community-led compliance and verification program to demonstrate the readiness and availability of commercial NFV products and services, including NFVI and VNFs. It is a joint demo by China Mobile, Huawei, Intel, Vodafone, VoerEir and us. There will be 4 OVP demos in total: NFVI validation, VNF compliance , VNF validation using a Heat VNF, and VNF validation using a TOSCA VNF.

2. We are hosting a conference session titled, "ONAP as a unified MEC-in-NFV Orchestrator" on September 25 at 13:50 in the Gorilla 4 room. Given that in the latest ETSI MEC architecture specification, there is a generic reference architecture and a MEC-in-NFV variant, we would like to discuss the MEC-in-NFV variant and the possibility of ONAP serving as the combined orchestrator (NFVO+MEAO). Also, given the rich functionality of various ONAP controllers, we would like to discuss how ONAP could possibly interface with both external MEPM-V components or alternatively subsume this functionality within ONAP. This is quite similar to how ONAP deals with VNFMs — they can be external or internal. There is no pre-planned agenda, and we would like to have an open discussion on this topic.

Please come by. Alternatively if you want to meet with me to understand our commercial ONAP distro or other services offerings, get in touch with us and we can set up some time.

I am delighted that Aarna is now an official ONAP contributor! We recently contributed to upgrade APP-C to include OpenDaylight Fluorine SR2. We hope to keep growing our contributions to both the ONAP codebase and also to use case blueprints such as Akraino ICN and OPNFV VCO 3.0.

There was an LFN Developer Design Forum (DDF) and Plugfest held in Stockholm in early June. These is a semi-annual event. In the past, the ONAP project had conducted DDFs and OPNFV had conducted Plugfests. This event was the first for all LFN projects. Given the history though, bulk of the activity was around ONAP and OPNFV. Here are 5 key takeaways from the event:

1. OVP: The community made great progress on the OPNFV Verification Program (OVP). Even though the name contains the word OPNFV, the program is broader than that.  OVP started with an NFVI verification program and it now also includes VNF verification for ONAP.
2. ONAP real-world experience: 8 end users (AT&T, Bell Canada, China Mobile, Orange, Swisscom, Telstra, Telecom Italia, and Vodafone) provided concrete  feedback on ONAP requirements. In addition, there was discussion on use case blueprints for 5G, edge computing, residential connectivity (BBS), cloud native network functions, network-as-a-service (CCVPN), and more.
3. ONAP planning: Various ONAP sub-projects and initiatives planned their activities for the next releases, El Alto and Frankfurt. El Alto is mostly expected to be a non-functional release focusing on S3P (scalability, security, stability, and performance) while Frankfurt will be a full blown release with functional and non-functional enhancements.
4. ONAP 3rd party collaboration: The ONAP community discussed how to work more closely with 3rd party standards groups such as ETSI, TM Forum, 3GPP, MEF, Broadband Forum, and others. There were similar discussions on how to collaborate further with 3rd party open source projects such as CNCF.
5. Other projects: OPNFV, OpenDaylight, and FD.io had discussions on their sub-project planning, upcoming releases, and non-functional enhancements such as scalability.

To learn more, read the full report.

Curious to learn more about ONAP? Try it out on Google Cloud or sign up for one of our ONAP trainings!

‍

We've discussed ONAP architectural principles in the past, but I felt it might be good to review them again as I have seen some confusion about the ONAP architecture. The architecture principles of ONAP (as described by the community) are classified into 4 categories:

• Scope: Lifecycle support; resource, vendor, and service agnostic; common information model; strive for standardization; and integrated and standardized catalog
• Business imperatives: Policy driven automation, model driven, self service and user focused, cloud agnostic, backwards compatible
• Implementation approach: microservices, shared services, CI/CD support, integration friendly/standard API, layered software abstractions, platform system data model
• Deployment/resiliency/scalability support: Cloud environment support, scalability, availability & resiliency, security, platform plumbing, lightweight and modular, runtime independence from the internet

‍

Specifically, let's discuss some of the key items from the list that I believe to be especially interest

1. ONAP is a containerized (microservices based) application deployed using Kubernetes (k8s). In this manner, ONAP can be deployed on as few or as many bare metal or virtual machines as required by the performance and availability needs of the user. It can scale to 1 VM for say development purposes, while the official community validation is across 15 VMs. And services do scale horizontally as well, e.g., DCAE can scale horizontally to handle the required telemetry load.
2. ONAP is model driven, and to the extent possible, inputs to ONAP are provided as models. In addition to the usual infrastructure-as-code benefits, a model driven approach reduces the need for programming and allows for changes to be made outside of the ONAP release cycle.
3. ONAP supports CI/CD. Not only is ONAP developed using a CI flow, it also expects VNFs and other vendor software products to be updated all the time—in a CI/CD manner.
4. ONAP is modular. The scope of ONAP requires that there be multiple components and services work together (at the highest level the components are design, orchestration, lifecycle management, inventory, and service assurance/automation). It is very common for users to utilize just a subset of ONAP services. For example, one end user has used just a few projects (Policy, A&AI, VES collector, DMaaP) for a specific use case. Others have done demos with just DCAE+Policy+DMaaP+APP-C while yet others have used just the orchestration+LCM piece leaving out DCAE+Policy completely.

Hopefully this discussion answers the title of my blog—the ONAP Dublin architecture is certainly microservices based and not monolithic. These microservices can be scaled and distributed. In fact, if you take a system such as DCAE, its nodes are HDFS nodes, and the horizontal scalability of HDFS is well known.

Another point of confusion is about the sizing or scalability of ONAP, i.e. that it might only work as 1 monolithic VM. As we saw above, ONAP has no problem being spread across multiple bare metal or virtual machines given that it is a containerized application that uses k8s for its orchestration. An ONAP Dublin deployment has over 200 k8s Pods or microservices. And you could literally distribute these services across 200+ VMs if you so desired (I would not recommend this) and more if you started to scale services.

Curios to learn more about ONAP? Feel free to take one of our ONAP trainings or download the Aarna.ml ONAP Distribution.

‍

We are now proud official silver member of Linux Foundation Networking (see LF press release). Given our ONAP involvement — as a ONAP distro provider along with training and custom engineering, this membership will allow us to engage more deeply with other contributors and the Linux Foundation.

Our highest priority is to further the use case of ONAP orchestrating multi-access edge computing (MEC) applications, something that is already in motion through China Mobile, Intel, and Huawei efforts. A solid support for MEC applications will allow ONAP to branch out to enterprises, which we feel is very important to bring in new potential end users.

Additionally, we are already starting to contribute to APP-C/SDN-C. In the next few months, we will start contributing to additional projects as well.