Skip to main content
All Posts By

ONAP

ONAP Releases Casablanca, Enhances Deployment Capabilities Across Open Source Networking Stack

By Announcement

New releases from ONAP and OPNFV advance NFV testing, orchestration & automation, as Accenture joins at the Gold level

San Francisco, December 4, 2018 LF Networking (LFN), which facilitates collaboration and operational excellence across open networking projects, today announced continued progress to ease deployments across the open source networking stack. New platform releases from ONAP (Casablanca) and OPNFV (Gambia) bring additional support for cross-stack deployments across new and existing use cases such as 5G and Cross-Carrier VPN (CCVPN), as well as enhancements to cloud-native VPN. Additionally, the organization’s compliance and verification program recently announced its expansion into virtual network functions (VNF) testing and is now recruiting Beta participants. VNF testing will help ease deployment pains and improve VNF quality and interoperability across real-world deployments.

“New and enhanced deployments of our platforms are popping up every day across the globe, and with tighter cross-community integration and an expanded compliance and verification program, we are well-positioned to facilitate innovative industry progress,” said Arpit Joshipura, general manager, networking, the Linux Foundation. “The latest releases of ONAP and OPNFV usher in a new era for LFN as the community continues to foster an expanding commercial ecosystem.”

“We are pleased with the continued growth and the diversity of contributors to ONAP, a key project within Linux Foundation Networking. The Casablanca release is a major step forward for this effort.  With wide-scale service provider and equipment supplier participation, ONAP is becoming the de facto automation platform for carrier grade service provider networks,” said Chris Rice, senior vice president of Network Cloud & Infrastructure at AT&T and Board Chair, LF Networking. “AT&T remains committed to actively contributing new code; leading technical areas; partnering on new 5G initiatives; orchestrating services across VNFs, PNFs, and soon CNFs (Container Network Functions), as well as developing leading edge, model driven platform enhancements like the Controller Design Studio.”

New Platform Releases Enhance Deployability

Together, LFN projects are crossing the open networking chasm by maturing capabilities that enhance deployability across an expanding commercial ecosystem. Supported by a growing list of top vendors, carriers, and other organizations, ONAP which brings together top global carriers and vendors with the goal of allowing end users to automate, design, orchestrate and manage services and virtual functions has expanded into a truly scalable platform with multiple, parallel threads. OPNFV a system-level integrations, deployment, testing and feature development project advances the state of NFV around cloud native and moves toward implementing continuous delivery (CD) to better support DevOps (a model that is growing importance to communication service providers) and infrastructure automation.

Key enhancements included in each release:

  • ONAP Casablanca introduces two new blueprints, sets the stage for a rich VNF ecosystem to emerge around ONAP, demonstrates community expansion, and adds new functionality making ONAP suitable for global deployment.
  • Building on a common theme of automation enhancements across LFN, OPNFV Gambia progresses the state of NFV around continuous delivery, cloud native network functions (CNFs), testing, carrier-grade NFVI features and upstream project integration. OPNFV was a pioneer with NFV continuous integration and is now taking a first step towards DevOps and continuous delivery.

Compliance and Verification Expands

Concurrently, expansion of the OPNFV Verification Program (OVP) is underway. Initially started as a program to test and verify the readiness and availability of commercial NFV NFVI/VIM products based on OPNFV functional testing capabilities, OVP is broadening its purview in 2019 to include testing and verification of VNF applications as well as third-party lab support. VNF testing will soon be in beta with active code that includes VNFSDK testing code. Vendors are encouraged to participate by submitting their VNFs for early testing to help shape the direction and future of virtualized deployments.

More details on ONAP Casablanca are available at this link and details on OPNFV Gambia can be found here. To learn about how to get involved in the compliance and verification program or to submit a VNF for testing send queries to verified@opnfv.org.  

Accenture Joins LFN

Additionally, LFN is excited to announce that Accenture has joined the project at the Gold level. Accenture is a leading global professional services company, providing a broad range of services and solutions in strategy, consulting, digital, technology and operations. Accenture joins additional Gold members Aptira, Inocybe Technologies, Lumina Networks, Microsoft and Telstra.

“ONAP continues to make great progress to help the industry evolve toward programmable network platform architecture via groundbreaking innovation and the ability to orchestrate cross-domain services,” said Amol Phadke, a managing director at Accenture and the company’s Global Network Strategy and Portfolio lead. “We are bringing a comprehensive and customizable ‘as a Service’ solution to the ONAP community that service providers can leverage and operationalize using a vendor-agnostic open-source approach.”  

Upcoming Community Events

