Page Status: Done

Last Reviewed on:

Certified by: @Byung-Woo Jun 

Purpose of this wiki

The purpose of this wiki is to have the architecture text that needs to be modified.  The source of this is the London  Architecture in read-the-docs. 

The text should be release independent, then copied back to read-the-docs.

Architecture text

.. 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 collection of Network Automation functions, including orchestration,
management, and automation of network and edge computing services for network
operators, cloud providers, and enterprises. Its real-time, policy-driven
orchestration and automation of physical, virtual, and cloud native network
functions enable rapid deployment of new services and comprehensive lifecycle
management. These capabilities are critical for 5G and next-generation networks,
enhanced by genAI/ML.

The ONAP projects address the growing need for common network automation
functions among telecommunication, cable, and cloud service providers, along
with their solution providers. They enable the delivery of differentiated network
services on demand, profitably and competitively, while maximizing existing
investments. The challenge that ONAP addresses is helping network operators manage the scale
and cost of manual changes required to implement new service offerings-ranging
from installing new data center equipment to, in some cases, upgrading
on-premises customer equipment. Many operators aim to leverage SDN and NFV to
accelerate service delivery, simplify equipment interoperability and integration,
and reduce overall CapEx and OpEx costs. Furthermore, the highly fragmented
management landscape makes it challenging to monitor and guarantee
service-level agreements (SLAs).
ONAP addresses these challenges by developing global and large-scale (multi-site
and multi-VIM/multi-Cloud) automation capabilities for physical, virtual, and
cloud-native network elements. It enhances service agility by supporting
data models for rapid service and resource deployment, and offering a common
set of northbound REST APIs, enabling model-driven interfaces to the networks.

ONAP's modular and layered architecture improves interoperability and simplifies
integration, allowing it to support multiple VNF environments by integrating with
various and multiple VIMs, VNFMs, SDN Controllers, and legacy equipment (PNF).
The Service Design & Creation (SDC) project further enables seamless orchestration
of CNFs. Additionally, ONAP's consolidated xNF requirements publication facilitates
the 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 the integration and deployment costs of heterogeneous
equipment-all while minimizing minimizing management fragmentation.
The ONAP enables end-user organizations and their network or cloud providers to
collaboratively instantiate network elements and services in a rapid and dynamic
manner. It also supports a closed control loop process, enabling real-time response
to actionable events. To design, engineer, plan, bill and assure these dynamic services,
three major requirements must be met: - A robust design function that enables the comprehensive specification of the service,
including modeling the resources and relationships that constitute the service,
defining the policy rules guiding the service behavior, specifying the applications,
analytics and closed control loop events for the elastic management of the service - An orchestration and control function (Service Orchestrator and Controllers) that
operates in a recipe- and policy-driven manner to automate service instantiation
as needed, while dynamically and elastically managing service demands - An analytic function that continuously monitors the service behavior throughout the service lifecycle, using the specified design, analytics and policies. It enables
the control framework to respond as needed, addressing situations ranging from
healing issues to scaling resources to accommodate demand variations To achieve this, ONAP separates the specifics of individual services and supporting technologies from the common information models, core orchestration platform, and generic management engines (e.g., for discovery, provisioning, assurance).
Furthermore, it combines the speed and flexibility of a DevOps/NetOps approach with the formal models and processes required by operators 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
approach contrasts sharply with traditional OSS/Management software platform
architectures, which relied on hardcoded services and technologies and required
lengthy software development and integration cycles to accommodate changes. The ONAP network automation provides service- and resource-independent capabilities
for design, creation, and lifecycle management, adhering to 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 requiring new platform software releases or disrupting operations for the
existing services - Scalability and distribution designed to support a large number of services and
extensive networks - A metadata-driven and policy-driven architecture that ensures the flexible and automated utilization and delivery of capabilities - The architecture that facilitates the integration of best-in-class components - Common capabilities developed once and used many times - Core capabilities designed to support a wide range of services and
infrastructure types Furthermore, ONAP includes a functional architecture with defined component and
interfaces, fostering industry alignment in addition to open source code.

Architecture Overview --------------------- The ONAP architecture consists of design time and run time functions, as well
as functions for managing ONAP itself.

Note: Use the interactive features of the ONAP Architecture Overview below.
Click to enlarge the figure, then hover your mouse over an element for a short
description. Click on an element to access a more detailed description |image1|



**Figure 1: a high-level view of the ONAP architecture and its microservice-based components.
Click to enlarge and explore.**


ONAP Streamlining Evolution
---------------------------

ONAP Streamlining goals are:

- To continue to support use cases efficiently for deployment in commercial production
environments and portfolios
- To enable the industry to select desired ONAP component functions, replace certain ONAP
functions, and seamlessly integrate those functions into their portfolios without requiring
the full platform
- To streamline ONAP by driving individual components and clusters of components guided
by use cases, allowing the industry to adopt functions flexibly and dynamically

Directions
^^^^^^^^^^

- Connecting ONAP, O-RAN, Nephio and other communities to achieve larger objectives
- Reusing selected ONAP functions for efficiency and consistency
- Functional delegations to distribute responsibilities effectively

Obstacles, Observations, Challenges and Resolutions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

