Creating xNFs (i.e. VNF, CNF, or PNF) is complex. Not only do xNF vendors have to meet functional requirements, but they also have to think about performance, stability, scalability, security, resilience, manageability, usability, cloud native principles, and more. To add to this complexity, xNFs need to interoperate with MANO software (e.g. ONAP; as a clarification ONAP does a lot more than what’s defined by ETSI MANO) and the NFV infrastructure such as OpenStack or Kubernetes. Thus far, the task of onboarding xNFs to MANO and NFVI software has been a fragmented activity repeated by every operator and oftentimes by vendors.

Clearly, there aren’t enough resources in the industry to do this N x N testing. The problem is further aggravated by CI/CD where products keep getting updated more frequently than before. What if there were onboarding specifications and an industry wide interop program? Fortunately, there is such a program! It’s called the OPNFV Verification Program (OVP) and it is available through the Linux Foundation. The program has different components, and the one that I am going to talk about is the VNF Verification Program. This program consists of static tests that check the VNF package and descriptor against the fairly detailed VNF requirements documented by the ONAP project followed by functional validation tests against an actual ONAP environment. VNFs that successfully pass these tests receive an OVP badge.

In may cases, we find that xNF vendors prefer to outsource ONAP related work. For this reason, we (Aarna) have helped several xNF vendors with ONAP onboarding and interoperability testing. We also help vendors pass the OVP test suite and obtain the VNF Verified badge. In fact, we recently worked with Affirmed Networks to ensure their MCC Platform passed OVP tests and successfully obtained the OVP badge. Affirmed, now part of Microsoft, is redefining the future of mobile networks, with over 100 production customers implementing their virtual EPC solutions, and now, with the recent introduction of UnityCloud, leading the industry in cloud native 5GC innovation. As only the second vendor to receive this OVP badge, Affirmed continues to demonstrate their support of open and standards based solutions, such as OPNFV and ONAP, to ensure that customers have a choice when planning for AnyG environment deployments.

‍

To simplify the experience even more, we at Aarna have introduced a new product — OVP-in-a-Box. With OVP-in-a-Box, the xNF vendor does not even need to install ONAP on-site. We deploy an instance of ONAP in the cloud and provide guidance to run through OVP tests. Of course, we can always deploy the ONAP instance on-prem and/or take over the entire interop effort in the form of a turnkey service.

Find out more about Affirmed Networks products on their website. Find out more about the Aarna.ml OVP-in-a-Box offering here. If you need more background on these topics, download our VNF Onboarding for ONAP whitepaper.

We (Aarna.ml) are deeply involved with the OPNFV 5G Cloud Native Network demo that showcases a subset of ONAP optimized for cloud-native workloads orchestrating Altran’s 5GC onto RedHat Open Shift. Feel free to read my prior blog on this topic and to view the webinar recording.

I’m thrilled to report that the demo was chosen as a Light Reading Leading Lights Awards 2020 finalist. We are in the “Most Innovative 5G Strategy”.

There are two ways to approach cloud-native. One is cloud-native-only-in-name. In this approach, you would keep doing everything as you used to and simply replace OpenStack APIs with Kubernetes APIs. Numerous multicloud solutions take this approach. The second approach is to be fully immersed in the Kubernetes and CNCF ecosystem. This means working with Helm, Operators, Custom Resources, Istio (or some other service mesh), Prometheus, FluentD, Jaeger, Argo, Knative, and more. It’s about fully embracing the entire CNCF/cloud-native mindset.

Our demo takes this second approach. And that’s why I’m so glad that Light Reading gave the demo the recognition it deserves. Another feature of this project is that it is open. This means anybody can join the project, can contribute, and can learn how to replicate the demo in their own environment. Join us! And if you have any questions about what subset of ONAP we are using to work this magic, contact us.

‍

The 6th release of ONAP, Frankfurt, got released today. Four things jump out at me:

• Greater commercial activity
• Increased stability/security
• Comprehensive 5G support
• Expanded Kubernetes (K8s) cloud support

Greater Commercial Activity