LFN will be onsite at KubeCon+CloudNativeCon North America in Seattle, December 10-13, 2018. Join us to learn how LFN projects enable cloud native network functions (CNFs) and integrate across the container landscape. More information about the event, including registration, full agenda and details on the co-located FD.io Mini Summit, are available here: https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/.

The next ONAP Developer Design Forum will be conducted jointly with the OPNFV Gambia Plugfest in Paris, France from January 8-11, 2019. The event  will focus on Dublin release planning and explore various synergies with OPNFV as well as provide a forum for beta testing VNF compliance. Both members and non-members are welcome to attend the co-located events. Learn more here: https://events.linuxfoundation.org/events/onap-ddf-opnfv-plugfest/.

Supporting Comments from LFN  Members:

https://www.onap.org/announcement/2018/12/04/onap-casablanca-supporting-comments-from-members.

About the Linux Foundation

The Linux Foundation is the organization of choice for the world’s top developers and companies build ecosystems that accelerate open technology development and commercial adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at www.linuxfoundation.org.

# # #

 

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

 

Additional Resources

Download ONAP Casablanca

Get the ONAP Architectural Whitepaper

Get the ONAP 5G Blueprint Overview

Get the ONAP CCVPM Blueprint Overview

Download OPNFV Gambia

OPNFV Verified Program

Join LFN as a Member

 

Media Contact

Jill Lovato

The Linux Foundation

jlovato@linuxfoundation.org

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.

ONAP vFW Blueprint Across Two Regions

By Blog

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

In the last blog we talked about how to use a public OpenStack cloud such as VEXXHOST as the NFVI/VIM layer for the ONAP vFW blueprint along with a containerized version of ONAP orchestrated by Kubernetes.

As we discussed, in reality, the traffic source and the vFW VNF are unlikely to be in the same cloud.  In this blog, we will briefly discuss how the vFW blueprint can span two different VEXXHOST tenants. This is not quite the same as two different cloud regions, but it is a pretty close simulation.

The two VNFs will be placed as follows:

  • vFW_PG (packet generator) on VEXXHOST Tenant1

  • vFW_SINC (compound VNF that consists of the vFW VNF and a sink VNF to receive packets) on VEXXHOST Tenant2

Since ONAP infrastructure is taken care of, here are the steps to connect ONAP to VEXXHOST. Please follow the steps from “Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP” blog, to register both tenants as 2 regions in ONAP. Next:

  1. Create an account on VEXXHOST with 2 different tenants.

  2. If Registering the VEXXHOST into A&AI using ESR UI, change the password length to less than 20 characters.

  3. On Tenant1 manually create OAM network, unprotected_private  networks with different subnets than on Tenant2.

  4. On Tenant2, create an OAM network using the VEXXHOST cloud Horizon dashboard.

  5. Add security rules to allow ingress ICMP, SSH &all the required ports along with IPV6 from both the tenants.

  6. Edit the base_vfw.env and base_vpkg.env VNF descriptor files to configure them correctly based on the respective Tenants.

  7. Copy the above parameters into a text editor to use for subsequent A&AI registration, SDN-C preload, and APP-C⇔vFW_PG VNF netconf connection.

Now follow the steps from the vFW wiki that involve:

  1. SDC designer role: Create vendor license model

  2. SDC designer/tester role: Onboard and test VNFs (or vendor software product i.e. VSP)

  3. SDC designer role: Design network service

  4. SDC tester role: Test network service

  5. SDC governor role: Approve network service

  6. SDC ops role: Distribute network service

  7. VID: Instantiate network service

  8. VID: Add VNFs to network service

  9. SDN-C preload: Configure runtime parameters (for us design-time & run-time parameters are the same); preload vFW SINC on Tenant2 and vFW PG on Tenant1

  10. VID: Add VFs to network service — this step orchestrates networks and VNFs onto OpenStack

Upon completion of these steps, you should be able to go to the VEXXHOST Horizon GUI and see the VNFs coming up. Give them ~15 minutes to boot and another ~15 minutes to be fully configured. See below screenshots:

vFW Network Topology on Tenant2

vFW Network Topology on Tenant1

VNF SINC Stack Orchestrated on OpenStack Tenant2

VNF PG Stack Orchestrated on OpenStack Tenant1

Did you try this out? How did it go? We look forward to your feedback. In the meantime if you are looking for ONAP trainingprofessional services or development distros (basically an easy way to try out ONAP < 1 hour), please contact us.

Useful links: ONAP Wiki, vFWCL WikiOrchestrating Network Services Across Multiple OpenStack Regions Using ONAP