...
The following diagram depicts Oslo ONAP Component Architecture:
ONAP Core Components
ONAP Core Component Interfaces and Relationships
| Gliffy | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Portal-NG : is a GUI platform provides the ability to integrate different ONAP GUIs
Use-Case UI (UUI) : provides the capability to instantiate the blueprint Use Cases and visualize the state. It also provides intent-based network management, leveraging genAI/ML
SDC : provides a design time tool for common model/catalog onboarding design and distribution
Policy Framework : provides the ability for the creation and management of policies. Its CLAMP (Closed Loop Automation Management Platform) provides the run-time control loop management
SO : Service Orchestrator and its modular sub-components provide the service orchestration, network service, network slicing and VFN/CNF/PNF in the ONAP architecture
AAI : provides real-time views of Resources and Services and their relationships. It also provides services to register externally used services
CPS : provides storage for real-time configuration and operational parameters
DCAE : provides the capability to collect events, and host analytics applications (supporting VES events)
Multi-VIM/Cloud : provides mediation capabilities to connect to different infrastructure providers (including K8s plugin for CNF)
CDS : is a framework to automate resource resolution for instantiation and configuration (Day 0, Day 1, Day 2)
CCSDK : provides a common set of reusable code that can be used across multiple controllers (for building/plug-in controller personas)
SDNC : provides a network controller capability for establishing network connections and configuring VNFs/CNFs. It is based on CCSDK
ONAP Core Component Interface Abstraction
ONAP component interfaces should be designed/used for/by not only ONAP but also non-ONAP.
ONAP component functions can be substituted and/or extended by vendors/operators
Component dependencies and couplings to other ONAP components should be removed.
Those dependencies and couplings could be both syntactic and semantic
Intra-ONAP component interfaces and communications should not be ONAP-specific.
Aligning with standards where possible (e.g., ETSI NFV MANO, ASD, 3GPP SA5…) should be global requirements
If there must be a deviation, that can be done in an extensible way that enables the standard-based approach
The exposed service interfaces should be for both ONAP and non-ONAP; promote ONAP component interfaces as LFN de facto standards
If exposed service interfaces conform to industry standards (e.g., ETSI SOL005, ETSI SOL003, 3GPP SA5), the interactions between the service provider and consumer would be simplified (e.g., VFC case in this diagram)
For now, the service consumers can use “adapters” which choose a desired service interface
Action Points:
Promote ONAP Component API models and interfaces as open-source de facto APIs
Event Handler / operator façade can be used trigger ONAP components as the previous slide
ONAP Shared Services
Security Framework : provides security capabilities for external and inter-component secure communications, authentication and authorization
Logging Framework (PoC) : provides general-purpose logging collection/aggregation/persistence/visualization, by leveraging open-source log collector, aggregator, database and visualizer (e.g., FluentBit, FluentD, ElasticSearch, Kibana)
...
Infrastructure Service supports the foundation of ONAP applications to run and includes computing, networking, storage, security and other essential resources. In ONAP, Service Mesh is placed in the Infrastructure Service layer for secured ONAP application communications
Service Mesh is an infrastructure layer to handle communication between microservices in a distributed system. In ONAP, Istio Service Mesh with Envoy proxies as the sidecars manages all incoming and outgoing network/application traffic for ONAP applications with mTLS, authentication and authorization
ONAP Core Component Use Cases and Integration
China Telecom Use Cases for Intent-Driven Closed Loop Autonomous Network
The following diagram depicts China Telecom use cases for Intent-driven closed loop autonomous network, where the core ONAP components are selected and integrated.
Huawei and China Mobile Incident API Enhancements
The following diagram depicts the Incident API enhancements by Huawei and China Mobile.
The management system is overwhelmed by the frequency and quantity of alarms, KPI, trace information with the growth of new service and service complexity.
Several incident reports/alarms could be collected and aggregated into a single incident
Repository-Based ONAP Core Integration (Future topic)
The following diagram depicts a possible CD/CD Repository-based Network Automation Choreography use cases.
...