The biggest danger for an early stage open source project is whether it reaches escape velocity before the novelty wears off. For ONAP, this has frankly been something I have been worried about the most. The current release has been quite encouraging on this front. This table shows the commercial activity around all or a subset of ONAP projects:

Customers in production/ pre-production7Customers in PoC/Pilot7Customers Contributing5Vendors with a Pure-Play Product3 (including Aarna)Vendors Using Parts of ONAP for a Product7Vendors Providing ONAP Services7

Are we at escape velocity with ONAP? You tell me :).

A related point, Bell’s use of ONAP has thus far been shrouded in mystery. As of today this has changed. Now you can now find out exactly what Bell is using ONAP for, how they put it into production, and what value they are getting in this recent customer case study by LF. More in perhaps a subsequent blog.

Increased Stability/Security

The Orange OPNFV crew took over the ONAP Integration project. They have years of deep experience on CI, automated testing, test tooling, and more. This experience has directly benefited ONAP. ONAP now has something called patch gating, where every path submission triggers an ONAP deployment followed by a set of automated tests. This increases the velocity of the project as people are not second guessing each other’s contributions. And it clearly increases stability. There are numerous other security enhancements also. Net-net the confidence you should have in putting ONAP into production continues to go up.

Comprehensive 5G Support

With support for full 5G orchestration, end-to-end slicing, Self Organizing Network (SON) enhancements, Fault Management/Performance Management (FM/PM) collection, close cooperation with 3GPP and the O-RAN Alliance Software Community, Configuration Management (CM) over NETCONF/RESTCONF/REST, a Configuration & Persistency service, and robust PNF support, is there a reason to not use ONAP for 5G?

Expanded Cloud Native Support

As a company we think 5G and edge will exclusively be Kubernetes based (you can still have a few VMs supported via technologies such as Kubevirt and Virtlet). For this reason, I’m super excited to see the various enhancements in the K8s plugin of the MultiCloud project that make it easier to register multiple K8s cloud, define composite applications (built using CNFs and Cloud Native Applications or CNAs) that span clouds, and orchestrate these composite applications with a single click based on intent. Orchestration, day 0 configuration, networking aspects are all taken care of. Then for ongoing lifecycle management and day 1, 2 configuration, we can cut over to existing ONAP controllers and CDS. For slicing, we can use SO+OOF+UUI and the new slicing GUI/models/workflows.

You are probably getting a sense for our roadmap — we are furiously working on ANOD 5.0 that will be our first cloud native 5G/edge orchestration, lifecycle management, and automation product. We will also build a network slice manager on top.

In the meantime:

• End users can try out Aarna.ml ONAP Distribution (ANOD) 4.0 based on the previous El Alto release. You can use it to start your disaggregated open source cloud native 5G journey. In fact, we are a part of the 5G Cloud Native Demo where we used ONAP to onboard a cloud native 5GC and orchestrate it onto a Kubernetes cloud. See webinar recording here.
• xNF vendors can try interop testing with our OVP-in-a-Box offering. Oftentimes, we find that it’s too much friction for a xNF vendor to install ONAP in-house to simply try out their product with ONAP. For such organizations, we have a SaaS offering of ONAP on GCP. It’s a hassle-free way to try out ONAP. If things go well, you can always bring that instance in-house.
• You can also take our ONAP training. With COVID, these are all virtual. But we’ve been working hard to ensure that the learning outcomes are the same as before. Contact us if you want to take advantage of ONAP training. We have a 15% discount if you purchase before the quarter end or June 30th.

For more information on ONAP Frankfurt, check out the official page or the “What’s New in ONAP Frankfurt” webinar (I’m a panelist). Anything else on your mind? Feel free to contact us.

‍

Aarna.ml ONAP Distribution 4.0 and OVP-in-a-Box.

We announced two new products this week. The first is Aarna.ml ONAP Distribution (or ANOD) 4.0, a commercial distribution of the ONAP El Alto release. If you need more background on ONAP El Alto, view our slides from the "What's New in ONAP El Alto" webinar. In a nutshell, ONAP El Alto is a non-functional release with significant work done on security and stability. Our ONAP distribution provides three value-adds:

