...
.. 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
.. Copyright 2020 ONAP Contributors
.. Copyright 2021 ONAP Contributors
.. Copyright 2022 ONAP Contributors
.. Copyright 2023 ONAP Contributors .. _ONAP-architecture: Architecture ============ ONAP is a comprehensive platform for orchestration, management, and automation
of network and edge computing services for network operators, cloud providers,
and enterprises. Real-time, policy-driven orchestration and automation of
physical, virtual, and cloud native network functions enables rapid automation
of new services and complete lifecycle management critical for 5G and
next-generation networks.
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 network operators 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 physical, virtual, and
cloud native 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). The Service Design & Creation
(SDC) project also offers seamless orchestration of CNFs. ONAP's consolidated
xNF requirements publication enables commercial development of ONAP-compliant
xNFs. This approach allows network and cloud operators to optimize their
physical, virtual and cloud native 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 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 APIs for new services and technologies without the need for new platform software releases or without affecting operations for the existing services - Scalability 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. Architecture Overview --------------------- The ONAP architecture consists of a design time and run time functions, as well
as functions for managing ONAP itself.
Note: Use the interaction features of the below ONAP Architecture Overview.
Click to enlarge it. Then hover with your mouse over an element in the
figure for a short description. Click the element to get forwarded to a more
detailed description |image1|
**Figure 1: a high-level view of the ONAP architecture with its
microservices-based platform components. Click to enlarge and discover.**
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
----------------------------------------------
The Figure 2 below, provides a simplified functional view of the architecture, which highlights the role of a few key components: #. ONAP Design time environment for onboarding services and resources
into ONAP and designing required services. #. External API provides northbound interoperability for the ONAP Platform. 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. 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. The Security Framework uses
open-source security patterns and tools, such as Istio, Ingress Gateway,
oauth2-proxy, and Keycloak. This security framework makes ONAP secure external
and inter-component communications, authentication and authorization.
Logging Framework (reference implementation PoC) supports open-source- and
standard-based logging. It separates application log generation from log
collection/aggregation/persistence/visualization/analysis; i.e., ONAP
applications handle log generation only and the Logging Framework stack will
handle the rest. As a result, operators can leverage/extend their own logging
stacks.
#. 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|
**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. Numerous
optimization such as shared databases and the use of standardized lightweight
container operating systems reduce the overall ONAP footprint.
ONAP Operations Manager (OOM)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The ONAP Operations Manager (OOM) is responsible for orchestrating the end-to-end lifecycle management and monitoring of ONAP components. OOM uses Kubernetes with IPv4 and IPv6 support 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.
Starting with the Istanbul-R9, as a PoC, OOM provides Service Mesh-based
mTLS (mutual TLS) between ONAP components to secure component communications,
by leveraging Istio. The goal is to substitute (unmaintained) AAF
functionalities.
In addition to Service Mesh-based mTLS, OOM provides inter-component
authentication and authorization, by leveraging Istio Authorization Policy.
For external secure communication, authentication (including SSO) and
authorization, OOM configures Ingress, oauth2-proxy, IAM (realized by
KeyCloak) and IdP.
|image3|
**Figure 3. Security Framework component architecture**
Microservices Bus (MSB)
^^^^^^^^^^^^^^^^^^^^^^^
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 London, ONAP Security Framework components provide secure communication
capabilities. This approach is more Kubernetes-native. As a result, MSB
will be replaced by the Security Framework, and MSB becomes an optional
component. In the spirit of leveraging the microservice capabilities, further steps towards increased modularity have been taken. Service Orchestrator (SO) and the
controllers have increased its level of modularity.
Portal ------
.. warning:: The ONAP :strong: 'portal' project is :strong:'unmaintained'.
Note: A new Portal-NG replaces the existing 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)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 the onboarding of Network
Services packages (ETSI SOL007 with ETSI SOL001), ONAP proprietary CNF packages
(embedding Helm Chart), ASD-based CNF packages (ETSI SOL004 and embedding Helm
Chart), VNF packages (Heat or ETSI SOL004) and PNF packages (ETSI SOL004). SDC
also includes some capabilities to model 5G network slicing using the standard
properties (Slice Profile, Service Template).
Since Kohn-R11 release, SDC supports the onboarding of another CNF-Modeling
package, Application Service Description (ASD) package. ASD is a deployment
descriptor for cloud native applications/functions. It minimizes information
needed for the CNF orchestrator, by referencing most resource descriptions to
the cloud native artifacts (e.g., Helm Chart). Its CSAR package adheres to
ETSI SOL004.
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. ONAP supports onboarding of CNFs and PNFs as
well.
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. VNF SDK
^^^^^^^
VNF SDK provides the functionality to create VNF/PNF packages, test VNF
packages and VNF ONAP compliance and store VNF/PNF packages and upload to/from
a marketplace.
VVP
^^^
VVP provides validation for the VNF Heat package.
Runtime Framework ----------------- The runtime execution framework executes the rules and policies and other
models 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
ONAP components use common services that support security (access control,
secure communication), logging and configuration data. 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,
by conforming to industry standards such as ETSI, TMF.
The SO provides orchestration at a very high level, with an end-to-end view
of the infrastructure, network, and applications. Examples of this include
BroadBand Service (BBS) and Cross Domain and Cross Layer VPN (CCVPN).
The SO is modular and hierarchical to handle services and multi-level
resources and Network Slicing, by leveraging pluggable adapters and delegating
orchestration operations to NFVO (SO NFVO, VFC), VNFM, CNF Manager, MSMF
(Network Slice Management Function), NSSMF (Network Slice Subnet Management
Function).
Starting from the Guilin release, the SO provides CNF orchestration support
through integration of CNF adapter in ONAP SO:
- Support for provisioning CNFs using an external K8S Manager
- Support the Helm-based orchestration
- Leverage the CNF Adapter to interact with the K8S Plugin in MultiCloud
- Bring in the advantage of the K8S orchestrator and
- Set stage for the Cloud Native scenarios
In London, ONAP SO added ASD-based CNF orchestration support to simplify
CNF orchestration and to remove redundancies of CNF resource attributes and
orchestration process.
- Support for ASD-based CNF models and packages
- Support the SO sub-component 'SO CNFM' for ASD-dedicated CNF orchestration
to isolate ASD management from other SO components - separation of concerns
- Use of ASD for AS LCM, and use of associated Helm Charts for CNF deployment
to the selected external K8S clusters
- Use of Helm Client to communicate with external K8S clusters for deployment
- Monitoring deployed K8S resources thru Kubernetes APIs
3GPP (TS 28.801) defines three layer slice management function which include:
- CSMF (Communication Service Management Function)
- NSMF (Network Slice Management Function)
- NSSMF (Network Slice Subnet Management Function)
To realize the three layers, CSMF, NSMF and/or NSSMF are realized within ONAP,
or use the external CSMF, NSMF or NSSMF. For ONAP-based network slice
management, different choices can be made as follows. Among them, ONAP
orchestration currently supports #1 and #4.
|image 4|
**Figure 4: ONAP Networking Slicing Support Options**
Virtual Infrastructure Deployment (VID)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. warning:: The ONAP :strong:'vid' project is :strong:'unmaintained'.
.. warning:: The ONAP :strong:'vid' component is no longer part of the ONAP
deployment from the London release.
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). The SDN-C also supports 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).
ONAP Controller Family (SDN-C) configures and maintains the health of L1-7 Network
Function (VNF, PNF, CNFs) and network services throughout their lifecycle
...