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.

The LFN DDF held from June 11-14 in Stockholm was a very pleasant experience! The weather was wonderful, Stockholm is beautiful, and it was bright & sunny all the time (I literally mean all the time, I didn't see darkness for a week). We had 4 presentations on the following ONAP related topics:

• FlexRAN onboarding to ONAP: Virtual Radio Area Network (vRAN) is a critical piece for upcoming 5G networks. In this joint presentation/demo with Intel, we showed how to build the FlexRAN (an open source vRAN approximation VNF from Intel), onboard it onto ONAP, and then deploy it onto OpenStack. Once the service was deployed, the FlexRAN service performs basic operations in a simulated environment.
• ONAP OOM GUI based installer: Remember how during the early days OpenStack installation was super difficult and a number of vendors made it easier through a GUI based installer? We are doing the same with ONAP. We showed a demo of our GUI based installer, built on top of OOM, that can install ONAP with a single click using model driven inputs.
• 4th ETSI NFV Plugtests Summary & Learnings for ONAP:  Here we provided a brief description of the ONAP interop activities at the 4th ETSI NFV Plugtests held from June 3-7, 2019. We also covered our learnings. See related blog where we talk about our Plugtests experience.
• ONAP COP Exam Review: In this session, we reviewed the status of the upcoming Certified ONAP Professional exam, discussed the challenges faced, and invited community members to help with specific questions/API documentation and to be alpha/beta testers

Presentations and recorded demos are available here. Wanting to try out ONAP? Consider our Aarna.ml ONAP Distribution that can be deployed on GCP in under a half day.

ETSI conducts NFV Plugtests where MANO, VNF, NFVI/VIM (i.e. Cloud), and other NFV vendors come together to perform interoperability testing. We were fortunate enough to participate in the 4th ETSI Plugtests as a MANO vendor with the goal of testing our Aarna.ml ONAP Distribution (ANOD) with VNF and NFVI/VIM (OpenStack) vendors. Rajendra Mishra and I (Sandeep Sharma) attended the event in person.

ETSI was a wonderful host. The participants were welcomed with an ETSI T-shirt and other goodies. A dinner was hosted by ETSI for all the participants at a beach side restaurant in Antibes, where we got to know some of the other participants better. And of course there were drinks and some great tasting food!

Before going to the event, we were involved in the pre-testing phase. The weekly calls that were organised by ETSI for the preparation of the event were really helpful. As a first time participant, we had a smooth preparation process. Getting involved in pre-testing with a cloud vendor and a VNF vendor gave us a great head start. The private HIVE network used for the Plugtests, played a key role in the pre-testing phase. Additionally, before the start of the event, every vendor was asked to fill up a form specifying the test cases they were going to execute during the event. This data collected before hand saved a lot of time which would otherwise have been wasted in planning test sessions during the event.

At the event, test sessions were organized such that each of the vendors from MANO, Cloud, and VNF categories could participate in single-vendor Network Service (NS) and Multi-vendor NS test execution. We participated in single-vendor NS testing with 5 VNF vendors and 2 VIM (OpenStack) providers. We also were able to create a multi-vendor NS which involved 2 VNF vendors and 1 VIM vendor. It was a great learning experience where we worked with multiple vendors and understood their product/service. We can leverage from these learnings and add value to the ONAP MANO solution that we provide. Some things worked very well for us and, of course, there were test cases which we could not execute successfully.  The failed test cases taught us the shortcomings of our solution that we already have started to address.

In general, this was a very positive experience. Our initial trepidation as a first time attendee was without merit. We would highly recommend other NFV vendors to attend. The one learning we can share is to invest in pre-testing. Having spent time in this activity made our experience at the Plugtests that much smoother. The other observation is that building working VNF Descriptors on the fly is challenging. Having the full week for a couple of trial-and-error rounds to reach a working model was very helpful.