In this final installment of our series of blogs related to the 4th ETSI Plugtests held in June 2019, I’d like to discuss the successful testing done between the Benu Networks Virtualized Multiservice Edge Gateway (vMEG) and our Aarna.ml ONAP Distribution (ANOD) 2.0. Benu Networks participated in the VNF category of the Plugtests and ANOD participated in the MANO category.

The vMEG series is Benu Networks’ virtual software deployment option for the SD-Edge Platform, which runs the Benu Operating System (BenuOS) for fixed and mobile broadband service providers looking to deploy next generation IP services to the edge and core of their networks.  The solution can run in OpenStack or VMware and on common industry hypervisors. The platform can support multiple services simultaneously. The vMEG provides new scale and economics for Benu Networks’ virtualized IP service & network applications and offers service providers a fully virtualized deployment for the most demanding networking and IP service applications.

ANOD is Aarna.ml 100% pure play commercially supported distribution of the Linux Foundation Open Network Automation Platform (ONAP) project. ONAP provides fully automated orchestration, lifecycle management, and monitoring of edge workloads and network services.

ONAP has a detailed set of VNF requirements that include packaging requirements as well. The VNF descriptor can either be in OpenStack Heat template or TOSCA. The testing used the Benu Networks’ vMEG packaged using a Heat VNF descriptor. Using this VNF package, we were able to onboard the VNF to ONAP’s design studio. Next, we created a Network Service (NS) consisting of that same VNF. ONAP then deployed the entire NS onto a commercial cloud vendor’s OpenStack platform.

Do you have a VNF but are not sure how to interoperate with ONAP? Check out our VNF Onboarding for ONAP whitepaper.

Learn more about Benu Networks’ vMEG at https://benunetworks.com

If you are curious about the business of open source software, I would highly recommend Peter Levine and Jennifer Li's blog titled, "Open Source: From Community to Commercialization." This exceptional blog, that uses the "As Software Eats the World, Open Source Eats Software" line, covers a number of topics ranging from growth of open source software in both revenue and across verticals, the virtuous cycle of open source, business success KPIs, business models, and finally open source go-to-market.

I am going to attempt to evaluate the ONAP project across the above metrics. ONAP, for those new to it, is a Linux Foundation Networking open source project that provides fully automated orchestration, monitoring, and lifecycle management of NFV, SDN, and edge computing services.

At least a quick scan of Levine's and Li's blog will be useful to get some context around the rest of my blog.

Open Source Renaissance

This one should apply to ONAP with ease. There is every reason to believe that open source will impact 5G and edge computing in the same way it has impacted other industries. With analysts such as Chetan Sharma predicting that over the first 10 years in their lifecycle, the edge computing economy will be more than 4x bigger than the cloud economy, the prospects for open source software in this segment are promising.

The Virtuous Cycle of Open Source

As 5G and edge computing disaggregate what has traditionally been a vertically integrated hardware and software solution, traditional benefits of open source such as no-vendor lock-in, the ability to influence the roadmap, rapid innovation, transparency, improved security etc.  come into play. ONAP brings with it a couple more advantages in the areas of collaboration with 3rd party standards bodies/open source projects and streamlining interop testing. On the first point, organizations such as ETSI, TM Forum, MEF, 3GPP, CNCF are using ONAP as a de-facto project to prove out their standards or open source efforts. On the second point, the industry simply does not have the resources to do N orchestration vendors x M Workload vendor interop testing. ONAP with its community driven compliance and validation testing of VNFs, will become the gold standard in interop test verification. In short, the combination of traditional open source benefits and a couple of unique ONAP-specific ones, should unlock the virtuous cycle of open source for ONAP.

Business Success

Levine and Li talk about three stages of business success: project-community fit, product-market fit, and value-market fit. Let me first provide my assessment of ONAP across these three stages and then my reasons for the assessment:

• Project-community fit: Proven
• Product-market fit: In-process
• Value-market fit: Not proven but promising

Project-Community Fit

If we look at project-community fit for ONAP, over the last 90 days, we see:

• 26 contributing organizations
• 30 sub-projects

The contributor growth since the inception of the project is as per the below chart. The month-to-month varies a lot, so I think the 6 month or 180 day moving average is better (source onap.biterg.io), and overall in the right direction.

Product-Market Fit

The fact that users such as AT&T and China Mobile were founders of the project shows that ONAP solves a real problem. With the latest ONAP Dublin release, the user activity looks like follows:

