3. Brief project overview

Notes to section editors:

Describe goals, technologies, key features, etc.
This chapter does not replace your project specific technical documentation
You may include a reference to your community wiki space.
Try to avoid references to specific time-dependent aspects of your project that might render this whitepaper obsolete quickly.
Please keep the length of your section to 1-2 pages.

3.1 FD.IO

Editor: Ole Troan

3.2 ONAP

(DRAFT)

Introduction

The ONAP project addresses the rising need for a common automation platform for telecommunication, cable, and cloud service providers—and their solution providers—to deliver differentiated network services on demand, profitably and competitively, while leveraging existing investments.

The challenge that ONAP meets is to help operators of telecommunication networks to keep up with the scale and cost of manual changes required to implement new service offerings, from installing new data center equipment to, in some cases, upgrading on-premises customer equipment. Many are seeking to exploit SDN and NFV to improve service velocity, simplify equipment interoperability and integration, and to reduce overall CapEx and OpEx costs. In addition, the current, highly fragmented management landscape makes it difficult to monitor and guarantee service-level agreements (SLAs). These challenges are still very real now as ONAP creates its fourth release.

ONAP is addressing these challenges by developing global and massive scale (multi-site and multi-VIM) automation capabilities for both physical and virtual network elements. It facilitates service agility by supporting data models for rapid service and resource deployment and providing a common set of northbound REST APIs that are open and interoperable, and by supporting model-driven interfaces to the networks. ONAP’s modular and layered nature improves interoperability and simplifies integration, allowing it to support multiple VNF environments by integrating with multiple VIMs, VNFMs, SDN Controllers, as well as legacy equipment (PNF). ONAP’s consolidated xNF requirements publication enables commercial development of ONAP-compliant xNFs. This approach allows network and cloud operators to optimize their physical and virtual infrastructure for cost and performance; at the same time, ONAP’s use of standard models reduces integration and deployment costs of heterogeneous equipment. All this is achieved while minimizing management fragmentation.

The ONAP platform allows end-user organizations and their network/cloud providers to collaboratively instantiate network elements and services in a rapid and dynamic way, together with supporting a closed control loop process that supports real-time response to actionable events. In order to design, engineer, plan, bill and assure these dynamic services, there are three major requirements:

A robust design framework that allows the specification of the service in all aspects – modeling the resources and relationships that make up the service, specifying the policy rules that guide the service behavior, specifying the applications, analytics and closed control loop events needed for the elastic management of the servic
An orchestration and control framework (Service Orchestrator and Controllers ) that is recipe/ policy-driven to provide an automated instantiation of the service when needed and managing service demands in an elastic manne
An analytic framework that closely monitors the service behavior during the service lifecycle based on the specified design, analytics and policies to enable response as required from the control framework, to deal with situations ranging from those that require healing to those that require scaling of the resources to elastically adjust to demand variations.

To achieve this, ONAP decouples the details of specific services and supporting technologies from the common information models, core orchestration platform, and generic management engines (for discovery, provisioning, assurance etc.). Furthermore, it marries the speed and style of a DevOps/NetOps approach with the formal models and processes operators require to introduce new services and technologies. It leverages cloud-native technologies including Kubernetes to manage and rapidly deploy the ONAP platform and related components. This is in stark contrast to traditional OSS/Management software platform architectures, which hardcoded services and technologies, and required lengthy software development and integration cycles to incorporate changes.

The ONAP Platform enables service/resource independent capabilities for design, creation and lifecycle management, in accordance with the following foundational principles:

Ability to dynamically introduce full service lifecycle orchestration (design ,provisioning and operation) and service API for new services and technologies without the need for new platform software releases or without affecting operations for the existing services
Carrier-grade scalability including horizontal scaling (linear scale-out) and distribution to support a large number of services and large networks
Metadata-driven and policy-driven architecture to ensure flexible and automated ways in which capabilities are used and delivered
The architecture shall enable sourcing best-in-class components
Common capabilities are ‘developed’ once and ‘used’ many times
Core capabilities shall support many diverse services and infrastructures

Further, ONAP comes with a functional architecture with component definitions and interfaces, which provides a force of industry alignment in addition to the open source code.

ONAP Architecture

The platform provides common functions such as data collection, control loops, meta-data recipe creation, and policy/recipe distribution that are necessary to construct specific behaviors.

To create a service or operational capability ONAP supports service/ operations-specific service definitions, data collection, analytics, and policies (including recipes for corrective/remedial action) using the ONAP Design Framework Portal.

Figure 1 below provides a high-level view of the ONAP architecture with its microservices-based platform components.

Figure 1

ONAP Functional Architecture

Figure 2 below, provides a simplified functional view of the architecture, which highlights the role of a few key components:

Design time environment for onboarding services and resources into ONAP and designing required services.
External API provides northbound interoperability for the ONAP Platform and Multi-VIM/Cloud provides cloud interoperability for the ONAP workloads
OOM provides the ability to manage cloud-native installation and deployments to Kubernetes-managed cloud environments.
ONAP Shared Services provides shared capabilities for ONAP modules. MUSIC allows ONAP to scale to multi-site environments to support global scale infrastructure requirements. The ONAP Optimization Framework (OOF) provides a declarative, policy-driven approach for creating and running optimization applications like Homing/Placement, and Change Management Scheduling Optimization. Logging provides centralized logging capabilities, Audit (POMBA) provides capabilities to understand orchestration actions.
ONAP shared utilities provide utilities for the support of the ONAP components.
Information Model and framework utilities continue to evolve to harmonize the topology, workflow, and policy models from a number of SDOs including ETSI NFV MANO, TM Forum SID, ONF Core, OASIS TOSCA, IETF, and MEF.

Figure 2

3.3 Open Daylight

Editor: Abhijit Kumbhare

3.4 Open Switch

Editor: Mike Lazar

3.5 OPNFV

Editor: Bin Hu

3.6 PNDA

Editor: <TBD>

3.7 SNAS