ONAP Beijing Release Developer Forum

Closed-Loop Automation Requirements for Beijing Release After ONAP Amsterdam Release did the closed loop based on the use cases, e.g. VOLTE use case close loop automation based on alarm correlation and self-healing, there are more requirements appeared. This presentation will describe the requirements of Closed-Loop Automation for Beijing Release, and utilise use case as examples to show the requirements.

OpenSource Access Management is a project to build a set of tools, interfaces, models, flows and services to extend the ONAP platform for the Access Network. The move from proprietary hardware and EMSs to Open hardware and the disaggregation of network devices, abstraction and services along with the introduction of SDN, NFV and Edge Networks creates new challenges and opportunities to enhance the platform.

With the increase of rapid deployment and management of new network services within CoSPs network, the dynamic scale-in/out controls are playing a crucial role to maintain the resiliency of critical services with optimal level of performance and resource utilization while responding to the changing packet processing demand in a live network. Furthermore the 5G Network Slicing, Edge Cloud and Cloud Native use cases put an immense pressure on CoSPs network to efficiently manage the production services. In the past, the SW based controls have been introduced in VIM managers with the dynamic discovery of resources to deploy next VNF instance, but with limited control over HW resources. Using latest Redfish compliant APIs, it is possible to extend closed-loop automation capabilities from Orchestration to deployment ready HW resource. In order to use these dynamic controls, the Orchestrator must be aware of workload types and communicate the policy to the VIM Manager to maintain a closed-loop control framework. Such framework should be capable of performing these essential tasks: Mapping Telemetry events to an Action, Dispatching Actions to workload deployment flow including HW bring-up or tear-down, Updating available HW resources to inventory database. The proposed framework is a generic design which can incorporate the aforementioned tasks for managing scalable workloads in NFV Cluster.

Real time data event streaming and real time event processing is becoming a critical need for industry transformation. Geo-Distributed data synchronization and Edge based intelligent processing is becoming a key need as edge based influx of data is growing by leaps and bounds. Intelligently processing this data, taking control actions, pushing meaningful data upstream becomes a must. SDN and IoT transformation to help in deploying a loosely coupled easily plug and play architecture, like the asynchronous pub/sub requirements for microservices are some of the key drivers. Business use cases of edge IoT networks; social networking and ‘internet of everything’ are going to propel this edge growth. This presentation covers a proposal and related concepts with tie into tooling needed to achieve this goal. The proposed feature can enhance the ONAP platform capabilities to support emerging technologies such as IoT, 5G, etc. for building and operating cloud native applications and services.

ONAP is central coordinator of end-to-end network service orchestration. Any security issues of ONAP deployment can disrupt operations in a significant way. Micro service based architecture, large number of services, scale-out of these services and possible deployment of some services at the edge could add to security challenges. Trusted infrastructure is needed - to enable secure communications among micro services with auto certificate enrolment - to keep private keys, secrets secure from adversaries and - to eliminate passwords proliferation across micro services, file systems and configuration files. This presentation discusses security challenges and potential solutions related to X.509v3 certificate enrolment, secure private key storage, secure cryptography execution, secure password storage and attestation of underlying platform/OS. It also discusses hardware technologies that help in providing root of trust for both key management and attestation. And then it discusses how ONAP can be augmented with these security solutions without disrupting the ONAP architecture.

Beijing Release will focus on S3P capabilities. As a result, it is important to define a clear test strategy to validate that both components and the full ONAP platform are S3P compliant. OPNFV has defined a full test framework covering functional tests, performances tests for the NFVI (Network Function Virtualization Infrastructure) . ONAP R1 mainly focused on functional tests and end-to-end tests according to the use-cases. Based on OPNFV experience and ONAP Release1, this session will propose a test strategy for Beijing Release.

