First let me explain the first two terms and then describe the connection to ONAP.

RIFEE

RIFEE is my term that means Rakuten's Infrastructure for Everyone Else.

There's tremendous buzz about how an IT company is aggressively jumping into mobile connectivity by building a cloud-native 5G-ready network, and in doing so outflanking traditional telcos on technology. I believe many mobile operators are asking themselves, privately I'm sure, how they can have an infrastructure just like Rakuten's, and how they can build a solution with the same speed.

In a TelecomTV interview, Tareq Amin, CTO Rakuten Mobile Network (along with Manish Singh from Tech Mahindra), talks about how they are working to achieve such an aggressive goal. It's worth a listen.

I have two suggestions on RIFEE. One is non-technical by adopting ideas from the Loonshots book. The other is technical by taking advantage of the Linux Foundation Open Network Automation Platform (ONAP) project.

Loonshots

Loonshots is a book by Safi Bahcall where he explores "how to nurture the crazy ideas that win wars, cure diseases, and transform industries." This is an interesting book that states that structure rather than culture is the reason innovation happens or not. An example used in the book is Nokia, a company that innovated from selling rubber boots and toilet paper in the '70s to selling half the smartphones on the planet by early 2000s. But that same company killed an internal iPhone like project along with an app store in 2004. What happened internally to create such a massive reversal? Did the culture suddenly change? Of course not. And the author argues that it was the company structure that changed and in doing so it stifled innovation.

Loonshots provides a very comforting message on the non-technical aspect of RIFEE. As a mobile operator, you should focus on structure, where it may be as straighforward as creating a new cloud-native software group in your company, to get the ball rolling. This group would have complete autonomy in terms of picking technologies, processes, and choosing vendors. This concept is obviously much simpler than trying to change your company culture.

ONAP

ONAP is a network automation project under the Linux Foundation umbrella with terrific momentum. It provides classic SDN/NFV management and orchestration, but also service assurance and automation.

As a mobile operator, you can use the ONAP 5G use-case blueprint along with say OPNFV VCO 3.0 to solve the technical aspect of RIFEE. (NOTE: The 5G blueprint and VCO 3.0 are not fully ready yet, but should be by end of 2019.)

By combining Loonshots and ONAP, you can get a 5G network by end of 2019. In fact, with this approach, you can not only match RIFEE, but beat in terms of technical superiority.

We moved to our new office in India’s Silicon Valley, Bangalore!

We are now  located in the most happening neighborhood in Bangalore  — Koramangala.

Our new coordinates are:

Aarna.ml LLP

Davanam Golden Square Prime,

4th Floor, Davanam Sarovar Portico Hotel,

Opposite Madiwala Police Station,

Koramangala, Bangalore 560 068

Tel: +91 49116666

We have a band of highly talented and super-experienced engineers in our Bangalore development center working on the Linux Foundation ONAP project!

The 4th ETSI Plugtests event is round the corner, and in this blog, I will explain how NFVI/VIM vendors, VNF vendors and hardware vendors can work with us to test ANOD (Aarna.ml ONAP Distribution) with their respective offerings at the Plugtests. This is the first time ONAP will be at a Plugtests, and we are very excited to gain end-to-end ONAP testing experience.

‍

‍

‍

NFVI/VIM

First, let us look at NFVI/VIM vendors. The Aarna.ml ONAP Distribution can be connected to any other Openstack/StarlingX deployment that complies to Ocata or later APIs. At the Plugtests, we would like to verify the interoperability with Openstack deployments from various NFVI/VIM vendors.

VNF Vendors

Next, let us look at VNF vendors. ANOD provides two orchestration paths (SO NFVO/gVNFM for Heat VNF descriptors and SO→VF-C NFVO for TOSCA VNF descriptors using an external sVNFM).

There are broadly 3 areas that need attention from VNF vendors’ point of view for onboarding their VNF’s onto ONAP.

