Today we made two presentations at the joint ONAP Dublin DDF + OPNFV Gambia Plugfest event in Paris. Both presentations/demos were successful and well received. A quick summary of the two presentations:

Mobile Content Cloud (MCC) Network Service Using ONAP:

Alex Xia from Affirmed and I showed how to use Affirmed Networks' MMC related VNFs and onboard them through the ONAP SDC design tool. We next showed how to create a single network service using these VNFs through ONAP SDC. Then we perform SDN-C preload of VNFs and deployed the network service (MCC) using VID in the ONAP portal. Finally, we showed  post-deployment configuration for the VNFs. See video here.

L2 Forwarder Using Yardstick NSB and ONAP:

In this presentation, we used a Sample VNF from OPNFV – L2 forwarder – to show an end-to-end lifecycle of a VNF using OPNFV + ONAP. We mean lifecycle from an operator point of view where the first step is to validate/certify a VNF and the last step is to deploy/manage it in production. We showed how we can do perf. benchmarking using OPNFV Yardstick NSB to validate/certify an VNF. Next we onboarded the VNF onto ONAP. Finally, we deployed the VNF using ONAP onto an OPNFV OpenStack scenario. See video here.

Want to learn more? Sign up for our public ONAP training (EU and US coming up in the next few months) or request a private onsite training. Or use our products/services for your specific project requirements.

Even though the Linux Foundation Open Network Automation Platform (ONAP) is well into its 3rd 6-month release (Casablanca came out in Dec’18), topics such as what ONAP is and how it’s architectured seem to be a subject of confusion. This is true even in sophisticated audiences as evidenced by a recent blog titled, “A Tale of Two Transformations: ONAP versus the Cloud” by Tom Nolle. At a high level, the blog compares ONAP and AWS (from a mindset point of view) and concludes that ONAP is business-as-usual and therefore incompatible with the transformative nature of cloud aka AWS. In my mind, a few key themes emerged from the above blog that are worth discussing.

But before we do that, it is important to consider what functionality ONAP includes. I call ONAP a MANO++, where ONAP includes the NFVO and VNFM layers as described by ETSI, but goes beyond by including service assurance/automation and a unified design tool. ONAP does not include the NFVI/VIM or the NFV cloud layer. In other words, ONAP doesn’t really care whether the NFV cloud is OpenStack, StarlingX, or in future, Kubernetes or Microsoft Azure. Nor does ONAP include VNFs. VNFs come from 3rd party companies or open source projects.

OK end of background. On to the four themes:

MODEL DRIVEN

The ONAP vs. Cloud blog states, “I told the ONAP people that I wasn’t interested in future briefings that didn’t focus on model-driven transformation of the ONAP architecture. Casablanca is the second release that has failed to provide that focus...” I found this statement perplexing. Model-driven is a central tenet of ONAP. In fact if anything, one might complain about there being too much model-driven thinking but not too little! There are models for:

• VNF descriptor  
• Network service descriptor  
• VNF configuration  
• Closed-loop automation template descriptor  
• Policy  
• APP-C/SDN-C directed graphs  
• Orchestration workflow  
• The big bang (just kidding)  
• So on and so forth

The key idea of a model driven approach is to enable non-programmers to change the behavior of the platform with ease. And ONAP embraces this paradigm fully.

DEVICE ORIENTATION

The ONAP vs. Cloud blog continues, “ECOMP [as a precursor to ONAP] is following what I’ve characterized as the “device networking” vision of the future, and not the “cloud-native” vision.” The blog asserts that the lack of a model driven approach means ONAP is relegated to a device-networking approach. This couldn’t be further from the truth either. ONAP goes through great pains of creating a hierarchy and providing the highest level of abstraction to the OSS/BSS layers. The below show a couple of examples.

Service Orchestration & LCM (the left-hand side item feeds into the right-hand side item):

VF ⇛ Module ⇛ VNF  ⇛ Network/SDN service   ⇛ E2E network service ⇛ Product (future) ⇛ Offer (future)

Service Assurance:

Analytics Microservices & Policies ⇛ Closed Loop Templates

With upcoming MEC applications, the million dollar question is, will ONAP orchestrate MEC applications as well? This is to be determined, but if this happens, ONAP will be even further from device-orientation than it already is.

CLOUD NATIVE

The blog further states, “the Casablanca release is replete with comments about VNFs and PNFs, and the wording makes it clear that what ONAP is now focused on is providing the operational layer of NFV. Since NFV isn’t cloud-native, ONAP doesn’t need to be [i.e. isn’t].”

