Amar Kapadia is the CEO and Co-Founder of Aarna Networks, a SaaS solutions provider that offers zero-touch edge and 5G services orchestration and management at scale. Amar has over 20 years of experience in networking, storage, server, and I/O technologies through marketing and engineering leadership positions at Mirantis, Emulex, Philips, and HP. Amar is the author of three books: "ONAP Demystified", "Understanding OPNFV" and "OpenStack Object Storage (Swift) Essentials," and holds an MS EE degree from the University of California, Berkeley. He lives in San Jose, California.
In a prior blog titled "OPNFV Yardstick NSB: The Prequel to VNF Onboarding" Sriram explained how and end-to-end VNF onboarding flow requires VNF validation, characterization and certification; and how OPNFV YardStick NSB can help with this effort.
To make this abstract concept a little more real, we have started an Intel DevMesh project titled "End-to-end VNF onboarding". In this project, we are using an L2 forwarding VNF from the OPNFV SampleVNF project. We will first show how to validate the VNF by using Yardstick NSB. Then we will onboard that same VNF onto ONAP, create a simple network service and then deploy the network service on OpenStack.
If you'd like to join us on this project, we welcome your participation. More details on the project and how to join available here.
Sriram Rupanagunta
Sriram Rupanagunta is a co-founder & SVP Engineering at Aarna Networks, Inc, and heads their engineering team. Prior to Aarna, Sriram was the Head of India Engineering at Data Center Business of Western Digital Corp. Prior to Western Digital, Sriram was with the SSD based startup Virident Systems (which was acquired by Western Digital). Earlier to that, Sriram was also the co-founder of start up Aarohi Communications which was acquired by Emulex Corporation, and was the Vice President, Technology at Emulex. He lives in Bangalore, India with his wife and a daughter.
Before you can onboard a VNF onto a MANO software stack such as ONAP, you need to select a VNF vendor. While comparing the functionality of competing VNFs is well understood from the PNF days, comparing their performance is a lot more difficult for the following reasons:
Differences between vendor environments: The NFVI/VIM platform, its configurations and traffic generators used by various vendors are likely to be different. Similarly, the actual performance tests may differ significantly. This makes comparing VNFs based on vendor provided metrics very difficult. While present to some degree, this issue was not as pronounced in the pre-NFV world.
Differences from a real production environment. If a vendor uses 10 NICs and uses up 100% of CPU resources available to generate metrics, then these metrics are not useful for a real world deployment. Similarly, the tests also need to reflect real world traffic conditions to be useful, which may or may not be the case in vendor provided results. Similar to the previous issue, this problem is also heightened in the NFV era.
The OPNFV Yardstick Network Service Benchmarking (NSB) tool is useful in solving the above problem. It runs performance tests on a VNF or entire network service. A CSP can thus use a consistent NFVI/VIM platform that reflects their production environment (could be an OPNFV scenario if there is desire to keep the validation platform vendor agnostic). The performance tests can also be written in a vendor agnostic manner. This methodology may be used to compare vendors in a consistent manner, validate VNFs and characterize their performance. NSB is fully automated, so can be plugged into a CI pipeline as well.
Curios to know more? Check out my OPNFV Yardstick demo video. If you have any feedback for me or want to deploy this methodology in-house, please contact us.
Sriram Rupanagunta
Sriram Rupanagunta is a co-founder & SVP Engineering at Aarna Networks, Inc, and heads their engineering team. Prior to Aarna, Sriram was the Head of India Engineering at Data Center Business of Western Digital Corp. Prior to Western Digital, Sriram was with the SSD based startup Virident Systems (which was acquired by Western Digital). Earlier to that, Sriram was also the co-founder of start up Aarohi Communications which was acquired by Emulex Corporation, and was the Vice President, Technology at Emulex. He lives in Bangalore, India with his wife and a daughter.
This blog is a continuation of the previous blog that explains deployment details (using TOSCA/HEAT templates) of various services that are part of vCPE blueprint in ONAP.
BTW, our ONAP Demystified book downloads and Amazon sales have crossed 400 as of today! Thanks for the tremendous interest. However, we haven't been doing so well on our ONAP merchandise. The merchandise, 100% pure-play ONAP without any Aarna branding, includes t-shirts, sweatshirts, hoodies, mugs, water bottles and much more. Feel free to buy & hopefully expense some of these items! There's minimal profit on each item and all proceeds go to the artist.
In this blog, we will cover 2 other services that are part of vCPE use case -- namely, vG MUX Infra service and vBNG service.
vG MUX Infra Service
vG_MUX provides the MUX functionality across all the links that are terminating at the Virtual Gateway.
The composition of this service is as shown below.
This service is modeled as a combination of TOSCA and HEAT templates, and the relationship is as shown:
The TOSCA model definitions file for this service can be found here.
The Environment file (base_vcpe_vgmux.env) for this service looks as follows:
Note the details about the networks for this service, such as private IP of bng_gmux link (10.1.x.x) and private IP networks of mux_gw (10.1.x.x, 10.0.x.x and 10.5.x.x) as well as the VNF details, including the pointer to the VPP source repo, since this VNF is based on VPP open source initiative.
Let us examine some of the interesting parts of HEAT template file (base_vcpe_vgmux.yaml) for this service. Complete copy of the HEAT template file can be found here.
heat_template_version: 2013-05-23
description: Heat template to deploy vCPE Infrastructure Metro vGMUX
##############
# #
# PARAMETERS #
# #
##############
parameters:
vcpe_image_name:
type: string
label: Image name or ID
description: Image to be used for compute instance
...
bng_gmux_private_net_id:
type: string
label: vBNG vGMUX private network name or ID
description: Private network that connects vBNG to vGMUX
...
mux_gw_private_net_id:
type: string
label: vGMUX vGWs network name or ID
description: Private network that connects vGMUX to vGWs
...
brgemu_bng_private_net_cidr:
type: string
label: vBRG vBNG private network CIDR
description: The CIDR of the vBRG-vBNG private network
onap_private_net_id:
type: string
label: ONAP management network name or ID
description: Private network that connects ONAP components and the VNF
...
vgmux_private_ip_0:
type: string
label: vGMUX private IP address towards the vBNG-vGMUX private network
description: Private IP address that is assigned to the vGMUX to communicate with the vBNG
Note the details of the vG_MUX VNF (vgmux), and its ports/networks. Also note the installation details of this service and the script to install on a VM (v_gmux_install.sh).
vBNG MUX Service
This service consists of 2 VL’s connecting the associated VNF’s, as shown below.
This service is modelled as follows using TOSCA (Green) and HEAT (Orange) templates:
The TOSCA model definitions file for this service can be found here.
The Environment file (base_vcpe_vbng.env) for this service is as shown:
Note the virtual link details of bng_gmux (10.1.x.x) and brgemu_bng (10.3.x.x), which are the 2 virtual links connecting BRG_Emulator to BNG_MUX and BNG_MUX to VG_MUX, and also two other network interfaces of BNG_MUX to connect to CPE_SIGNAL network (10.4.x.x), and lastly to ONAP OAM network (10.0.x.x).
Let us look at some of the interesting parts of HEAT template (base_vcpe_vbng.yaml) for this service. A full copy of the HEAT template file can be found here.
Interested in learning more about ONAP? Consider our ONAP training courses. Or want to try out vCPE or some other blueprint in your lab? Contact us for ONAP professional services.
Sriram Rupanagunta
Sriram Rupanagunta is a co-founder & SVP Engineering at Aarna Networks, Inc, and heads their engineering team. Prior to Aarna, Sriram was the Head of India Engineering at Data Center Business of Western Digital Corp. Prior to Western Digital, Sriram was with the SSD based startup Virident Systems (which was acquired by Western Digital). Earlier to that, Sriram was also the co-founder of start up Aarohi Communications which was acquired by Emulex Corporation, and was the Vice President, Technology at Emulex. He lives in Bangalore, India with his wife and a daughter.
This blog explains deployment details (using TOSCA/HEAT templates) of some of the important services of the vCPE blueprint in ONAP. It assumes that the reader is familiar with vCPE use case (for which there are several blogs/video available, including a free book from Aarna.ml -- ONAP Demystified, or the ONAP Confluence page).
The following block diagram provides an overview of the end to end service of vCPE, and how various constituent services are linked together.
vCPE end to end use case comprises of several services (some of which are optional, and will be replaced by equivalent services already existing in CSP’s environment), each of which contains one or more VNF’s and/or VL’s.
vCPE General Infra Service
vG MUX Infra ServicevBNG Service
vBNG MUX Service
vBRG Emulation
vCPE Customer Service
This blog shows details of some of these services, and their associated model templates.
vCPE General Infra
This service consists of vDHCP, vAAA and vDNS VNF’s connected by 2 virtual links (VLs) - cpe_signal and cpe_public, both of which are Openstack Neutron networks. The cpe_public link is also connected to a Web Server.
Now, let us examine the Infra Service in SDC Catalog for its constituent components and their details.
The composition of this service is as follows, which shows the virtual links (VLs) and the VF that makes up all the VNF’s:
The CSAR file for this service contains the following details:
The service is modeled (in TOSCA and HEAT templates) as follows:
Notice that the 2 networks (CPE_PUBLIC and CPE_SIGNAL) are modeled in HEAT, and so is the VF module that contains VM’s for all the VNF’s (vDHCP, vAAA and vDNS + vDHCP). The TOSCA template includes node_templates for all the HEAT templates. The TOSCA model definition file for this service can be found here.
Let us take a closer look at the Environment file (base_vcpe_infra.env) of this service.
Note the details about the constituent VNF’s (vAAA, vDHCP, vDNS and vWEB_Server), including their IP addresses, and the network addresses of the VL’s that these VNF’s are connected to (cpe_signal and cpe_public). For eg., vDHCP & vAAA are connected to cpe_signal network (10.4.x.x), and vDNS and vWebServer are connected to cpe_public network (10.2.x.x). Also, DCAE Collector service is connected at 10.0.4.x IP address.
Now, let us look at some of the interesting fields of HEAT template (base_vcpe_infra.yaml) of this service. This contains details about all the VNF’s that are part of this service, and how they will be instantiated using HEAT. Complete copy of the HEAT template can be found here.
heat_template_version: 2013-05-23
description: Heat template to deploy vCPE Infrastructure elements (vAAA, vDHCP, vDNS_DHCP, webServer)
##############
# #
# PARAMETERS #
# #
##############
parameters:
vcpe_image_name:
type: string
label: Image name or ID
description: Image to be used for compute instance
…
cpe_signal_net_id:
type: string
label: vAAA private network name or ID
description: Private network that connects vAAA with vDNSs
...
cpe_public_net_id:
type: string
label: vCPE Public network (emulates internet) name or ID
description: Private network that connects vGW to emulated internet
...
vaaa_private_ip_0:
type: string
label: vAAA private IP address towards the CPE_SIGNAL private network
description: Private IP address that is assigned to the vAAA to communicate with the vCPE components
...
vdns_private_ip_0:
type: string
label: vDNS private IP address towards the CPE_PUBLIC private network
...
vdhcp_private_ip_0:
type: string
label: vDHCP private IP address towards the CPE_SIGNAL private network
description: Private IP address that is assigned to the vDHCP to communicate with the vCPE components
...
vweb_private_ip_0:
type: string
label: vWEB private IP address towards the CPE_PUBLIC private network
description: Private IP address that is assigned to the vWEB to communicate with the vGWs
Note the details about various VNF’s (vAAA, vDHCP, vDNS and vWebServer) and the VL’s (Neutron networks - cpe_signal which connects vAAA with vDNS VNF’s and cpe_public, which connects vGW service to Emulate Internet) that are part of the Infrastructure service. Also note the vAAA instantiation, and details of DCAE Collector IP address, and the installation script (v_aaa_install.sh) in vAAA VNF. Other VNFs (vDNS, vDHCP & vWebserver) have been left out but you can refer to the link above for these details in the HEAT template file.
In the next blog, we will examine other Services and their details.
In the meantime check out our latest webinar on "What's new in ONAP Beijing" or request ONAP training if you/your team needs to learn more.
Amar Kapadia
Amar Kapadia is the CEO and Co-Founder of Aarna Networks, a SaaS solutions provider that offers zero-touch edge and 5G services orchestration and management at scale. Amar has over 20 years of experience in networking, storage, server, and I/O technologies through marketing and engineering leadership positions at Mirantis, Emulex, Philips, and HP. Amar is the author of three books: "ONAP Demystified", "Understanding OPNFV" and "OpenStack Object Storage (Swift) Essentials," and holds an MS EE degree from the University of California, Berkeley. He lives in San Jose, California.
What's a software release without some celebration? I am going to point out two ways, hopefully new to you, to celebrate the ONAP Beijing release:
ONAP Demystified Book:
For those new to ONAP, the project can be a bit overwhelming. The community has been making it easier to sink your teeth into the project with improved documentation, online training (offered by LF, developed by Aarna) and in-person training.
Today, I am very excited to share a new resource with you -- a mini-book titled ONAP Demystified, written by yours truly. This 76 page book provides a high-level understanding and business perspective of the ONAP project and a guide for navigating, participating, and benefiting from the ONAP community. The book is also meant for vendors that wish to determine how to position or sell their products into the ONAP ecosystem. This book covers the Beijing release.
Enjoy a wide range of ONAP merchandise (again not free), all without any vendor branding. You can get merchandise such as ONAP Beijing t-shirts, muscle tanks, dolmans, throw pillows, and even phone cases.
We'd love to hear your feedback, do let us know if you were able to take advantage of any of these resources.
Sriram Rupanagunta
Sriram Rupanagunta is a co-founder & SVP Engineering at Aarna Networks, Inc, and heads their engineering team. Prior to Aarna, Sriram was the Head of India Engineering at Data Center Business of Western Digital Corp. Prior to Western Digital, Sriram was with the SSD based startup Virident Systems (which was acquired by Western Digital). Earlier to that, Sriram was also the co-founder of start up Aarohi Communications which was acquired by Emulex Corporation, and was the Vice President, Technology at Emulex. He lives in Bangalore, India with his wife and a daughter.
The ONAP OOM project supports deploying ONAP using Kubernetes. This blog explains these steps and how they can be further automated.
Automation Leading to a Carefree Ops Engineer
The ONAP deployment is divided into the following logical steps:
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.
Setting up Rancher for Kubernetes environment, which is used to deploy ONAP
Preparing OpenStack for ONAP, which includes creating the required Cloud resources
ONAP deployment using Kubernetes/OOM
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, which is not covered here.
The first step of ONAP deployment is Openstack installation and deployment which has been automated already as part of Openstack project. There are multiple installers that can be used but for the purpose of this blog, I will describe Apex installer which installs Openstack and OPNFV. This uses the functionality of OOO (Triple-O), which essentially installs one Openstack instance (overcloud) over another Openstack instance (undercloud). This process can be initiated by running a single Apex script from the shell (or from a Jenkins job) which sets up both the Openstack instances. For example, in case of OPNFV deployment using APEX installer, the steps to automate the process are:
Install the APEX packages using the appropriate package manager of the Linux distro
Use the deployment script to start the Openstack Undercloud & Overcloud
Set up Openstack credentials on the Jump host, so that Openstack CLI can be used from Jump host, instead of from Undercloud instance
These can be included in a single script that can be invoked on the system as part of init scripts or the Jenkins job.
The second step of setting up Kubernetes is more involved, since it requires automating Rancher or Cloudify (which are the recommended tools for Kubernetes set up of ONAP). There are multiple steps involved in either of them, which require UI interactions from the user to set this up. In case of Rancher, it does provide CLI, and all the steps can be automated using the equivalent CLI commands (which is supported in the training lab of the upcoming Beijing release, but can also be run on Amsterdam).
The step of preparing Openstack is essentially to create the required cloud resources for deploying ONAP and it is fairly straightforward. The resources of course will vary depending on the type of deployment (HA, Network configuration etc.), but the basic set of resources are fairly simple to create. Openstack provides CLI tool that can be run from the Undercloud instance. Alternatively, the SSH credentials can be copied to the Jump host (which is where all the other commands will be run), and a single script (with the required openstack CLI commands) can be created to run all the required Openstack resources.
The last step is the deployment of ONAP components itself (using the ONAP Operations Manager, or OOM), which involves downloading the correct version of Containers, and deploying them using Kubernetes. This process is already automated as part of OOM in the ONAP distribution, and the deployment script takes care of starting all the required containers. The only other customization of these scripts that could be done is to run only the required containers for your application/use case, to avoid resource crunch.
In summary, all the necessary steps to install and deploy ONAP on a system (for the purpose of development or Devops) can be automated.
Please refer to Aarna’s free cloud images for more details on these steps and the necessary scripts.