1. If the VNF/Network Services are going to be orchestrated using SO in ONAP, they need to create HEAT descriptors for their VNFs. If these descriptors already exist ( i.e. if these VNFs are already running as Virtual Machines under Openstack), these descriptors can be reused, with some changes needed as part of ONAP onboarding.  
2. If the VNF/Network Services are going to be orchestrated using VFC in ONAP, they need TOSCA descriptors  for the VNFs. Additionally, there needs to be a ETSI SOL-003 compliant sVNFM as well.  
3. Lastly, the VNF vendors can use ONAP tools to test their VNF descriptors for compliance, using VVP (for HEAT based templates) or VNFSDK (for TOSCA based templates).

Once the above steps are completed, we can work together with the VNF vendor to execute the official Plugtests test plan. The test plan can include an NFVI/VIM vendor or we can use the OPNFV scenario included with ANOD. Time permitting, we can also perform some closed-loop automation testing by creating a collector, analytics pipeline and a Policy.

Hardware Vendors

The Plugtests can also be used to ensure that ONAP functionality is validated on the target hardware platform. This will involve deploying ANOD on the target servers, and using ONAP and Openstack (either the OPNFV scenario included with ANOD or from any other NFVI/VIM vendor) to test end to end functionality of deploying VNFs (open source or from one of the above vendors). This activity could bring  all 4 players together - NFVI/VIM, VNF vendors and hardware vendors along with the Aarna.ml ONAP Distribution to execute the official Plugtests test plan.

A couple of  weeks ago, the Linux Foundation announced the expansion of the OVP program to include ONAP VNF compliance testing. Vendors will be able to test their VNFs against ONAP using a self-service model, submit their results, and get a compliance badge. These VNFs will also get listed on the OVP site.

I think this is a very positive development. The program should contribute to the growth of the ONAP ecosystem that is critical for ONAP's long term success. There is plenty of information about the program and the benefits to Communication Service Providers (CSPs) and VNF vendors in the above links. So I'm not going to repeat this.

Instead I am going to address a key question: As a VNF vendor, should you engage now or wait & watch? That of course, depends on a cost-benefit analysis.

Cost-benefit of passing OVP testing in 2019

Since the tests are very light right now, the cost of passing OVP is simply to create an ONAP compliant VNF descriptor (VNFD). The program has only static tests and there are no functional, lifecycle management, monitoring or performance tests at this time.

‍

In our view, the effort required for simple VNFs is:

• If a Heat/TOSCA VNFD already exists, the effort is in the 1-2 man-week range  
• If a VNFD does not exist, the effort is in the 2-4 man-week range

‍

At a $250K burdened salary, we are talking about a roughly $10K investment.

‍

What's the benefit? That's not as easy to quantify, but qualitatively:

• Your VNF will be listed on the LFN OVP site as an ONAP compliant VNF. Along with this comes the visibility and PR/marketing benefit.  
• Ability to say "yes" to RFPs that require ONAP compliance and entering a shortlist of VNFs could put you ahead of your competitors.  
• Ability to participate in open community-based ONAP blueprints or create private demos; these demos will not require any licensed MANO software.  
• Benefit of appeasing CSPs that have committed to OVP even if immediate RFPs don't require ONAP compliance.

‍

Is the benefit much greater than $10K? We think so, but ultimately you have to be the judge of that.

‍

Cost-benefit of waiting on OVP until 2020 or later

‍

The benefit of waiting on OVP until 2020 or later is obviously the ~$10K savings in 2019. What is the cost? The cost again cannot be quantified, but qualitatively:

• Inability to participate in ONAP based RFPs.  
• Perceived lack of open source community thought leadership.  
• Facing a higher bar in 2020; OVP tests will be more complex, and you will have to catch up with competitors that already have a badge from earlier, easier testing.

‍

In summary, as a VNF vendor, you need to determine whether passing OVP in 2019 makes sense or not. We feel it should be an easy "Yes" based on the cost-benefit analysis above. If you agree but are not sure where to start, read our "VNF Onboarding for ONAP Whitepaper".

‍

We can also help with our Aarna.ml ONAP Distribution (ANOD) along with ONAP training and ONAP deployment/VNF onboarding services. Feel free to contact us on any of these ONAP related topics.