There are three sub-myths in the paragraph that surrounds the above text. First is that VNFs can’t be cloud-native. In fact they can be and ONAP highly encourages, I daresay, insists upon it (see ONAP VNF Development requirements here)? Cloud-native or containerized network functions (CNFs) are just around the corner and they will be fully supported by ONAP (when we say VNF, we include CNFs in that discussion). Second, the argument that ONAP documentation being replete with VNFs and PNFs is a net negative misses the point. ONAP refers to VNFs and PNFs since they constitute higher level services. The argument is tantamount to saying that if AWS uses the words VM or container, they need to be written off as outmoded. Moreover, new services such as 5G are expected to be built out of physical network functions (PNFs) — for performance reasons — and VNFs. Therefore, ONAP anticipates orchestrating and managing the lifecycle of PNFs. Finally, the third assertion is that VNFs not being written in a cloud-native manner is somehow indicative of ONAP being mis-architected. It is true that a large number of VNFs are VNFs-in-name-only (i.e. PNFs that have been virtualized, but not much else); however, this is orthogonal to ONAP. As mentioned above, ONAP does not include VNFs.

LACK OF INNOVATION

The final section of the above-mentioned blog can be summarized as saying that there is a lack of innovation on the ONAP side. The ONAP vs. Cloud blog offers examples such as Amazon Firecracker, Lambda and Outpost as evidence. Let’s take each one:

• Amazon Firecracker: ONAP can already support unikernels (i.e. ridiculously small VMs) and will support Kata containers when the MultiCloud project fully supports k8s. So I don't see any issue.  
• Lambda: Here there is some truth, ONAP can’t handle function-as-a-service. For NFV, I am not sure ONAP ever needs to support function-as-a-service. However, if ONAP ends up orchestrating MEC applications, it might have to. But I don’t view this as a showstopper. When the time comes, I’m sure the ONAP community will figure this issue out — it's not that hard of a problem.  
• Outpost: ONAP and Outpost are different layers of the software. There are two ways they can interoperate. Today, ONAP is containerized and can run on any cloud that supports k8s. I assume Outpost will support k8s, so ONAP can already run on Outpost. Second, if an Outpost adapter is written for the ONAP MultiCloud project, ONAP will be able to orchestrate VNFs onto Outpost. It’s just a small-matter-of-programming :).

In summary, even amongst sophisticated circles there is a lot of confusion about ONAP’s ability to support a model driven, service oriented, cloud native, transformative future. Hopefully this blog clarifies some of those points.

Want to learn more about ONAP? Try Aarna.ml ONAP Distribution 1.0 (ANOD) — Development for free on GCP. Request ONAP Training

There is tremendous interest in development around ONAP. We hear CSPs and vendors talk about activities such as:

• Trying out a specific ONAP blueprint e.g. vFW, vDNS, vCPE etc.  
• Building a PoC for internal purposes/customer demos  
• VNF onboarding (from both a vendor point-of-view and CSP)  
• Network service design  
• OSS/BSS interfacing  
• Policy development  
• Closed-loop automation template design  
• Alarm correlation

Most developers naturally gravitate towards doing these kinds of development activities on their laptop. However, ONAP cannot be tried out on a typical laptop since it is resource hungry. To solve this problem, we have created our first product -- the Aarna.ml' ONAP Distribution 1.0 Development (or ANOD 1.0 Development for short). We label it "Development" since ANOD 1.0 is not available for production; only for development. Our subsequent releases, of course, will be supported in production deployments. Our ONAP development distribution, based on the ONAP Beijing release, can be installed on GCE or on one single (or more) bare metal server. How did we get it to fit? We have replaced DCAE with CDAP-all-in-one and done some other magic. This way the functionality is intact but the footprint is very light. We have also automated a number of steps to make the distribution very easy to install. Just recently we came across two customers who were stuck at different stages of ONAP installation. One could not get all the containers up, while another one was stuck at vFW deployment (could not complete the closed-loop automation exercise). ANOD 1.0 Development solves issues such as this by being repeatable and simple to use. The one final benefit of ANOD is that it is self-contained with all the working container images for ONAP, so works in environment with limited internet access — something we are finding to be extremely commonplace.

This blog explains how the ONAP can be deployed seamlessly on a bare metal server(s) or on Cloud, using ANOD 1.0 Development.

The ONAP OOM project supports deploying ONAP using Kubernetes. ONAP  deployment can be done on a single server (all in one), a single VM (such as Google cloud instance) or multiple servers/VMs. If it is installed on a single server or a Google cloud instance, we will be creating another KVM instance inside this server or VM (using Nested VM feature). If the VM/server requires Openstack too (in addition to ONAP), it is deployed using OPNFV Apex installer.  In this case, the number of GCE VMs goes up to 2. We use OOM for deploying ONAP, using Aarna’s pre-built ONAP QCOW images (available on GCloud) for creating ONAP Kubernetes cluster.