• Aarna OOM, a value-add version of the community ONAP Operations Manager (OOM) includes automation via Ansible scripts and a simple GUI
• Commercial support at two levels: 8x5 or 24x7
• 100% pure play open source, so that you never have to worry about vendor lock in

Unlike previous releases, we waited to deploy ANOD 4.0 with real paying customers before making it generally available. All three initial customers are happy with the results so far. One of them is John Hopkins University Applied Physics Lab that is doing research on 5G. More on that collaboration in a future blog. See the product page for more details.

________________________________________________________________________________________________________________________________________________________________________________

We also announced another product called OVP-in-a-Box. This is a hosted (or a SaaS) version of ONAP meant to help xNF vendors establish interop with ONAP.

A bit of background first. The Linux Foundation has created an interop program called the OPNFV Verification Program or OVP that gives out badges to products that pass the program's compliance and validation tests. There are two versions of OVP — NFVI and VNF. Here we are talking about the VNF OVP program which is used to establish interop with ONAP.

The issue with OVP is that xNF (xNF signifies VNF, PNF, or CNF) vendors need to have a running instance of ONAP for OVP testing. We have found that many xNF vendors do not have the internal knowledge or skills to deploy ONAP, Moreover, even if they got deployment help from someone like us, they initially want to try out ONAP without actually installing it in-house. For these customers, our OVP-in-a-Box offering will reduce the friction of trying out ONAP by providing xNF vendors:

• A running instance of ONAP on Google Cloud
• Training and support for running OVP tests

If you are interested in getting a demo or trying out either of these products, feel free to contact us!

I'm a presenter for a Linux Foundation webinar next week on the topic of "Integrating ONAP with a 5G Cloud Native Network" on May 19, 2020.

First some history — multiple members of the OPNFV community put together the original end-to-end 5G Cloud Native demo which was shown at Kubecon in November 2019. The demo was received with tremendous excitement as it was the first truly cloud native 5G demo.

‍

One key component missing from that demo was automation. To help with this gap, we (Aarna.ml) decided to contribute to the effort by integrating ONAP with the demo. By using a subset of ONAP, we will be able to fill gaps around orchestration, lifecycle management, monitoring, and closed loop automation over time. See details on this effort here. However, since the vRAN portion of the original demo had some stringent hardware requirements in terms of FPGA boards and the need for a faraday cage to not interfere with licensed spectrum, we decided to simplify the problem and focus only on the 5G Core (5GC) instead for now.

We are happy to show the first version of this demo next week. We will show ONAP onboarding the Altran 5GC and then orchestrating it onto Red Hat OpenShift. Instead of a full 5G vRAN, we will use a gNB emulator instead.

Please join us for this exciting webinar and demo!

As one of the main contributors, I'm thrilled to state that the Private LTE/5G Integrated Cloud Native NFV/App Stack blueprint in the Linux Foundation Edge Akraino project got approved today.

Given the opening up of unlicensed/licensed private spectrum all around the world (e.g. CBRS in the US), Private LTE/5G promises to be very exciting market. Six end users (Airbus, Globe, Orange, Tata Communications, T-Mobile, and Verizon), a number of vendors (such as us), and individuals are collaborating on this blueprint demo which  will be created in a completely open manner and will contain, to the degree possible, open source components.

The key components of this blueprint are:

• NFVI hardware: Standard server, switch, storage components
• NFVI software: Kubernetes with OVN (SDN), Virtlet (to run VMs), Multus (for multiple CNI), Istio, and SD-EWAN (to connect an app across clouds). A main component in the NFVI software will also be an open source 5G UPF CNF.
• Orchestrator: ONAP with AF integration, OpenNESS
• Workloads (CNFs): Facebook Magma for vEPC, TIP OCN and Polaris for 5GC
• Workloads (CNAs): We are starting with the applications in the original ICN blueprint, viz. 360° video, EdgeX Foundry, video AI/ML. However, we might change things around to collaborate with other Akraino blueprints such as the 5G MEC blueprint that is working on cloud gaming, HD video, and live broadcasting.

We will first start with Private LTE over CBRS but then quickly move over to Private 5G and edge computing.

As an open source effort, we could always use more help, Please join us if this is interesting!