- ONAP components were primarily designed for ONAP-specific consumption
- If a component is not utilized by ONAP use cases, it risks becoming obsolete
or unmaintained rather than being graduated
- ONAP component-specific features may be overlooked if they are not utilized
by other ONAP components
- Resolutions: ONAP component functions should be designed for use not only ONAP
but also in non-ONAP environments
- Component design should be generic and extensible in a way that would enable
it to be used in non-ONAP
- If components are more generally applicable, there is the potential to gain
more traction
- Component dependencies and couplings to other ONAP components are structured in
an ONAP-specific manner
- Those dependencies and couplings can be both syntactic and semantic
- Many intra-ONAP component interfaces and communications are ONAP-specific
- Limited APIs standardization efforts are in place, such ETSI MANO APIs,
ASD, 3GPP
- Resolutions: Making each ONAP component 'stand-alone' emphasizes to potential
users that they can adopt individual components without committing to the entire
ONAP
- Deviating from standards complicates integration with other systems, particularly
non-ONAP systems
- Resolutions: Aligning with standards where possible should be a global requirement
- Resolutions: If deviations are necessary, they should be implemented in an
extensible manner that supports a standard-based approach
- CI build and integration processes for vendors/operators might be less compatible
with ONAP's. Some vendor/operators do not use OOM. In certain cases, a vendor
maintains an entirely separate set of Helm charts for ONAP components
- Resolutions: Component Helm charts in OOM have been rewritten to support the
individual build and deployment of components, leveraging LFN-compliant CI/CD
- Vendor- or operator-specific security and logging requirements may vary, leading to
integration challenges.
- Resolutions: The ONAP security framework, based on Service Mesh, Ingress, and
Keycloack, supports vendor- and operator-neutral security
- The timelines and cadence of ONAP releases are inflexible, making it challenging to
accommodate different release strategies
- It is not possible to create a 'Release' in JIRA for individual component releases
- Branching strategies are not aligned with ONAP's CMO (Current Mode of Operation)
- This misalignment results in an artificial split in functionality between releases
- Resolutions: The ONAP Streamlining release management supports agile and dynamic
component lifecycles

ONAP Streamlining Target Architecture
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

- Modularity & independent management: Support for stand-alone components
- Interface abstraction & loose coupling: Including standardization wherever possible
- Extensibility & interchangeability: Design for adaptability and flexibility
- Scalability: Allowing the addition, update and deletion of components without disruption
- Autonomous self management: Components manage themselves independently
- Design for general use: Suitable for both ONAP and non-ONAP consumers
- Conformance to industry standards: Adhering to security and logging best practices
- Clustering components by use cases: Grouping components based on specific use case
requirements
- Best component selection: Choosing the optimal components for specific tasks
- Responsive integration and delivery: Ensuring seamless integration and timely delivery
- Reference automation: ONAP can still provide reference automation for coordination

See the Resources page on '<ONAP Streamlining Evolution>'-

Component Function Summary
--------------------------

Note: The following components are deprecated as of the Oslo release:

- Message Bus (MSB)
- VNF SDK
- VVP
- External APIs
- CLI
- Correlation Engine (Holmes)
- Virtual Function Controller (VFC)
- OOF
- Model Utilities
- NBI
- DMaaP






Simplified and Individual Functional Overview of the Architecture
-----------------------------------------------------------------

Figure 2 below provides a simplified functional view of the architecture, highlighting the role of key components: #. ONAP Design time environment: Used for onboarding services and resources
into ONAP and designing required services #. External API (this is deprecated): Previously provided northbound
interoperability for ONAP
#. ONAP Runtime environment: Model- and policy-driven orchestration
and control functions enabling the automated instantiation and configuration
of services and resources. Multi-VIM/Cloud ensures cloud interoperability for
ONAP workloads. It also includes an Analytic framework that closely monitors
service behavior and handles closed-loop control for dynamic handling healing,
scaling and updates #. OOM (ONAP Operations Manager): Manages cloud-native installation and deployments in Kubernetes-managed cloud environments #. ONAP Shared Services: Provides shared capabilities for ONAP modules. The ONAP
Optimization Framework (OOF) (this is deprecated) previously provided a
declarative, policy-driven approach for creating and running optimization
applications like homing/placement and change management scheduling. The Security
Framework uses open-source security tools and patterns, such as Istio, Ingress
Gateway, oauth2-proxy, and Keycloak, to secure external and inter-component
communications, as well as 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. ONAP applications handle log generation only, while the
Logging Framework stack manages the rest. This design enables operators to
leverage or extend their existing logging stacks
#. ONAP shared utilities provide utility tools to support ONAP components
The information Model and framework utilities continue to evolve to harmonize topology, workflow, and policy models from various SDOs, including ETSI NFV MANO,
TM Forum SID, 3GPP, ONF Core, OASIS TOSCA, IETF, and MEF.

|image2|




**Figure 2. A simplified functional view of the ONAP architecture ** Microservices Support --------------------- As a cloud-native application consisting of numerous services, ONAP requires sophisticated initial deployment as well as post-deployment management. Its deployment methodology must be flexible enough to accommodate various
scenarios and purposes across diverse operator environments. Users may also choose to integrate only a subset of ONAP components into their own systems. Additionally, the platform must be highly reliable, scalable,
secure, and easy to manage.

To meet these objectives, ONAP is designed as a microservices-based system,
with all components packaged as Docker containers, adhering to best practice
for optimizing image size. Various optimizations, such as shared databases
and the use of standardized lightweight container operating systems, help
minimize ONAP's overall 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 utilizes Kubernetes with IPv4 and IPv6 support to ensure CPU
efficiency and platform deployment. Additionally, OOM enhances the ONAP
components maturity by providing scalability and resiliency improvements for
the components it manages. As the lifecycle manager of the ONAP functions, OOM uses the Kubernetes container management system and Consul to provide the following functionalities: #. Deployment: Built-in component dependency management, including support for multiple clusters, federated deployments across sites, and anti-affinity rules #. Configuration: Unified configuration across all ONAP components #. Monitoring: Real-time health monitoring integrated with a Consul GUI and Kubernetes #. Restart: Automatic restart of failed ONAP components #. Clustering and Scaling: Enables clustering of ONAP services for seamless scaling #. Upgrade: Facilitates containers or configuration updates with minimal or no service disruption #. Deletion: - Allows for clean up of individual containers or entire deployments OOM supports a wide variety of cloud infrastructures to meet diverse requirements,
making it a versatile and robust solution for managing the ONAP functions.