• 3 users state they have ONAP in production: AT&T, Bell Canada, Orange
• 12 other users state they are in PoC stage: Bringcom, China Mobile, China Telecom, Deutsche Telekom, Equinix, KDDI, Reliance Jio, Swisscom, Telecom Italia, Turk Telecom, Verizon, Vodafone

This is all promising, but I don't think we have yet seen the one solid use case where users are tripping over each other to get to ONAP. Perhaps 5G and edge computing might be it? For this reason, I'm leaning towards saying product-market fit is in-process.

Value-Market Fit

There are two questions that come to mind: 1) Is the project inherently amenable to a value-market fit? And 2) Has that value-market fit been demonstrated as of now?

The first question is interesting. As Levine and Li point out, if the project is too awesome, there isn't an opportunity to create much value-market fit. Docker comes to mind. So the project should inherently have some rough edges that require vendors. ONAP fits in this category. In fact, if anything vendors will have to do some serious heavy lifting in terms of ONAP lifecycle management and hardening.

Having established this point, the second question is whether there is value-market fit today. Based on the ONAP product revenue, I would say not yet. Other than us (Aarna.ml), I am not aware of a 100% open source pure-play distribution. However, as per the Dublin announcement, there is some level of commercial activity around ONAP at Accenture, Amdocs, Boco, CommScope, ENEA, Ericsson, Fujitsu, Huawei, IBM, Netsia, Nokia, Tech Mahindra, Samsung, Wipro, and ZTE. Many of the bigger companies are obviously dabbling; looking to see which way the wind blows. The only burn-your-ships-a-la-vikings company is Aarna.ml, where we will live and die solely based on the success or failure of ONAP.

Business Models

I expect 5 business models for ONAP:

1. SaaS: ONAP could be installed in a public cloud to manage 5G/edge and other workloads. This could be attractive for smaller customers.
2. Managed ONAP: This is between a software sale and SaaS, where ONAP could be installed on-prem, but managed by a vendor.
3. Open-core: This is a perhaps going to be the most popular ONAP business model. In fact, we at Aarna are pursuing this model at this time. We will provide support for the ONAP platform itself and provide proprietary apps, artifacts, and dashboards on top specific to a use-case. Our proprietary add-on is called AarnaStream™.
4. Services: ONAP will need a ton of professional services. We expect large SIs to provide these services.
5. Training: This is another standard business model. In fact, Aarna is the #1 ONAP training provider.

Open Source Types by Buyer

If there was one embellishment I might make to an otherwise amazing blog by Levine and Li, that is to categorize open source projects by the buyer persona, more specifically the champion.

I think the champion can be classified into three categories:

1. Individual champion: Take Postman for example. It is typically brought into the organization by individuals.
2. Team leader champion:  Jenkins for example. It is difficult to try this out individually, but a team can definitely evaluate Jenkins and bring it in.
3. Organization leader champion: For good or bad, ONAP fits here. Even the evaluation of ONAP has to be driven at high level by someone who has authority across multiple teams.

How an open source project is championed in an organization, in my view, affects the way the business success evolves:

What do you think? I'd love to hear your feedback.

I attended the ONS Europe that took place in Antwerp, last month. I am going to share my thoughts on the conference in general, and ONAP related topics in particular.

We participated in the Linux Foundation booth to demonstrate the OPNFV Verification Program (OVP)—an open source, community-led compliance and verification program to show the readiness and availability of commercial NFV products and services, including NFVI and VNFs. It was a joint demo led by China Mobile, Huawei, Intel, Vodafone, VoerEir and us (Aarna.ml). We showed 4 OVP demos in total: NFVI validation, VNF compliance, VNF validation using a Heat VNF, and VNF validation using a TOSCA VNF. We used the Dovetail test framework for NFVI compliance testing, VVP for static validation of VNFs (using Heat templates) and VTP for run-time validation of both TOSCA and Heat based VNFs. There was a fair amount of interest and curiosity around OVP in general, and many visitors (from operators to VNF vendors) to the booth asked for additional information and pointers on the program and felt they would benefit from this. Most of the questions from the visitors were around how they could enhance this for additional coverage of VNF-specific functionality.  

The keynote sessions were quite well-attended. Few key take-aways from my point of view, more specific to ONAP and LF Networking perspective:

