All Posts By

ONAP

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

ONAP Beijing: Member Supporting Quotes

By | Announcement

“As one of the founding creators of and leading code contributors to ONAP, we’re thrilled to see this strong and growing developer ecosystem continue to advance the platform,” said Chris Rice, LF Networking Board Chairman and Senior Vice President of Domain 2.0 Architecture and Design at AT&T. “All service providers and network operators will benefit from the second software release, Beijing, which is focused closely on enhancing the platform to ensure scalability, security, stability and performance in support of real world deployments. As the 5G era approaches, software-centric network automation will be key to meeting customer expectations and driving new capabilities into the network.”

 

“China Mobile is committed to implementing network transformation technology innovation based on the ONAP open source community. We are very pleased to see that after the basic functional verification of the Amsterdam version of the core network virtualization business scenario, the community version of Beijing has been enhanced with respect to stability, reliability, and security,” said Yachen Wang, Deputy General Manager, AI and Intelligent Operation R&D Center, Network and IT Technology Department, China Mobile. “We will select core modules based on the Beijing version to conduct customized product R&D for key CMCC application scenarios. At the same time, we will continue to invest resources in supporting community work. In particular, the jointly-developed SDN and NFV-enabled cloud network collaborative orchestration business scenarios to enhance functionality and verification, contributing to the widespread deployment of ONAP.”

 

“As a platinum member, China Telecom has witnessed and participated in the successful deployment of ONAP’s Amsterdam release. Thanks to member collaboration, the Beijing release is now available and includes progress in Security, Stability, Scalability and Performance,” said Dr. Sun Qiong, SDN Technology R&D Center Director of China Telecom Beijing Research Inst., and LFN Board member, China Telecom.  “Based on the ONAP Architectural Principles, Beijing will accelerate the policy-driven orchestration and automation of physical and virtual network functions, and expand the platform’s maturity. China Telecom has endeavored and will continuously work hard together with other LFN members to to develop the top global automation platform in a software-defined, virtualized era.”

 

“The ONAP Beijing release brings the maturity of the platform to a new stage, providing a very good reference for carrier network transformation and service  automation,” said Dr. Xiongyan Tang, chief scientist, China Unicom Network Technology Research Institute. “As an innovative leader in China’s telecommunications industry, China Unicom has always been committed to uniting industry partners, accelerating network innovation, enabling business development and prospering the whole industry ecosystem. We will continue to participate in developer activities within the LFN community and within our network, to help enable growth across the industry.”

 

Mats Karlsson, Head of solution area OSS at Ericsson says “Ericsson is one of the leading promoters of open source ecosystem, accelerating the adoption and industry alignment in key technology areas including ONAP and ETSI – NFV alignment to benefit customers and partners.  As part of Ericsson’s collaboration and deep involvement in many open source projects, we see automation with orchestration playing a vital role in the evolution of 5G networks. ONAP is a key enabler of 5G evolution bringing automation based on analytics, policy and orchestration across legacy & hybrid cloud environments. The Beijing release takes substantial step forward in platform security, scalability, stability, enhanced exposure capabilities, and deployable on both virtual machine and container/kubernetes infrastructures. This release also demonstrated Virtual CPE and Virtual VoLTE use cases.”

“The ONAP Beijing Release focuses on increasing the stability, reliability, security and performance of the platform, it is a key milestone for ONAP’s commercial deployment,” said Bill Ren, vice president, Network & Industry Ecosystem Development, Huawei. “With 5G and network cloudification, automation and intelligence are more important to the telecommunications industry than ever before. Because of its advanced architecture and concepts, Huawei believes that ONAP is an industry platform more suitable for global operator network automation, but ONAP’s  maturity requires more consensus and collaboration in the upstream and downstream in the industries. Huawei will work with its carrier partners to conduct a joint POC of the 2B service scenario based on the Beijing Release, and promote ONAP to commercial deployment as soon as possible.”

“Inocybe is pleased to have been actively involved in contributing to the OpenDaylight (SDN-C) component of the ONAP Beijing Release,” said John Zannos, CRO of Inocybe and LFN Board Member. “ONAP is bringing the world’s operators together to collaboratively innovate and solve some of the most common challenges they face on their journey to automated and intelligent networks. In collaboration with partners, we’re looking at how we can best industrialize the software and help operators build, test and manage use-case specific distributions using the production-ready components of ONAP like SDN-C.”

“Netsia is fully committed to ONAP and actively participating in the OSAM project for the Casablanca release,” said Bora Eliacik, VP of Engineering, Netsia. “We intend to take this into production at a leading service provider in Turkey.”

 

Marc Rouanne, President of Mobile Networks at Nokia, says: “As top 10 contributor to the Beijing release, Nokia is an active member in the ONAP community and we continue to collaborate with community members to advance standard interfaces and system modularity in support of our customers’ varying needs. Integration with external controllers represents a significant step forward for an open and expandable automation platform, and is a key result of this collaboration. Nokia also supports recent ONAP directions towards virtual and physical network and service operations automation. Comprehensive automation strategies are critical for fast moving, hybrid network, digital services environments.”

 

“Designed using best-in-class micro-service architecture and following the best practice criteria for open source software, the ONAP Beijing Release provides a reliable and operable platform. It includes a set of powerful VNF packaging and validation tools that provides a common framework, easing VNF on-boarding and reducing the integration load,” said Emmanuel Lugagne Delpon, Senior Vice President of Orange Labs Networks. “Aligned with the internal network transformation program towards network softwaritisation, Orange is very active in the community with 20+ contributors for the Beijing Release. Orange developed 3 APIs aligned with TMF to facilitate integration within existing IT and BSS applications: External API/NorthBound Interface for service order, catalogue and inventory. To promote ONAP usage and to provide more testing capabilities, Orange proposes an Openlab platform used by 70+ users (from operators, vendors and academic) to demonstrate the full ONAP framework capabilities and to share results with the community.”

 

“We are excited to see the growing ONAP developer community and the strong interest from leading  Communication Service Providers (CSPs) across the globe,” said Arunmozhi Balasubramanian, Senior VP, Network Services – Solutions & Strategy, Tech Mahindra. “Tech Mahindra is among the top five contributors of ONAP. Tech Mahindra is executing a number of ONAP PoCs (Proof of Concepts) with leading CSPs across Americas, Europe and ANZ (Australia and New Zealand). The Beijing release provides support for PNFs (Physical Network Functions) which paves the way for easier migration to next- gen service management. ONAP enables CSPs to realize the much needed Service Agility and Hyper Automation for their networks.”