Security Framework
^^^^^^^^^^^^^^^^^^
Starting with the Istanbul-R9 release, OOM provides Service Mesh-based mTLS
(mutual TLS) to secure communication between ONAP components, by leveraging Istio.
This new security mechanism, implemented under the Security Framework, replaces
the previously unmaintained AAF functionalities, resulting in AAF is deprecated.

In addition to Service Mesh-based mTLS, Security Framework provides inter-component
authentication and authorization using Istio Authorization Policy. For external secure
communication, including authentication (with 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'.

The Microservices Bus (MSB) previously provided fundamental microservices support,
including service registration/ discovery, external API gateway, internal API
gateway, client software development kit (SDK), and Swagger SDK. When integrated
with OOM, MSB featured a Kube2MSB registrar, which extracted services information
from Kubernetes metafile and automatically registered services for ONAP components.

Since the London release, ONAP Security Framework components have provided secure
communication capabilities, offering a more Kubernetes-native. Consequently, MSB
had been replaced by the Security Framework, making MSB becomes an obsolete ONAP
component. In alignment with the global of leveraging microservice capabilities, further steps
have been taken to increase modularity. The Service Orchestrator (SO) and controllers
have enhanced their level of modularity to better align with the microservices
architecture.
Portal ------

.. warning:: The ONAP :strong: 'portal' project is :strong:'unmaintained'.

Note: A new Portal-NG replaces the existing Portal.
ONAP provides a unified, consistent user experience across design-time and runtime environments, tailored to the user's role. Role changes are configured within a single ONAP instance. This experience is managed through the ONAP
Portal, which grants access to design, analytics, and operational
control/administration functions via a shared, role-based menu or dashboard.

The portal architecture previously offered web-based capabilities such as
application onboarding and management, centralized access management through
the Authentication and Authorization Framework (AAF), dashboards, and hosted
application widgets. It also provided an SDK to ensure consistent UI development
across multiple teams, leveraging built-in capabilties (Services/ API/ UI
controls), tools, and technologies.

For operators who require it, ONAP used to include a Command Line Interface (CLI),
allowing integration with scripting environments. Additionally, ONAP SDKs used to
enable operations, security, third parties (e.g., vendors and consultants), and
other experts to define and redefine new collections, analytics, and policies (including recipes for corrective or remedial actions) through the ONAP Design Portal function.

Portal-NG
---------

Portal-NG is a GUI platform function that enables the integration of various ONAP
GUIs into a centralized portal. It offers the following features:

- The ability for ONAP components to run within their own infrastructure while
providing centralized management services and capabilities
- Common functionalities such as application onboarding and management,
centralized access management, hosting application widgets, context-aware
UI controls, and a visualization and reporting engine
- SDK capabilities for accessing portal functionalities
- Multi-language support

Portal-NG supports administrative roles for managing the Portal-NG itself and
the on-boarded applications. From the ONAP Portal-NG, administration can:

- Access all functionalities available to regular users
- Manage users and application administrators
- Onboard applications and widgets
- Edit the functional menu

Design Time Components ====================== The design time components serve as comprehensive development environments,
providing tools, techniques, and repositories for defining and describing
resources, services, and products. These components enable the reuse of
models, improving efficiently as more models become available over time. 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) to control behavior and process execution. Process specifications
automatically handle the sequencing of instantiation, delivery and lifecycle
management for resources, services, products and the ONAP components.

Some process specifications (i.e., recipes™) and policies are geographically
distributed to optimize performance and enhance autonomous behavior in
federated cloud environments.
Service Design and Creation (SDC)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Service Design and Creation (SDC) provides tools, techniques, and repositories for defining, simulating, and certifying system assets along with their associated
processes and policies. Each asset is categorized into one of four asset groups:
Resources, Services, Products, or Offers.

SDC supports the onboarding of various package types, including:
- 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)
- PNF packages (ETSI SOL004)

SDC also includes capabilities for modeling 5G network slicing using the standard
properties such as the Slice Profile and Service Template.

Since Kohn-R11 release, SDC supports onboarding of additional CNF-Modeling
package: the Application Service Description (ASD) package. ASD serves as a
deployment descriptor for cloud-native applications and functions. It minimizes
the information required by referencing most resource descriptions directly to
the cloud-native artifacts (e.g., Helm Charts). Its CSAR package adheres to
ETSI SOL004.

The SDC environment supports a diverse range of users through common services
and utilities. Using the design studio, product and service designers onboard,
extend, or retire resources, services and products. Operations teams, engineers,
customer experience managers, and security experts create workflows, policies
and methods to implement closed loop automation and manage elastic scalability.
Vendors can integrate these tools into their CI/CD environments to package VNFs,
CNFs and PNFs, and upload them to the validation engine. Once tested, the VNFs,
CNFs and PNFs can be onboarded through SDC.