• Cloud-native based architectures and deployments, specifically using Kubernetes are gaining traction and interest.
• How LFN sees the path from Open source projects to commercialization.
• Alignment of ETSI and Linux Foundation and how Open source and Open standards can work together, and seen as complementing each other, and not competing.
• The growing interest in Edge Clouds, and related technologies.

There are several other interesting presentations and while I am not going to mention specific presentations (all of which are available here), let me talk about a few themes that seem to be emerging.

Edge computing will bring together Enterprises, Telcos and Cloud vendors, with specific applications for IoT, Healthcare, Retail and so on. This is an interesting development that creates technical challenges in terms of managing and orchestrating these applications at scale.

There were presentations from Telcos that gave an overview of the 5G transition and how it is changing the landscape of services and applications that are going to be enabled as a result of this transition. This again poses several challenges in terms of orchestrating these Network Services and VNF/CNFs. Another interesting session outlined how 5G applications can be architected as cloud-native, the criteria used for disaggregating them into stateless containers, and how Kubernetes based technologies can be used to build them. The scale at which these applications are expected to be deployed is very interesting!

There were a couple of presentations from Telco operators (one of them with whom we at Aarna.ml actively worked together) on their journey with ONAP, the challenges faced by them, and the recommendations from them as consumers of this technology. The common theme in these presentations is the need for simplifying the deployment of ONAP and targeting specific use cases.

We also hosted an unconference session titled, "ONAP as a unified MEC-in-NFV Orchestrator", and while this is technically feasible, the feedback we received is that it needs more work in terms of understanding existing solutions in this space, and how vendors will perceive this as an opportunity rather than a potentially competing solution.

The ONS conference was followed by Technical Meetings of specific open source projects - ONAP, ODL and CNTT (which is a Telco task force for common NVFi or NFV Infrastructure, with active collaboration from Linux Foundation). The ONAP technical meeting is an open community event, and this specific meeting had several interesting presentations such as Edge, alignment with ETSI standards as well as various sub-committee meetings. The presentations can be found here.

Overall, it was a very interesting and enriching experience to attend this event and interact with various community members, in the beautiful city of Antwerp!

If you are VNF/PNF (xNF) vendor and are not sure how to proceed with ONAP interop, review our whitepaper on this topic. Or contact us, we will be happy to do an assessment on the various aspects of your xNF compatibility required with ONAP—VNF descriptors, configuration, lifecycle management and monitoring. As ONAP experts that have worked with 6 VNF vendors, we can also give you advice on the different strategies for interop: direct vs. via sVNFM/EMS, Heat vs. TOSCA, etc.

#ONAP #NFV #5G #MEC

In our ongoing series of blogs related to the 4th ETSI Plugtests held in June 2019, today we want to highlight the successful testing done between the Palo Alto Networks Virtualized Next-Generation Firewall (vNGFW) and our Aarna.ml ONAP Distribution (ANOD) 2.0. Palo Alto participated in the VNF category of the Plugtests and ANOD in the MANO category.

Palo Alto Networks K2-Series 5G-ready next-generation firewalls, powered by PAN-OS®, adopts a preventive security approach to provide robust and comprehensive end-to-end security strategy for mobile network deployments. Designed to handle growing throughput needs due to increasing amounts of application-, user-, and device-generated data, the K2-Series offers amazing performance and threat prevention capabilities to stop advanced cyberattacks and secure mobile network infrastructure, subscribers, and services.

K2-Series family of firewalls integrates cloud-based threat intelligence powered by machine learning and AI techniques for rapid, real-time response to threats across networks on a global scale. Gain complete visibility and granular control with automated security enforcement across all network interfaces including RAN, Roaming, S(Gi), Cellular IoT (NB-IoT) and non-3rd Generation Partnership Project (3GPP) access.

Open Network Automation Platform (ONAP) a Linux Foundation Networking open source project, includes the functionality of a  MANO solution, as described by ETSI, in terms of NFVO and VNFM, but goes beyond that by providing a real-time policy driven closed loop automation framework for service assurance. In addition, ONAP contains an inventory service and a simple-to-use design studio.

ANOD is Aarna.ml 100% pure play commercially supported distribution of ONAP. It includes an enhanced version of the ONAP installer called A-OOM (Aarna ONAP Operations Manager) that reduces 3-4 weeks of installation time to just half-a-day. ANOD also comes with basic or premium support so that you can use ONAP with confidence.