In a blog titled "The Telecom Industry Has Moved to Open Source", Arpit Joshipura, GM Networking & Orchestration + Edge/IOT at Linux Foundation, is quoted as saying, "We have seen a 140-year-old telecom industry move from proprietary and legacy technologies to open source technologies with LF Networking.” I couldn't agree more. As with enterprises, open source adoption will increase within Communication Service Providers (CSPs). And it will increase significantly.

At the same time, there is massive confusion amongst CSPs in terms of what open source is, and how they should consume it. I've heard statements such as, "I'm going to wait until project XYZ is a stable product" or "why should I pay for open source software support, the community will provide support." The implication here is that the community is working on full productization and/or providing L1-3 support. Here are some of my thoughts on open source:

What is Open Source?

Isn't open source code developed in an open repo using an open source license? Yes, but this is a very limited understanding. Just having open access to the code does not make it usable. True open source means that all aspects code development needs to be open:

• Code development  
• Test suites  
• Continuous Integration (CI) pipeline  
• Code review process/disposition of reviews  
• Integration labs  
• Backlog list (roadmap features/bugs) and process of deciding which items make it in a particular release  
• Meetings  
• Wiki pages/documentation  
• Interop testing  
• Use case discussions/demos

Linux Foundation projects have governance in place to make all these aspects open.

What Open Source is Not?

There are two major misconceptions — community (as opposed to a commercial distro) open source is a product and open source is free. These two points are obviously inter-related. An open source community's charter is to develop code. It's not to develop and support a fully finished product. For this reason, the open source community typically works on interesting technical problems. It doesn't do the laborious work of building a product. Unfortunately, a lot of productization in terms of stability, scalability, security, performance, documentation, manageability, installation, lifecycle management and monitoring is not the most exciting work. This same point also explains why open source is not free. Either the end user or a commercial distribution vendor has to do the work of creating a finished product from the open source code.

The above picture is analogous to the gap between open source and a commercial product.

Why Open Source?

If open source is not free and it is not a finished product, then why bother using it? Should't one keep using proprietary products? Not really. There are numerous very good reasons to embrace open source. Open source:

• Supplements/replaces standards: Standards often move very slowly. Or they are not grounded in reality. Or they leave things open to interpretation. Open source projects can supplement standards with a reference implementation and in some cases replace them entirely.  
• Results in faster innovation: Since programmers from a diverse backgrounds work on open source projects, they can typically innovate faster. In a project such as the Linux Foundation ONAP project, you have a diversity of programmers from classic telco to cloud technologies to hardware to security to OSS/BSS backgrounds. This means ONAP can innovate faster than any proprietary product.  
• Roadmap influence: Traditionally an end user has to talk to a sales person who talks to a product manager who talks to an architect who talks to the engineers. Anybody remember the game of telephone? By the time the engineer gets the requirement, it's hardly recognizable. In open source, end users can influence the project directly.  
• Reduced lock-in: A healthy open source project (see next section) typically has multiple commercial vendors. This reduces, if not eliminates, vendor lock-in. So even though open source is not free, this particular point might result in open source being less expensive than proprietary.  
• Transparency: If an open source project is truly open as per the section above, there is full transparency in terms of what the community is doing, and more importantly how decisions are being made.

What is a Healthy Open Source Project?

A healthy open source, in my view, has five attributes:

1. Truly open: A healthy open source project, see above, is truly open in all aspects.  
2. Multiple contributors: An indication of a healthy project is that no one company dominates contributions. The more uniform the distribution of contributions, the better off is the community.  
3. Active end-user participation: This is a critical point. Ideally end-users should be contributing code. But this need not always be the case; end-users can contribute in other ways, e.g. by defining requirements, participating in use cases, providing customer case studies etc.  
4. Commercial activity: A project may do well for a while without commercial activity (commercial activity may be defined as both vendors generating revenue and end-users putting the project in production to generate value), especially if it is early in the project's life. However, commercial activity is the oxygen that sustains a project. Without commercial activity, it is very difficult to see how a project can survive long term.  
5. Ecosystem: Related to the previous point, a healthy open source project has an ecosystem of interoperating products (proprietary or open source). Again, early in a project's life, the ecosystem may be small.