The Policy Creation component handles policies, which include rules, conditions, requirements, constraints, attributes, or needs that must be provided, maintained, or enforced. At a technical level, policies consist of machine-readable rules that enable actions to be triggered based on specific conditions or requests.
Policies often consider the conditions in effect, both in triggering specific
policies and in selecting the appropriate outcomes based on those conditions. Policies enable rapid modification by allowing rules to be updated easily, thus
altering the technical behaviors of the components using those policies without requiring software code rewrites. This abstraction simplifies the management and control of complex systems. VNF SDK
^^^^^^^
.. warning:: The ONAP :strong: 'VNF SDK' project is :strong:'deprecated'.

The VNF SDK previously provided functionality for creating VNF/PNF packages,
testing VNF packages for ONAP compliance, storing VNF/PNF packages, and
uploading or downloading to or from a marketplace.

VVP
^^^
.. warning:: The ONAP :strong: 'VVP' project is :strong:'deprecated'.

The VVP previously provided validation for VNF Heat packages.

Runtime Components ------------------ The runtime execution components execute the rules, policies and other
models distributed by the design and creation environment. This enables for the distribution of models and policies across various ONAP
modules, including the Service Orchestrator (SO), Controllers, Data Collection,
Analytics, and Events (DCAE), CPS, Policy Framework and Active and Available
Inventory (A&AI). These ONAP components rely on common services for security
(access control, secure communication), and logging. Orchestration ^^^^^^^^^^^^^ The Service Orchestrator (SO) component automates processes by executing of
activities, tasks, rules and policies necessary for the on-demand creation,
modification or removal of network, application or infrastructure services
and resources. This includes VNFs, CNFs and PNFs, while adhering to industry
standards such as ETSI, 3GPP, TMF and others.

The SO provides high-level orchestration with an end-to-end perspective on
infrastructure, network, and applications. Examples include BroadBand Service
(BBS) and Cross Domain and Cross Layer VPN (CCVPN).

The SO is modular and hierarchical, designed to manage services and multi-level
resources, and network slicing. It achieves this by leveraging pluggable adapters
and delegating orchestration operations to components such as NFVO (e.g., SO NFVO,
VFC - deprecated), VNFM, CNF Manager, MSMF (Network Slice Management Function),
and NSSMF (Network Slice Subnet Management Function).

Starting from the Guilin release, the SO provides CNF orchestration support
through the integration of a CNF adapter in ONAP SO. Key features included:

- Support for provisioning CNFs using an external Kubernetes Manager
- Helm-based orchestration support
- Utilization of the CNF Adapter to interact with the Kubernetes (K8S) plugin
in MultiCloud
- Leveraging the capabilities of the K8S orchestrator
- Preparing the groundwork for cloud-native scenarios

In the London release, ONAP SO introduced ASD-based CNF orchestration support
to simplify CNF orchestration and eliminate redundancies in CNF resource attributes
and orchestration process. Key features include:

- Support for ASD-based CNF models and packages
- Introduction of the 'SO CNFM' sub-component for dedicated ASD-based CNF orchestration,
ensuring separation of concerns by isolating ASD management from other SO components
- Use of ASD for Application Service Lifecycle Management (AS LCM) and associated
Helm Charts for CNF deployment to selected external Kubernetes (K8S) clusters
- Use of the Helm Client for communicating with external K8S clusters during
deployment
- Monitoring of deployed K8S resources via Kubernetes APIs

3GPP (TS 28.801) defines a three-layer slice management function consisting of:

- CSMF (Communication Service Management Function)
- NSMF (Network Slice Management Function)
- NSSMF (Network Slice Subnet Management Function)

These three layers can be implemented within ONAP or through external CSMF, NSMF,
or NSSMF components. For ONAP-based network slice management, different
implementation options are available. Currently, ONAP orchestration supports
options #1 and #4.

|image 4|

**Figure 4: ONAP Networking Slicing Support Options**

Virtual Infrastructure Deployment (VID)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. warning:: The ONAP :strong:'vid' project is :strong:'deprecated'.
.. warning:: The ONAP :strong:'vid' component is no longer part of the ONAP
deployment from the London release.

The Virtual Infrastructure Deployment (VID) application previously allowed
users to instantiate infrastructure services from SDC, along with their
associated components, and perform change management operations, such as
scaling and software upgrades, on existing VNF instances.
Policy-Driven Workload Optimization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. warning:: The ONAP :strong:'OOF' project is :strong:'deprecated'.
The ONAP Optimization Framework (OOF) previously offered a policy-driven
and model-driven framework for developing optimization applications for a wide
range of use cases. The OOF Homing and Allocation Service (HAS) was a policy
driven workload optimization service that enabled the optimized placement of
services across multiple sites and clouds. This optimization was based on a
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, previously leveraged OOF-HAS for "Policy-driven Performance/Security-Aware
Adaptive Workload Placement/Scheduling" across cloud sites. OOF-HAS utilizes
cloud-agnostic intent capabilities and real-time capacity checks provided
by ONAP MC to determine the optimal VIM/Cloud instances. These instances are
selected to meet required performance SLAs for workload (e.g., VNF) placement
and scheduling (Homing).

This approach enables operators to realize the true value of virtualization
by optimizing cloud resources at a fine-grained level while ensuring performance
and security SLAs are met.
Controllers ^^^^^^^^^^^
Controllers are applications coupled with cloud and network services that execute configurations, enforce real-time policies, and manage the state of distributed components and services. Instead of relying on a single monolithic control layer, operators can use multiple distinct controller types to manage resources in their specific execution domains, such as cloud computing
resources (SDN-C).

.. warning:: The ONAP :strong:'appc' project is :strong:'deprecated'.
.. warning:: The ONAP :strong:'VF-C' project is :strong:'deprecated'.