ANOD 1.0 Development can be deployed in the following configurations:

1. On GCE, using 2 VM’s (one of them running Openstack, and another running ONAP). This can also be supported on other cloud based technologies that support nested VM feature. (Note: This is also used in Aarna’s ONAP Training Labs)  
2. On single or multiple Bare metal server (that supports nested KVM capabilities), pointing to an external Openstack (not deployed using ANOD)  
3. On a single Bare metal server (that supports nested KVM capabilities), with Openstack as part of the deployment (all-in-one)

These reference architectures are shown below.

The reference architecture in case of GCE looks as follows:

The reference architecture in case of Bare metal installation (with external Openstack) looks as follows:

The reference architecture in case of a single server (all-in-one) installation looks as follows:

The ONAP deployment is divided into the following steps:  

1. Deploying OpenStack as a target NFVI cloud for ONAP. This step is optional, in case you already have a Openstack (public or private) deployment that you plan to use for ONAP.  
2. Downloading KVM images for ONAP that are part of ANOD, which are pre-installed with all the required packages and automation tools.  
3. Setting up Rancher for Kubernetes environment, which is used to deploy ONAP  
4. Preparing OpenStack for ONAP, which includes creating the required Cloud resources  
5. ONAP deployment using Kubernetes/OOM and verifying the functionality

Once these steps are done, the deployment is ready for use, and SDC design and NS/VNF onboarding can be done, using the sample vFW service, or any other custom network service/VNFs.

Each of these steps can be automated, either for deployment in development environment or as part of Jenkins job in Continuous Integration (CI) process. In case of live deployments, the process obviously needs lot more automation and tuning of various components.

In summary, the benefits of ANOD are:

1. Able to try out ONAP on 1 GCP VM or single bare metal node  
2. Easy repeatable installation  
3. Installation possible without internet connectivity

On GCP: one instance of ANOD is free. Request access here.

On bare metal: ANOD is available on an annual subscription basis. Often times our customers request ANOD with ONAP training. Please contact us for pricing.

Do you find yourself in meetings where NFV buzz-words are being thrown around and the prevailing attitude of "everyone should know this stuff" preventing you from asking what these terms mean? Have you also been frustrated that most of the NFV material out there is telco-centric and not really tailored for Cable Operators, meaning it does not directly address your needs?

Well I have some good news for you. There is now a CableLabs NFV101 course that covers the basics of NFV, with a 100% Cable Operator point of view. The training will take around 3 hours (virtual) or 1/2 day in-person. It is broken into 7 chapters:

• NFV basics  
• Key NFV requirements  
• Use cases  
• Current industry landscape  
• The role of open source and standards  
• Future trends

You can take it for free online. Or you can contact us for an in-person fee-based training.

After having designed the first pre-DOCSIS CMTS at HP in '96-'97 (yes HP was in the CMTS business for a short while) and having worked on the first QAM/MPEG2 based digital set-top boxes in '97-'99 at VLSI Technology (acquired by NXP), I'm super excited to be back working with the cable industry, and am really looking forward with meaningful conversations.

Feb-2019 Update: The course is now also available on Intel Network Builders here.

The Linux Foundation Open Network Automation Project or ONAP takes its promise of being able to change the behavior of the platform without requiring programming, to the degree possible, quite seriously. The philosophy is pervasive -- ranging from areas such as creating closed loop automation pipelines, describing hardware platform requirements for VNFs, modifying/creating new network service orchestration workflows or modifying/creating new behavior for APP-C (application) and SDN-C (Software Defined Networking) controllers.

Take SDN-C and APP-C for example. In addition to configuration and other data in the form of models (e.g. YANG), they take programming inputs represented through something called Directed Graphs (DGs). These DGs are processed by a service logic interpreter and converted to Java objects. Most importantly, DGs can be written by non-programmers. They can also be changed dynamically without requiring any system restart. APP-C, for example, comes with DGs that can configure, start/stop, rebuild a VNF along with numerous other actions. They can be modified by users. Furthermore, they can be supplemented with additional DGs to create new features.

The ONAP wiki has a nice writeup on how to install the DG Editor on an Ubuntu desktop and next how to create your first DG.

‍

Unfortunately, I don't have an Ubuntu desktop. Rather than figuring out how to install the DG Editor on my mac, I decided to spin it up on Google Cloud. Here are the instructions. You can watch a YouTube video of this demo as well.