Specifically from the Plugtests point of view, ONAP has a detailed set of VNF requirements that include packaging requirements as well. The VNF descriptor can either be in OpenStack Heat template or TOSCA. The testing used the Palo Alto vNGFW packaged using a Heat VNF descriptor. Using this VNF package, we were able to onboard the VNF to ONAP’s design studio. Next we created a Network Service (NS) consisting of that same VNF. ONAP then deployed the entire NS onto a commercial cloud vendor’s OpenStack platform.

Do you have a VNF but are not sure how to interoperate with ONAP? Check out our VNF Onboarding for ONAP whitepaper.

Learn more about Palo Alto Networks’ 5G security at https://www.paloaltonetworks.com/security-for/network/5g-mobile-networks

The 4th ETSI Plugtests event was conducted earlier in June of this year. We got the opportunity to work with several VNF and VIM vendors, as well as end users.  One of the interoperability tests we concluded successfully was between our ONAP distro and Mobileum’s Smart Diameter Routing Agent (sDRA) and virtual Network Traffic Redirection (vNTR) VNFs.

A bit of background first:

Mobileum helps Communications Service Providers (CSPs) grow and protect their revenues, innovate new business models, and digitally engage with their customers. Mobileum leverages their unique technology platform, Active Intelligence, to deliver innovative analytics solutions in focused areas; in Roaming, Fraud, Revenue Assurance, Security, and Customer Engagement. Mobileum Smart DRA (Diameter Routing Agent) application leverage's Mobileum’s standards-based, carrier-grade, multi-feature platform called SDS, to provide comprehensive features and functionalities of DRA solution in a single node. Mobileum’s Network Traffic Redirection application is an innovative solution that offers mobile operator to pro-actively contact their outbound roamers by using signalling protocols to influence the choice of networks to which they latch when they roam.

ANOD is Aarna.ml 100% pure play commercially supported distribution of the Linux Foundation Open Network Automation Platform (ONAP) project. ONAP includes the functionality of a  MANO solution, as described by ETSI, in terms of NFVO and VNFM, but goes beyond that by providing a real-time policy driven closed loop automation framework for service assurance. In addition, ONAP contains an inventory service and a simple-to-use design studio.

Mobileum participated in the VNF category of the Plugtests and we, with ANOD,  in the MANO category. The Heat templates provided by Mobileum for the vSDRA and vNTR VNFs were first onboarded onto Aarna.ml ONAP Distribution (ANOD) 2.0 by using the Service Design & Creation (SDC) design studio. Once onboarded, the VNFs were chained together by using a common virtual network into a single Network Service along with a traffic generator. The Network Service was distributed to the run-time components of ANOD. Finally, by using the Virtual Infrastructure Deployment (VID) tool, the Network Service was deployed onto a commercial OpenStack distribution.

To learn more about ANOD or how Aarna.ml might help you package your VNF/PNF/CNF for ONAP, please contact us.

#NFV #VNF #ONAP #Roaming #Telecom #Mobileum #Aarna.ml

If you haven't watched yesterday's interview with the CEOs of Verizon, IBM, and Qualcomm on CNBS yet, I would highly encourage watching it .

If you don't have the time/patience, here's my top 4 takeaways (I'm paraphrasing of course):

1. Unlike the previous generations, 5G will have a big impact on enterprises, and the enterprise part might actually be the more exciting and a bigger revenue piece of 5G

2. It's not just 5G; it's 5G + Edge Computing + NFV/SDN

3. Enterprises will start taking advantage of 5G by 2022

4. Open standards/open source will be important

Of course ONAP didn't come up specifically. But I can't help but imagine what a great opportunity this is for ONAP. With the Frankfurt release in 1H 2020, the 5G use case blueprint will be fully fleshed out. And with the support for Kubernetes becoming more robust, any arbitrary Edge Computing application will also be supported.

While automation is not the first thing on people's mind as they roll out 5G/Edge, these services will not be viable unless there is full automation in terms of orchestration and management. When the need for automation becomes urgent (my prediction sometime in 2020), the combination of open source benefits such as vendor agnostic/no lock-in and architectural benefits such as real-time closed loop automation, positions ONAP to dominate 5G/Edge.

Not sure what ONAP is? Read our ONAP Demystified Book. If you're ready to give ONAP a test-drive, try out Aarna.ml ONAP Distribution 3.0 that comes with commercial support.