The Virtual Function Controller (VF-C) and SO NFVO previously provided an
ETSI NFV-compliant NFV-O function responsible for the lifecycle management of
virtual services and the associated physical COTS server infrastructure. VF-C
previously offered generic VNFM capabilities, and both VF-C and SO NFVO integrate
with external VNFMs and VIMs as part of the NFV MANO stack.

ONAP includes an application-level configuration and lifecycle management module
called SDN-C. SDN-C provides services for application-level configuration (using
tools like NetConf, Chef, Ansible, RestConf, etc.) and lifecycle management
functions (e.g., Stop, resume, health check). SDN-C shares leverages common code
from the CCSDK repository.

However, there are key differences between these two modules. SDN-C uses CDS
exclusively for onboarding and configuration/LCM flow design.

SDN-C has been used for Layer1-7 network elements. This distinction is somewhat
loose, and over time, better alignment is expected, leading to a common repository
for controller code that supports application-level configuration and lifecycle
management of all network elements (physical or virtual, layer 1-7).

The ONAP Controller Family (SDN-C) configures and maintains the health of L1-7
Network Function (VNF, PNF, CNF) and network services throughout their lifecycle.
Key capabilities include:

- Configure Network Functions (VNF/CNF/PNF)
- Provides programmable network application management platform:
- Behavior patterns defined via models and policies
- Standards-based models and protocols for multi-vendor implementations
- Extensible southbound adapters, such as Netconf, Ansible, Rest API, etc.
- Operational control, version management, software updates, and more
- Local source of truth
- Manages inventory within its scope
- Tracks and stores the state of network functions
- Supports for configuration audits

