...
.. This work is licensed under a Creative Commons Attribution
.. 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017-2018 Huawei Technologies Co., Ltd.
.. Copyright 2019 ONAP Contributors
.. _ONAP-architecture:
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 is 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 is 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 is
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 service
- 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 manner
- 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 ONAP architecture consists of a design time and run time functions, as well as functions for
managing ONAP itself.
**Figure 1 provides a high-level view of the ONAP architecture with its microservices-based platform components.**
|image1|
Architecture overview navigation portal: https://safratech.net/onapdocs21/action_page.php?release=istanbul&doc_type=arch-overview
Component Function Summary
==========================
Simplified Functional View of the 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.
#. ONAP Runtime environment provides a model-and policy-driven
orchestration and control framework for an automated instantiation and
configuration of services and resources. Multi-VIM/Cloud provides cloud
interoperability for the ONAP workloads. Analytic framework that closely
monitors the service behavior handles closed control loop management for
handling healing, scaling and update dynamically.
#. 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 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.
|image2|
Image Added
Image Removed
**Figure 2. Functional view of the ONAP architecture**
Microservices Support
=====================
As a cloud-native application that consists of numerous services, ONAP requires
sophisticated initial deployment as well as post- deployment management.
The ONAP deployment methodology needs to be flexible enough to suit the
different scenarios and purposes for various operator environments. Users may
also want to select a portion of the ONAP components to integrate into their
own systems. And the platform needs to be highly reliable, scalable, secure and
easy to manage. To achieve all these goals, ONAP is designed as a
microservices-based system, with all components released as Docker containers
following best practice building rules to optimize their image size. To reduce
the ONAP footprint, a first effort to use shared data base have been initiated
with a Cassandra and mariadb-galera clusters.
The ONAP Operations Manager (OOM) is responsible for orchestrating the
end-to-end lifecycle management and monitoring of ONAP components. OOM uses
Kubernetes to provide CPU efficiency and platform deployment. In addition, OOM
helps enhance ONAP platform maturity by providing scalability and resiliency
enhancements to the components it manages.
OOM is the lifecycle manager of the ONAP platform and uses the Kubernetes
container management system and Consul to provide the following functionality:
#. Deployment - with built-in component dependency management (including
multiple clusters, federated deployments across sites, and anti-affinity
rules)
#. Configuration - unified configuration across all ONAP components
#. Monitoring - real-time health monitoring feeding to a Consul GUI and
Kubernetes
#. Restart - failed ONAP components are restarted automatically
#. Clustering and Scaling - cluster ONAP services to enable seamless scaling
#. Upgrade - change out containers or configuration with little or no service
impact
#. Deletion - clean up individual containers or entire deployments
OOM supports a wide variety of cloud infrastructures to suit your individual
requirements.
Microservices Bus (MSB) provides fundamental microservices supports including
service registration/ discovery, external API gateway, internal API gateway,
client software development kit (SDK), and Swagger SDK. When integrating with
OOM, MSB has a Kube2MSB registrar which can grasp services information from k8s
metafile and automatically register the services for ONAP components.
In the spirit of leveraging the microservice capabilities, further steps
towards increased modularity have been taken in the Dublin release. Service
Orchestrator (SO) and the controllers have increased its level of modularity.
Portal
======
ONAP delivers a single, consistent user experience to both design time and
runtime environments, based on the user's role. Role changes are configured
within a single ONAP instance.
This user experience is managed by the ONAP Portal, which provides access to
design, analytics and operational control/administration functions via a
shared, role-based menu or dashboard. The portal architecture provides
web-based capabilities such as application onboarding and management,
centralized access management through the Authentication and Authorization
Framework (AAF), and dashboards, as well as hosted application widgets.
The portal provides an SDK to enable multiple development teams to adhere to
consistent UI development requirements by taking advantage of built-in
capabilities (Services/ API/ UI controls), tools and technologies. ONAP also
provides a Command Line Interface (CLI) for operators who require it (e.g., to
integrate with their scripting environment). ONAP SDKs enable
operations/security, third parties (e.g., vendors and consultants), and other
experts to continually define/redefine new collection, analytics, and policies
(including recipes for corrective/remedial action) using the ONAP Design
Framework Portal.
Design Time Framework
=====================
The design time framework is a comprehensive development environment with
tools, techniques, and repositories for defining/ describing resources,
services, and products.
The design time framework facilitates reuse of models, further improving
efficiency as more and more models become available. Resources, services,
products, and their management and control functions can all be modeled using
a common set of specifications and policies (e.g., rule sets) for controlling
behavior and process execution. Process specifications automatically sequence
instantiation, delivery and lifecycle management for resources, services,
products and the ONAP platform components themselves. Certain process
specifications (i.e., recipes™) and policies are geographically distributed
to optimize performance and maximize autonomous behavior in federated cloud
environments.
Service Design and Creation (SDC) provides tools, techniques, and repositories
to define/simulate/certify system assets as well as their associated processes
and policies. Each asset is categorized into one of four asset groups:
Resource, Services, Products, or Offers. SDC also supports TOSCA1.3 List type
definition in Dublin release which provides the ability to design complicated
service descriptor.
The SDC environment supports diverse users via common services and utilities.
Using the design studio, product and service designers onboard/extend/retire
resources, services and products. Operations, Engineers, Customer Experience
Managers, and Security Experts create workflows, policies and methods to
implement Closed control Loop Automation/Control and manage elastic
scalability.
To support and encourage a healthy VNF ecosystem, ONAP provides a set of VNF
packaging and validation tools in the VNF Supplier API and Software Development
Kit (VNF SDK) and VNF Validation Program (VVP) components. Vendors can
integrate these tools in their CI/CD environments to package VNFs and upload
them to the validation engine. Once tested, the VNFs can be onboarded through
SDC. In addition, the testing capability of VNFSDK is being utilized at the
LFN Compliance Verification Program to work towards ensuring a highly
consistent approach to VNF verification.
The Policy Creation component deals with policies; these are rules, conditions,
requirements, constraints, attributes, or needs that must be provided,
maintained, and/or enforced. At a lower level, Policy involves machine-readable
rules enabling actions to be taken based on triggers or requests. Policies
often consider specific conditions in effect (both in terms of triggering
specific policies when conditions are met, and in selecting specific outcomes
of the evaluated policies appropriate to the conditions).
Policy allows rapid modification through easily updating rules, thus updating
technical behaviors of components in which those policies are used, without
requiring rewrites of their software code. Policy permits simpler management
/ control of complex mechanisms via abstraction.
Runtime Framework
=================
The runtime execution framework executes the rules, policies and models that are
distributed by the design and creation environment.
This allows for the distribution of models and policy among
various ONAP modules such as the Service Orchestrator (SO), Controllers,
Data Collection, Analytics and Events (DCAE), Active and Available Inventory
(A&AI). These components use common services that
support logging, access control, Multi-Site State Coordination (MUSIC), which
allow the platform to register and manage state across multi-site deployments.
Orchestration
-------------
The Service Orchestrator (SO) component executes the specified processes by
automating sequences of activities, tasks, rules and policies needed for
on-demand creation, modification or removal of network, application or
infrastructure services and resources, this includes VNFs, CNFs and PNFs. The SO provides
orchestration at a very high level, with an end-to-end view of the infrastructure, network,
and applications.
One is BroadBand Service (BBS), the second one is Cross Domain and Cross Layer VPN
(CCVPN).
Virtual Infrastructure Deployment (VID)
---------------------------------------
The Virtual Infrastructure Deployment (VID) application enables users to
instantiate infrastructure services from SDC, along with their associated
components, and to execute change management operations such as scaling and
software upgrades to existing VNF instances.
Policy-Driven Workload Optimization
-----------------------------------
The ONAP Optimization Framework (OOF) provides a policy-driven and model-driven
framework for creating optimization applications for a broad range of use
cases. OOF Homing and Allocation Service (HAS) is a policy driven workload
optimization service that enables optimized placement of services across
multiple sites and multiple clouds, based on a wide variety of policy
constraints including capacity, location, platform capabilities, and other
service specific constraints.
ONAP Multi-VIM/Cloud (MC) and several other ONAP components such as Policy, SO,
A&AI, etc. play an important role in enabling Policy-driven
Performance/Security-Aware Adaptive Workload Placement/ Scheduling across
cloud sites through OOF-HAS. OOF-HAS uses Hardware Platform Awareness (HPA),
cloud agnostic Intent capabilities, and real-time capacity checks provided by
ONAP MC to determine the optimal VIM/Cloud instances, which can deliver the
required performance SLAs, for workload (VNF etc.) placement and scheduling
(Homing). Operators now realize the true value of virtualization through fine
grained optimization of cloud resources while delivering performance and
security SLAs.
Controllers
-----------
Controllers are applications which are coupled with cloud and network services
and execute the configuration, real-time policies, and control the state of
distributed components and services. Rather than using a single monolithic
control layer, operators may choose to use multiple distinct controller types
that manage resources in the execution environment corresponding to their
assigned controlled domain such as cloud computing resources (network
configuration (SDN-C) and application (App-C). The App-C and SDN-C also support the
Virtual Function Controller (VF-C) provides an ETSI NFV compliant NFV-O function that is
responsible for lifecycle management of virtual services and the associated
physical COTS server infrastructure. VF-C provides a generic VNFM capability
but also integrates with external VNFMs and VIMs as part of an NFV MANO stack.
ONAP has two application level configuration and lifecycle management modules
called SDN-C and App-C. Both provide similar services (application level
configuration using NetConf, Chef, Ansible, RestConf, etc.) and life cycle
management functions (e.g. Stop, resume, health check, etc.).
They share common code from CCSDK repo. However, there are some differences
between these two modules (SDN-C uses CDS only for onboarding and
configuration / LCM flow design, whereas App-C uses CDT for the LCM functions
for self service to provide artifacts storing in APP-C Database).
SDN-C has been used mainly for Layer1-3 network elements and App-C is
being used for Layer4-7 network functions. This is a very loose
distinction and we expect that over time we will get better alignment and
have common repository for controller code supporting application level configuration
and lifecycle management of all network elements (physical or virtual, layer 1-7).
Because of these overlaps, we have documented SDN-C and App-C together.
...