1. Create an Ubuntu 16.04 VM with 2vCPUs. Go with the default memory and disk size that come with 2 vCPUs.

2. Install relevant packages and start the DG editor:

# Install these packages one-at-a-time

sudo apt-get install default-jre

sudo add-apt-repository ppa:webupd8team/java

sudo apt-get update

sudo apt-get install oracle-java8-installer

sudo apt-get install -y nodejs

sudo ln -s /usr/bin/nodejs /usr/bin/node

sudo apt-get install maven

sudo apt-get install graphviz

sudo apt-get install npm

# Install DG Builder editor

# This entire command is one line

git clone http://gerrit.onap.org/r/sdnc/oam && (cd oam && curl -kLo `git rev-parse --git-dir`/hooks/commit-msg http://gerrit.onap.org/r/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg)

cd oam/dgbuilder

# username can be anything e.g. akapadia in my case

# enter one of your email addresses as well

# This whole command is one line

./createReleaseDir.sh 15.10   ~/sdnc/1510/service-logic

npm install sqlite3

./start.sh 15.10

http://:3101/#

# Username: username from above

# Password: test123

# Ignore following errors

# 25 Sep 00:04:51 - [red] Flows file not found...

# Could not load the file /home/.../oam/dgbuilder/releases/15.10/selected_modules

3. Try out the "Your First Graph" exercise. Of course, you won't be able to upload or activate the DG since the editor is not connected to ONAP. But you will be able to learn about the various DG "nodes" in the areas of flow control, device management, Java plugin support, logging/recording and resource management. If there's sufficient interest, I might do a subsequent blog explaining each of the various DG nodes.

If you would like to learn more about ONAP, please request one of our ONAP training courses. Or if you would like to set up ONAP in your lab, check out our professional services. Setting up ONAP in your own lab seems to be a trend right now. We've just completed 3 such setups in the last month. Pardon the sales pitch, but don't be late on this critical technology, start playing with it in your lab ASAP.

Earlier this month, Iain Morris from Light Reading reported that Orange is starting their '5G Plus Automation' RFP effort this year and the message to vendors is clear, "If you can't support ONAP interfaces, don't bother responding."

As an ONAP products & services, company, this news could not have been better. ONAP is about 1.5 years old and the commercial activity around the project has had a slow start. However, this announcement should change that. Once an operator adopts ONAP, vendors will have no option but to ensure interoperability. As more vendors support ONAP, more operators will adopt, thus kicking off the proverbial virtuous cycle.

But what does supporting ONAP interfaces mean? There are three broad categories of interfaces:

• Northbound API: that interface to OSS/BSS applications, E-Services (e.g. self-service web/mobile applications for end-users), big data applications  
• Southbound interfaces: to OpenStack other SDN controllers  
• Onboarding interfaces: for VNFs, PNFs, analytic microservices/applications, policies etc. I'm speculating here, but I imagine MEC application onboarding specs could come soon.

While all interfaces are important, the most critical one at this time is VNF/PNF (aka xNF) onboarding due to the sheer magnitude of xNFs out there. The ONAP community provides very detailed guidelines/documentation on how to write and package an xNF for ONAP consumption. The main requirements are:

1. Cloud optimized/native VNF (the specification covers topics such as design, resiliency, security, modularity and DevOps) image  
2. xNF descriptor (OpenStack Heat or TOSCA)  
3. xNF lifecycle management support (with or without a sVNFM)  
4. xNF configuration template (e.g. YANG model)  
5. xNF monitoring (e.g. via VES or Google Protocol Buffers; with or without an EMS)  
6. xNF CI tests  
7. xNF license metadata  
8. xNF documentation  
9. Additional artifacts e.g. error-code XML file

As you can see, while VNF vendors might be able to get away with a quick demo with just item number 2, a full ONAP interop is a LOT more involved. Furthermore, even within a category e.g. monitoring, a vendor can support just 1 event for a demo, but will have to support the full set of events for production use.

The above article is just the start. More and more operators will require ONAP compatibility as 5G RFPs start to roll out. As a VNF vendor, I think your two choices are: A) Get a head-start and use ONAP compatibility as a competitive advantage, or B) Wait for the RFP and scramble. Not supporting ONAP at all, I don't think is a realistic option.

In either scenario, Aarna.ml is ready to help. If you are new to ONAP, check out our free eBook. Or request one of our popular ONAP trainings. When you are ready to play with ONAP, request our ONAP deployment or ONAP VNF onboarding professional services.