Controller Design Studio (CDS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The Controller Design Studio (CDS) community in ONAP has contributed a
framework to automate resource resolution for instantiation and configuration
provisioning operations, such as Day-0, Day-1 or Day-2 configurations. The
core function of CDS is to create and populate a controller blueprint,
generate a configuration file from this blueprint, and associate this
configuration file (configlet) with a PNF, VNF, or CNF during the
design phase.

CDS eliminates dependence on code releases and the delays they introduce,
empowering service providers to have greater control over their services.
Users can modify models and their parameters with flexibility, allowing
them to retrieve data from external systems (e.g., IPAM) required for
real-world deployments. This approach enables service providers to be more
responsive to their customers' needs and deliver tailored solutions that
better meet customer expectations.


Inventory
^^^^^^^^^
Active and Available Inventory (A&AI) provides real-time views of a system's
resources, services, products, and their relationships, while also maintaining
a historical view. A&AI integrates data managed by multiple ONAP instances,
Business Support Systems (BSS), Operation Support Systems (OSS), and network
applications to create a comprehensive 'top to bottom' view. This view spansfrom the products purchased by end users to the underlying resources that serveas the building blocks for those products. A&AI serves not only as a registry for products, services, and resources butalso as a dynamic database that maintains up-to-date relationships betweenthese inventory items. To support the agility required by SDN/NFV, A&AI is updated in real-time by controllers as changes occur in the network environment. Additionally, A&AI is metadata-driven, enabling the dynamic and rapid additionof new inventory types via SDC catalog definitions. This approach eliminatesthe need for lengthy development cycles, allowing for faster adaptation to evolving network and service requirements.Policy Framework ^^^^^^^^^^^^^^^^ The ONAP Policy Framework is a comprehensive function for policy design, deployment, and execution. It serves as the decision-making component within an ONAP system, enabling the specification, deployment, and governance offeatures and functions. These can include closed-loop automation, orchestration,or traditional open-loop use case implementations. The Policy Framework actsas the single source of truth for all policy decisions.Since the Istanbul release, the CLAMP was officially integrated into thePolicy component. CLAMP's role in provisioning policies has been expanded toinclude support for policy provisioning outside the context of a control loop,effectively functioning as a Policy UI. For more details, refer to the Policy - CLAMP section below. Closed Control Loop Automation Management Platform Function in Policy (Policy - CLAMP) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Closed-loop control in ONAP is achieved through the collaboration of various design-time and run-time elements. The runtime loop begins with data collectors from the Data Collection, Analytics and Events (DCAE) module. ONAP provides thefollowing collectors: - VES (VNF Event Streaming) for events- HV-VES for high-volume events - SNMP Collector for SNMP traps- File Collector for file-based data ingestion- Restconf Collector for receiving notificationsAfter the data collection and verification phase, the data flows through a series of microservices, such as Homes for event detection, Policy for determining appropriate actions, and controllers and orchestrators for implementing those actions. The Policy framework also monitors these loops and manages their lifecycle.DCAE includes specialized microservices for specific use cases, such as Slice Analysis and the SON-Handler. Dedicated event processor modules transform collected data (e.g., SNMP, 3GPP XML, RESTCONF) into VES format and push it intothe data lake. At the design stage, CLAMP, Policy, and DCAE provide tools to support the creation of closed-loop processes, ensuring seamless integration and execution.This automation pattern is referred to as 'Closed Control Loop Automation' as it provides the necessary automation to proactively respond to network and service conditions without human intervention. A high-level schematic of 'Closed Control Loop Automation' and its various phases within the service lifecycle is shown in Figure 5. Closed control loop functionality is enabled by Data Collection, Analytics, and Events (DCAE) in conjunction with other ONAP runtime components. Together, theydeliver FCAPS (Fault Configuration Accounting Performance Security) functionality.DCAE collects performance, usage, and configuration data; computes analytics; aids in troubleshooting; and publishes events, data and analytics to componentssuch as Policy, Orchestration, and the Data Lake.Additionally, the Holmes component connects to DCAE to provide alarm correlationfor ONAP, enhanced data collection capabilities with High Volume VES, and bulk performance management support. Working with the Policy Framework (and the embedded CLAMP), these components detect network issues and determine the appropriate remediation. In some cases, actions are executed automatically by notifying the Service Orchestrator or a controller. In other cases, as configured by the operator, an alarm is raisedto require human intervention before executing changes. The policy Framework has been extended with adaptive policy execution to enhance its decision-making capabilities.From the Honolulu-R8 release to the Istanbul-R9 release, the CLAMP component was successfully integrated into the Policy Framework component. Initially introducedas a proof of concept in the Honolulu-R8 release, it became a fully integratedcomponent within the Policy Framework component in the Istanbul-R9 release.CLAMP's role in policy provisioning has been expanded to support policies outsidethe context of a Control Loop, effectively serving as a Policy UI. The integrationof CLAMP into the Policy Framework was officially completed in the Istanbulrelease. |image5|**Figure 5: ONAP Closed Control Loop Automation**Data Collection Analytics and Events (DCAE)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^DCAE provides capabilities for event collection and hosting analytics applications(DCAE Services). It collects performance, usage, and configuration data fromthe managed environment. This data is processed by various analytic applications, and when anomalies or significant events are detected, the results trigger appropriateactions, such as publishing to other ONAP components such as Policy, SO, orControllers.Key capabilities include:- Collecting, ingesting, transforming and storing data as needed for analysis- Providing a framework for the development of analytics applicationsMulti Cloud Adaptation^^^^^^^^^^^^^^^^^^^^^^ Multi-VIM/Cloud provides an infrastructure adaptation layer for VIMs/Cloudsand Kubernetes (K8s) clusters. It exposes advanced cloud-agnostic intent capabilities, in addition to standard capabilities, which are utilized by OOF(deprecated) and other components for enhanced cloud selection, as well as SO and/or VF-C (deprecated) for cloud-agnostic workload deployment.The K8s plugin is responsible for deploying CNFs on Kubernetes clusters usingKubernetes APIs.Virtual Function Controller (VFC)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^.. warning:: The ONAP :strong: 'VFC' project is :strong:'deprecated'.VFC previously provided NFVO capabilities to manage the lifecycle of network services and VNFs in compliance with the ETSI NFV specification.Data Movement as a Platform (DMaaP)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^.. warning:: The ONAP :strong: 'DMaaP' project is :strong:'deprecated'.DMaaP previously provided data movement services for transporting and processing data from any source to any target. Its message routing functionality was deprecated in New Delhi release, with Strimzi and Kafka replacing it. In the Oslo release, the remaining DMaaP sub-component, Data Routing, was also deprecated. Use Case UI (UUI)^^^^^^^^^^^^^^^^^UUI provides the capability to instantiate blueprint use cases and visualize their state. It serves as an application portal that enables the management of ONAP service instances. Customers can create, delete and update service instances, as well as to monitor their alarms and performance.The component supports the following functionalities:- Customer Interaction Management- Package Management (includes IBN packages)- Service Instance Management (includes CCVPN, 5G Slicing, Intent-based automation)- Blueprint Instantiation, handling blueprint use cases instantiation- Model As A Service (MaaS) for dynamic generative AI modeling services to enhance ONAP's genAI; for more details, see <>'-- Monitoring and Visualization (includes 5G slicing monitor and other events)- Network Topology VisualizationUUI contains the following sub-components:- UUI GUI- UUI Server- UUI NLP Server (since Istanbul release)- UUI INTENT ANALYSIS Server (since Kohn release)- LLM-Adaptation- DatabaseConfiguration Persistence Service (CPS)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^The Configuration Persistence Service (CPS) provides storage for real-timerun-time configuration and operational parameters that need to be used by ONAP.Several services ranging from SDN-C, DCAE and the network slicing use caseutilize CPS for these purposes. Its details in:ref:'CPS - Configuration Persistence Service<onap-cps:architecture>'.CLI^^^.. warning:: The ONAP :strong:'CLI' project is :strong:'deprecated'. ONAP CLI previously provided a command-line interface for accessing ONAP.External APIs^^^^^^^^^^^^^.. warning:: The ONAP :strong:'externalapi' project is :strong:'deprecated'.External APIs were previously used to expose ONAP capabilities.Shared Services ---------------.. warning:: The ONAP :strong:'Logging Framework' project is a reference implementation PoC.ONAP offers a set of operational services for all ONAP components, including activity logging, reporting, common data layer, configuration, data persistence,access control, secret and credential management, resiliency, and softwarelifecycle management. ONAP Shared Services provide shared capabilities for ONAP modules, such as access management, security enforcement, and logging. Optimization Framework (OOF)^^^^^^^^^^^^^^^^^^^^^^^^^^^^.. warning:: The ONAP :strong:'OOF' project is :strong:'deprecated'.The Optimization Framework (OOF) previously offered a declarative, policy-driven approach for creating and executing optimization applications, such as like Homing/Placement and Change Management Scheduling Optimization. Security Framework ^^^^^^^^^^^^^^^^^^The Security Framework utilizes open-source security patterns and tools, including Istio, Ingress Gateway, oauth2-proxy, and Keycloak. It ensures secure external and inter-component communications, as well as authentication and authorization. See the Figure 3. Security Framework component architecture for its architecture.Logging Framework (PoC)^^^^^^^^^^^^^^^^^^^^^^^.. warning:: The ONAP :strong:'Logging Framework' project is a reference implementation PoC. The Logging Framework supports open-source- and standard-based logging. It separates application log generation from log collection, aggregation, persistence, visualization, and analysis. In this setup, ONAP applications focus solely onlog generation, while the Logging Framework stack manages the remaining processes. This approach allows operators to leverage or extend their own logging stacks. ONAP Modeling ------------- .. warning:: The ONAP :strong:'ONAP Modeling' project is :strong:'deprecated'.ONAP previously provided models to assist with service design, the development of ONAP service components, and the enhancement of standards interoperability. Models are a critical component of both the design time and runtime framework development. The ONAP modeling project leverages the expertise of member companies, standard organizations, and other open source projects to create models that are simple, extensible, and reusable. The goal is to meet the requirements of various use cases, guide the development,ensure consistency across ONAP components, and explore a common model to enhanceONAP interoperability. ONAP supports various models, as detailed in the Modeling documentation. Since the Kohn release, a new CNF modeling descriptor, the Application Service Description (ASD), has been introduced. This addition simplifies CNF modeling and orchestration by delegating resource modeling to Kubernetes-based resourcedescriptors, such as Helm Charts. The modeling project previously supported the ETSI catalog component, which offered parser functionalities and additional package management capabilities. Industry Alignment ------------------ONAP's support for and collaboration with other standards and open-source communities is evident in its architecture: - MEF and TMF Interfaces: Utilization in the External APIs - ETSI-NFV Models: In addition to the VNFD and NSD models defined by ETSI-NFV, ONAP supports NFVO interfaces, including: - SOL 005: Between the SO and VFC/SO-NFVO- SOL 003: From either the SO (thru SOL003 Adapter) or VFC to an external VNFM- Application Service Descriptor (ASD): The ASD v1.0 specification for CNF is approved, and promoted as an O-RAN standard- 3GPP Interfaces and LLM services: These are utilized in the UUI and other genAI capable components Read this white paper for more information: 'The Progress of ONAP: Harmonizing Open Source and Standards <https://www.onap.org/wp-content/uploads/sites/20/2019/04/ONAP_HarmonizingOpenSourceStandards_032719.pdf>'- ONAP Blueprints ---------------ONAP can support an unlimited number of use cases, within reason. To provide concrete examples of how ONAP can solve real-world problems, the community has developed a set of blueprints. These blueprints not only help users quickly adopt the ONAP capabilities through end-to-end solutions but also assist the community in prioritizing their work. 5G Blueprint ^^^^^^^^^^^^The 5G blueprint is a multi-release initiative focused on the following key areas:end-to-end service orchestration, network slicing, PNF/VNF lifecycle management,PNF integration, and network optimization. This blueprint addresses the unique requirements brought by the combination of eMBB (promising peak data rates of 20 Mbps), uRLLC (guaranteeing sub-millisecond response times), mMTC (supporting 0.92 devices per square foot(, and network slicing. First, ONAP must manage the lifecycle of a network slice from creation and activation to deactivation and termination. Additionally, ONAP needs to optimize the network using real-time and bulk analytics, place VNFs on the appropriate edge cloud, scale and heal services, and enable edge automation. ONAP also provides self organizing network (SON) services, such as physical cell ID allocation for new RAN sites.These requirements have driven the five initiatives mentioned above and weredeveloped in close collaboration with standards and open-source organizations,including 3GPP, TM Forum, ETSI, and O-RAN alliance.|image6|**Figure 6. End-to-end 5G Service** Read the 5G Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_5G_062519.pdf>'-to learn more.A related initiative outside of ONAP is the 5G Super Blueprint, wheremultiple Linux Foundation projects collaborate to demonstrate an end-to-end 5G network. In the short term, this blueprint will showcase three major projects: ONAP, Anuket (K8S NFVI), and Magma (LTE/5GC).|image 7|** Figure 7. 5G Super Blueprint Initial Integration Activity**In the long-term, the 5G Super Blueprint will also integrate O-RAN-SC and LF Edgeprojects.Residential Connectivity Blueprints ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Two ONAP blueprints, vCPE and BBS, address the residential connectivity use case. Virtual CPE (vCPE) """""""""""""""""" Currently, the services offered to a subscriber are limited to those built intothe broadband residential gateway. In the blueprint, the customer is provided with a slimmed-down physical CPE (pCPE) connected to a traditional broadband network, such as DSL, DOCSIS, or PON (Figure 6). A tunnel is then established to a data center hosting various VNFs, offering a significantly broader rangeof services to the subscriber at a much lower cost of the operator.This blueprint leverages ONAP to support the complex orchestration and management of open-source VNFs, as well as both virtual and underlay connectivity. |image8| **Figure 8. ONAP vCPE Architecture** Read the 'Residential vCPE Use Case with ONAP blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_vCPE_112918FNL.pdf>'- Broadband Service (BBS) """"""""""""""""""""""" This blueprint provides multi-gigabit residential internet connectivity services using PON (Passive Optical Network) access technology. A key feature of this blueprint is the automatic re-registration of an ONT (Optical Network Terminal) when the subscriber moves (nomadic ONT) or changes their service subscription plan. This blueprint leverages ONAP for the design, deployment, lifecycle management, and service assurance of broadband services. Additionally, it demonstrates howONAP can orchestrate services across different locations (e.g., Central Office, Core) and technology domains (e.g., Access, Edge). |image9| **Figure 9. ONAP BBS Architecture** Read the 'Residential Connectivity Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_BBS_062519.pdf>'-to learn more. Voice over LTE (VoLTE) Blueprint ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^This blueprint leverages ONAP to orchestrate a Voice over LTE service. Itincorporates commercial VNFs to create and manage the underlying vEPC and vIMS services by interworking with vendor-specific components, including VNFMs, EMSs, VIMs and SDN controllers, across Edge Data Centers and a Core Data Center. ONAP supports the VoLTE use case with several key components: SO, VF-C, SDN-C, and Multi-VIM/ Cloud. In this blueprint, SO is responsible for end-to-end VoLTEservice orchestration, collaborating with VF-C and SDN-C. SDN-C establishes network connectivity, while the VF-C component completes Network Services and VNF lifecycle management, including service initiation, termination and manualscaling, and FCAPS (Fault, Configuration, Accounting, Performance, Security) management. This blueprint also demonstrates advanced functionalities such as scaling and change management. |image10| **Figure 10. ONAP VoLTE Architecture Open Network Automation Platform** Read the 'VoLTE Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNF.pdf>'-to learn more. Optical Transport Networking (OTN)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Two ONAP blueprints, CCVPN and MDONS, address the OTN use case. CCVPN focuseson Layers 2 and 3, while MDONS targets Layers 0 and 1.CCVPN (Cross Domain and Cross Layer VPN) Blueprint """"""""""""""""""""""""""""""""""""""""""""""""""CSPs, such as CMCC and Vodafone, are experiencing strong demand for high-bandwidth,flat, high-speed OTN (Optical Transport Networks) across carrier networks. They also aim to offer high-speed, flexible and intelligent services for high-value customers, as well as instant and adaptable VPN services for SMB companies. |image11| **Figure 11. ONAP CCVPN Architecture** The CCVPN (Cross Domain and Cross Layer VPN) blueprint combines SOTN (Super high-speed Optical Transport Network) with ONAP, leveraging ONAP's orchestrationcapabilities to achieve unified management and scheduling of resources and services.It enables cross-domain orchestration and ONAP peering across service providers. In this blueprint, SO handles end-to-end CCVPN service orchestration in collaboration with VF-C and SDN-C. SDN-C establishes network connectivity, while VF-C component manages the Network Services and VNF lifecycle. ONAP peering across CSPs is facilitated through an east-west API, which is aligned with the MEF Interlude API. CCVPN, together with the IBN use case, provides intent-based cloud leased line services. Key innovations in this use case include:- Physical network discovery and modeling- Cross-domain orchestration across multiple physical networks- Cross-operator end-to-end service provisioning and close-loop rerouting for cross-domain services- Support for dynamic changes (.e.g., branch sites, VNFs)- Intelligent service optimization leveraging AI/ML technologies Read the 'CCVPN Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_CCVPN_062519.pdf>'-to learn more.MDONS (Multi-Domain Optical Network Service) Blueprint""""""""""""""""""""""""""""""""""""""""""""""""""""""While CCVPN addresses the automation of networking layers 2 and 3, it does notcover layers 0 and 1. Automating these layers is equally important, as providingend-to-end services often involves manual and complex negotiation between CSPs,including both the business arrangement and actual service design and activation. Additionally, CSPs may operate multiple networks independently, requiring similartransactions among their own networks and business units to deliver end-to-end services. The MDONS blueprint, developed by AT&T, Orange, and Fujitsu, addresses this challenge. When used together, MDONS and CCVPN provide a comprehensive solutionto the OTN automation problem. |image12|**Figure 12. ONAP MDONS Architecture**Intent Based Network (IBN) Use Case^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Intent technology can simplify network management by abstracting the intricatedetails of the underlying network infrastructure, contributing to more efficient operations. This use case provides a valuable business function by reducing management operating expenses (OPEX) through a paradigm shift from complex procedural operations to declarative intent-driven operations.|image 13|**Figure 13. ONAP Intent-Based Networking Use Case**3GPP 28.812, Intent driven Management Service (Intent driven MnS), defineskey concepts utilized in this initiative. The Intent-Based Networking (IBN) use case includes the development of an intent-driven decision-making mechanism. This use case was initially demonstrated in a smart warehouse scenario, where the intent is to increase the output volume of automated guided vehicles (AVG),with the network automatically scaling in response.The Intent UI is implemented in UUI, and the components of the intent framework interact with various ONAP components, including SO, A&AI, Policy, DCAE, and CDS.vFW/vDNS Blueprint ^^^^^^^^^^^^^^^^^^The virtual firewall, virtual DNS blueprint is a basic demonstration to verify the correct installation of ONAP and to provide a basic introduction to itscapabilities. The blueprint consists of five VNFs: vFW, vPacketGenerator, vDataSink, vDNS and vLoadBalancer. It exercises most aspects of ONAP, includingVNF onboarding, network service creation, service deployment, and closed-loop automation. Key ONAP components involved in this blueprint are SDC, Policy, SO, and DCAE. In recent releases, the vFW blueprint has been demonstrated using a mix of CNFs and VNFs, as well as entirely with CNFs.Verified end to end tests-------------------------Use cases^^^^^^^^^Various use cases have been tested for the release. Examples of these use casesare listed below. Detailed information on use cases, functional requirements,and automated use cases can be found here::doc:'Verified Use Cases<onap-integration:docs_usecases_release>'.- xNF Integration- ONAP CNF Orchestration - Enhancements- ONAP ASD-Based CNF Orchestration- PNF Pre-Onboarding- PNF Plug & Play- Lifecycle Management- Policy-Based Filtering- Bulk PM / PM Data Control Extension- Support for xNF Software Upgrade in Association with Schema Updates- Configuration & Persistency Service- Security- CMPv2 Enhancements- Service Mesh- Istio Gateway- Authentication and Authorization Leveraging KeyCloak- Standard alignment- ETSI-Alignment- ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES- Extend ORAN A1 Adapter and add A1 Policy Management- Striving to align with Linux AI & Data and GenAI Commons (in Research)