Let's take ONAP as a case study. By being a part of Linux Foundation, ONAP is automatically truly open.

Second, the distribution of contributions is quite uniform (contributions from Dec-26 2018 to Mar-26 2019).  

Third, ONAP boasts end user participation from AT&T, China Mobile, Orange, Bell Canada, Vodafone, Verizon, Turk Telecom, Reliance, China Telecom and others. Some contribute code. Others participate in use case/blueprint development. And yet others contribute by providing requirements. Finally, end user customer success stories are just starting to emerge.

Fourth, the ONAP commercial activity is early. We (Aarna) provide a development distribution (as of March 2019; if you are reading this in the future, we should have production distribution), training and some point professional services. SIs such as Tech Mahindra, Accenture and others provide a much broader set of ONAP professional services. Orange has put parts of ONAP in production and is mandating ONAP compliance in their RFPs.

For the last point, ONAP is still early in terms of an ecosystem. The upcoming OVP VNF Validation program should expand the ecosystem significantly. The ecosystem of interoperating cloud, SDN controller and OSS/BSS systems is also early and growing.

While the last 2 points are a bit weak, it is still early in the life of ONAP, so we can hazard a guess that ONAP is going to be a healthy project. You can use the same evaluation technique on other projects too.  

Open Source Consumption Models

Given the above background, there are three ways to consume open source projects. Two lead to success and one leads to failure.

Successful Model#1 Do-it-yourself (DIY): The DIY model requires that an end user support themselves with the open source technology. This requires architecture, engineering, testing and support teams. A meaningful open source project can easily require 20-30 full time people. This can be very expensive. Also, the end user has to have the ability to retain these individuals. There are many stories where end users spun up an internal OpenStack team, only to lose the staff once the team members had completed their actual goal — which was learning OpenStack and improving their resume appeal. Given the hassle and cost, an end user needs to determine whether a DIY model is a core differentiator for them. End users successful with a DIY technique are Google for Kubernetes and Amazon for Hadoop.

Successful Model#2 (Commercial distribution): This model requires that an end user work with a commercial distribution vendor for an open source project. The commercial vendor provides a finished product and L1-3 support. This is normally a safe default path for most end users.

Failed Model#1 (DIY without a long-term internal team): I can't tell you how many end users mistakenly believe that an open source project is a free finished product (reminds me of the saying — if something is too good to be true, it probably is). Even if the customer can do a successful PoCs using this technique, it is a doomed model once you go into production. There are numerous anecdotes of how a bunch of smart architects and engineers got OpenStack to run in a lab and then put it into production. 6 months later, either the engineers were gone. Or they were around but didn't know how to upgrade. Or the configuration changes got so complex that nobody could support the deployment after a year. This is a horrible lose-lose model. The end user directly experiences a negative business impact with very unhappy customers. And the open source project unfairly gets a bad name.

In short, open source is on a meteoric rise amongst CSPs. And I hope CSPs can embrace open source with their eyes wide open.

Needless to say, if you are looking for a commercial ONAP vendor, please contact us.

In this blog, I will explain the steps needed for using Robot scripts for onboarding and instantiation of VNF’s in an OOM based ONAP deployment, such as one used by Aarna.ml ONAP Distribution (ANOD). The Robot script comes with the default deployment and you can learn more about the Robot framework here.

Setup Requirements

Before we go deeper into various Robot scripts, we need to make sure that following setup is available and working correctly.

1. ONAP should be setup with the correct Openstack configurations. You can refer to Aarna’s ANOD for deploying ONAP.  
2. All Kubernetes containers in ONAP need to be up and running.  
3. ONAP should be accessible over the GUI.

‍

Robot Script Commands

The Robot framework in ONAP provides us various options to onboard/distribute/instantiate VNF packages.

‍

First, you need to download latest ONAP source files from the git repo.

‍

