...
.. 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
.. Copyright 2024 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, with genAI/ML.
The ONAP project addresses the rising need for a common network automation
functions 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).
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 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 function 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 function (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 function 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 functionalities 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 network automation 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.**
ONAP Streamlining Evolution
---------------------------
ONAP Streamlining goals are:
- Support use cases efficiently for use in commercial production environment and portfolios
- Support pick and choose desired ONAP component functions, swap some of the ONAP functions,
integrate those functions into operators' portfolios seamlessly, without brining in a
whole ONAP functions
- Drive individual components and clusters of components guided by use cases, will enable
the flexible and dynamic function adoption by the industry
Directions
^^^^^^^^^^
- Connecting ONAP, O-RAN, Nephio and other communities for larger objectives
- Reuse of selected ONAP functions
- Functional delegations
Obstacles, Observations and Challenges
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Component Function Summary
--------------------------
Note: The following components are deprecated as of New Delhi:
- Message Bus (MSB)
- VNF SDK
- VVP
- External APIs
- CLI
- Correlation Engine (Holmes)
- Virtual Function Controller (VFC)
- OOF
- Model Utilities
- NBI
- DMaaP MR
Simplified and Individual 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 (this is deprecated) provides northbound interoperability for the ONAP. 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) (this is deprecated) 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, 3GPP, 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, security handling 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. This new security mechanism has replaced (unmaintained) AAF
functionalities. As a result, AAF is deprecated.
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)
^^^^^^^^^^^^^^^^^^^^^^^
.. warning:: The ONAP :strong: 'MSB' project is :strong:'deprecated'.
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
has been 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.
Portal-NG
---------
Portal-NG is a GUI platform that provides the ability to integrate different ONAP
GUIs into a centralized portal. It provides:
- The capability to allow other ONAP components to run within their own infrastructure
while providing common management services and capabilities in a centralized way
- Provides common capabilities such as application on-boarding and management,
centralized access management and hosting application widgets, Context-Aware
UIControls, Visualization & Reporting Engine
- Provides SDK capabilities to access portal capabilities
- Provides multi-language support
Portal-NG supports admin roles to perform administrative activities of Portal-NG
itself and the administration of on-boarded apps. From the ONAP Portal-NG,
administrators:
- access the same functionality accessible to users
- manage users and application admins
- onboard applications and widgets
- edit the functional menu
...