While Beijing release will be focused on making ONAP carrier grade. Ease of Operations would be presumably integral part of Beijing release strategy. We have thought about several operational aspects that are listed below and intend to present during sessions in Santa Clara. Please feel free to get in touch; happy to have short call if required to explain the rational. Look forward to have our proposal accepted. a. CBR (Configuration, Backup and Restore) Solution - This Solution Proposes to Build Vendor/Service agnostic config management platform which will enable the current ONAP Platform to support config versioning, backup and config restoration features by leveraging underlying Controller platform. This platform will also add support for config comparison which would allow to compare two different version of configuration and highlight the delta and keeps the track of changes, this would also help in debugging the configuration output in case the applied configuration is not giving expected output. b. Pre-certification Solution - This Solution Proposes to Build Vendor/Service agnostic Pre-test/Service Certification platform to enable Application/Network level validation with automated workflow, test automation engine, analytics and result dashboard for end user Device and Service Certification. This platform will automate various test for L1-L3 layer validation and L4-L7 validation and health check by leveraging controller framework before moving customer premises equipment into production or before being monitored via DCAE. c. VNF Config Flexibility - This Solution Proposes to Build Vendor Agnostic generic VBS (Velocity Builder System) based custom config engine to generate VNF/PNF Configurations which will be built on CBR platform. These Config templates will be triggered by CBR Platform based on VNF/PNF type (Input received via MSO or A&AI) via controller platform. The generic configuration will have initial/base config to establish network connectivity and global configuration for initializing VNF/PNF. The rationale behind this is to reduce Vendor dependency for VNF config templates by building vendor agnostic generic configuration engine. d. Hybrid Provisioning - This Solution Proposes to Build Vendor Agnostic generic VBS based custom configuration engine to support Legacy CPE Configurations (on Physical Network Function) which will be built on CBR platform. This Configuration templates will be triggered by CBR Platform based on CPE type (Input received via MSO or A&AI) via controller platform or direct interface thru CBR Platform. The solution is to enable hybrid support to current platform by enabling current platform to support provisioning of legacy devices. e. QoS Engine - The solution proposes to build QoS Engine to store the generic QoS policies for network function type created by SD&C during design time and provide a specific QoS policy to Network controller during execution based on customer requirements that it gets from MSO. QoS Engine will have algorithms to instantiate QoS policies for a network function based on generic QoS policies; it holds during design time. And, specific customer requirements that it gets from Network controller during execution time f. Inventory Navigator - This solution proposes to build an intuitive GUI on top of ONAP A&AI component that is easily pluggable into ONAP to provide unified view of physical and virtual objects and their relationships. This UI should provide end 2 end view of Customer to Cloud i.e. Customer à customer subscription à service Instance à VNF à VM à Physical Infra

With concepts such as edge computing, use of NFV technologies and related management principles are now being deployed almost end to end in telecommunication networks. But for some applications there is still a need to deploy physical network functions (PNFs) or appliances even further out in the network. In this presentation we will look at options for integrating management of PNFs in a NFV-centered management and automation platform such as ONAP, supporting design, instantiation and operation of hybrid network services combining PNFs and virtual functions.

In the ONAP Amsterdam Release, the VNF Function Test did not transfer from OPEN-O to ONAP. In this presentation, the implementation in OPEN-O will be introduced and hope to find a best way to merge into ONAP Beijing Release.

Cloud Native is a term that describes the patterns of organizations, architectures and technologies that consistently, reliably and at scale take full advantage of the possibilities of the cloud to support cloud-oriented business models. In this paradigm the Cloud Native Applications are developed specifically for deployment in and being managed by cloud environments, delivering on the characteristics associated with cloud. They are container packaged, dynamically managed and micro-service oriented, resulting in better reuse, simplified and cost effective operations and improved efficiency, agility and maintainability. Virtual Network functions are taking their first steps towards Cloud Native Architecture and this poses several interesting challenges for automation platforms like ONAP. The VNFs would now be composing of several microservices each of which can be individually lifecycle managed. Container orchestration platforms like Kubernetes have powerful orchestration capabilities which would takes away most of the burden from higher level orchestrator. The Cloud Native Ecosystem has rich set of solutions for monitoring and optimizing a cloud native deployment which are becoming de-facto standards very fast. In this talk we discuss the implications of Cloud Native VNFs on ONAP and some suggestions on how should the ONAP architecture be evolved to be ready for Cloud Native VNFs.