The base script for Robot is located at the following location:

oom/kubernetes/robot/

‍

The first step is to initialize the Robot setup with ONAP. The command is as follows

cd oom/kubernetes/robot/

./demo-k8s.sh onap init

‍

This will create test customer models and distribute them in ONAP. The script takes several minutes to complete. After the completion of the script one can log into ONAP GUI and see various test customers and test models.

‍

The Robot framework provides following additional commands:

1. Create demo customer (Demonstration) and services, etc.

$>./demo-k8s.sh onap init_customer

2. Distribute demo models (demoVFW and demoVLB)

$> ./demo-k8.sh onap distribute  []

3. Preload data for VNF for a given  module

$> ./demo-k8.sh onap  preload    

4. Instantiate vFW module for the a demo customer. This will go all the way to create a stack in openstack.

$> ./demo-k8.sh onap instantiateVFW

5. Delete the module created by instantiateVFW

$> ./demo-k8.sh onap deleteVNF

‍

The Robot framework runs as a kubernetes container on one of the ONAP server nodes. The Robot container has template files for the following VNF's.

• vCPE  
• vFW  
• vFWCL  
• vLB  
• vLBMS  
• vVG  

‍

Using Robot scripts one can onboard above VNF's in ONAP. Some base functionality is provided as part of the ONAP package and the rest can be built by modifying the scripts. The scripts can also be further tweaked to create custom 'CUSTOMERS' and distribute them.

One can login to the Robot container using following commands.

# Get the Robot POD name

$> kubectl get pod --all-namespaces -o=wide | grep robot

onap dev-robot-54bbc764fb-2k2mw 1/1 Running 1 49d 10.42.108.186 beijing01

# Connect to Robot POD

$> kubectl exec -it -n onap dev-robot-54bbc764fb-2k2mw -- /bin/bash

The above kubectl command creates a bash shell within Robot container. In the shell we can view various Robot scripts that use python commands to operate on ONAP.

Above mentioned VNF packages and  corresponding Openstack Heat templates are located in following directories:

root@dev-robot-54bbc764fb-2k2mw:/# cd /share/heat/

root@dev-robot-54bbc764fb-2k2mw:/share/heat# ls

OAM-Network  ONAP  temp  vCPE  vFW  vFWCL  vLB  vLBMS  vVG

root@dev-robot-54bbc764fb-2k2mw:/share/heat# cd vFW

root@dev-robot-54bbc764fb-2k2mw:/share/heat/vFW# ls

MANIFEST.json  base_vfw.env  base_vfw.yaml

Above we can see the .yaml and .env file for virtual firewall (vFW).

When Robot scripts are invoked, it picks up the above files, creates a zip and then onboards it to ONAP.

More details on Robot scripts can be found here

/var/opt/OpenECOMP_ETE/robot/testsuites

After the completion of a Robot command, one can look at the logs located in following directory.

root@dev-robot-54bbc764fb-2k2mw:/share/logs/demo/InitDemo# pwd

/share/logs/demo/InitDemo

root@dev-robot-54bbc764fb-2k2mw:/share/logs/demo/InitDemo# ls

log.html  output.xml  report.html

# We can access the Robot logs from web UI

Logs URL = http://<PORTAL LOAD BALANCER  IP>:30209/logs/demo/

For copying the files from the container to host server you can use the following command.

kubectl cp onap/<robot container id>:<path to file>  <local name>

e.g.

kubectl cp onap/dev-robot-54bbc764fb-2k2mw:/var/opt/test  /tmp/test

For customization of Robot commands and addition of functionality one can look into following scripts.

root@dev-robot-54bbc764fb-2k2mw:/var/opt/OpenECOMP_ETE/robot/testsuites/demo.robot

The above file contains Robot tags for above mentioned commands.

In the next blog, I will explain how some of these Robot scripts can be customized for onboarding VNFs and Network services that you created, so that this process of onboarding and testing them can be automated.

Curious to learn more? Take our 2 day training in San Jose on April 1-2 just before ONS. Or give ANOD a spin.

‍