Monthly Archives

July 2018

Webinar on demand: What’s new in ONAP Beijing Release?

By | News

Download the BrightTalk webinar here.

Are you worried about orchestrating your NFV/SDN network services and edge computing applications? The Linux Foundation Open Network Automation Platform (ONAP) promised to be a key component of next generation networks to orchestrate, configure, monitor and automatically manage complex services and applications. With the recent Beijing release, the ONAP community has fortified software stability, harmonized northbound APIs with standard bodies, improved ONAP deployment using Kubernetes, added important functional features and created two new projects. If you have not followed the release too closely, join us for this webinar and learn all about it. In this webinar, you will learn:
•What is ONAP?
•How can ONAP help you?
•What is new in the Beijing release?
•How can you get involved?

vCPE Blueprint in ONAP

By | Blog

This post originally appeared on Arana Networks. Republished with permission.

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 Networks — 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.

  1. vCPE General Infra Service

  2. vG MUX Infra ServicevBNG Service

  3. vBNG MUX Service

  4. vBRG Emulation

  5. 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.

parameters:

  cloud_env: “openstack”

  cpe_public_net_cidr: “10.2.0.0/24”

  cpe_public_net_id: “zdfw1cpe01_public”

  cpe_public_subnet_id: “zdfw1cpe01_sub_public”

  cpe_signal_net_cidr: “10.4.0.0/24”

  cpe_signal_net_id: “zdfw1cpe01_private”

  cpe_signal_subnet_id: “zdfw1cpe01_sub_private”

  dcae_collector_ip: “10.0.4.1”

  dcae_collector_port: “8081”

  demo_artifacts_version: “1.2.0”

  install_script_version: “1.2.0-SNAPSHOT”

  key_name: “vaaa_key”

  mr_ip_addr: “10.0.11.1”

  onap_private_net_cidr: “10.0.0.0/16”

  onap_private_net_id: “ext-net”

  onap_private_subnet_id: “ext-net”

  pub_key: “ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQXYJYYi3/OUZXUiCYWdtc7K0m5C0dJKVxPG0eI8EWZrEHYdfYe6WoTSDJCww+1qlBSpA5ac/Ba4Wn9vh+lR1vtUKkyIC/nrYb90ReUd385Glkgzrfh5HdR5y5S2cL/Frh86lAn9r6b3iWTJD8wBwXFyoe1S2nMTOIuG4RPNvfmyCTYVh8XTCCE8HPvh3xv2r4egawG1P4Q4UDwk+hDBXThY2KS8M5/8EMyxHV0ImpLbpYCTBA6KYDIRtqmgS6iKyy8v2D1aSY5mc9J0T5t9S2Gv+VZQNWQDDKNFnxqYaAo1uEoq/i1q63XC5AD3ckXb2VT6dp23BQMdDfbHyUWfJN”

  public_net_id: “2da53890-5b54-4d29-81f7-3185110636ed”

  repo_url_artifacts: “https://nexus.onap.org/content/groups/staging”

  repo_url_blob: “https://nexus.onap.org/content/sites/raw”

  vaaa_name_0: “zdcpe1cpe01aaa01”

  vaaa_private_ip_0: “10.4.0.4”

  vaaa_private_ip_1: “10.0.101.2”

  vcpe_flavor_name: “onap.medium”

  vcpe_image_name: “ubuntu-16.04-daily”

  vdhcp_name_0: “zdcpe1cpe01dhcp01”

  vdhcp_private_ip_0: “10.4.0.1”

  vdhcp_private_ip_1: “10.0.101.1”

  vdns_name_0: “zdcpe1cpe01dns01”

  vdns_private_ip_0: “10.2.0.1”

  vdns_private_ip_1: “10.0.101.3”

  vf_module_id: “vCPE_Intrastructure”

  vnf_id: “vCPE_Infrastructure_demo_app”

  vweb_name_0: “zdcpe1cpe01web01”

  vweb_private_ip_0: “10.2.0.10”

  vweb_private_ip_1: “10.0.101.40”

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

  …

    …

  dcae_collector_ip:

    type: string

    label: DCAE collector IP address

    description: IP address of the DCAE collector

 …

#############

#           #

# RESOURCES #

#           #

#############

resources:

….

  # Virtual AAA server Instantiation

  vaaa_private_0_port:

    type: OS::Neutron::Port

    properties:

      network: { get_param: cpe_signal_net_id }

      fixed_ips: [{“subnet”: { get_param: cpe_signal_subnet_id }, “ip_address”: { get_param: vaaa_private_ip_0 }}]

  …

  vaaa_0:

    type: OS::Nova::Server

    properties:

     …

          template: |

            #!/bin/bash

            # Create configuration files

            mkdir /opt/config

            echo “__dcae_collector_ip__” > /opt/config/dcae_collector_ip.txt

            …

            # Download and run install script

            curl -k __repo_url_blob__/org.onap.demo/vnfs/vcpe/__install_script_version__/v_aaa_install.sh -o /opt/v_aaa_install.sh

            cd /opt

            chmod +x v_aaa_install.sh

            ./v_aaa_install.sh

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.