1 .. This work is licensed under a Creative Commons Attribution
2 .. 4.0 International License.
3 .. http://creativecommons.org/licenses/by/4.0
4 .. Copyright 2017-2018 Huawei Technologies Co., Ltd.
5 .. Copyright 2019 ONAP Contributors
6 .. Copyright 2020 ONAP Contributors
7 .. Copyright 2021 ONAP Contributors
8 .. Copyright 2022 ONAP Contributors
9 .. Copyright 2023 ONAP Contributors
11 .. _ONAP-architecture:
15 ONAP is a comprehensive platform for orchestration, management, and automation
16 of network and edge computing services for network operators, cloud providers,
17 and enterprises. Real-time, policy-driven orchestration and automation of
18 physical, virtual, and cloud native network functions enables rapid automation
19 of new services and complete lifecycle management critical for 5G and
20 next-generation networks.
22 The ONAP project addresses the rising need for a common automation platform for
23 telecommunication, cable, and cloud service providers—and their solution
24 providers—to deliver differentiated network services on demand, profitably and
25 competitively, while leveraging existing investments.
27 The challenge that ONAP meets is to help network operators keep up with the
28 scale and cost of manual changes required to implement new service offerings,
29 from installing new data center equipment to, in some cases, upgrading
30 on-premises customer equipment. Many are seeking to exploit SDN and NFV to
31 improve service velocity, simplify equipment interoperability and integration,
32 and to reduce overall CapEx and OpEx costs. In addition, the current, highly
33 fragmented management landscape makes it difficult to monitor and guarantee
34 service-level agreements (SLAs). These challenges are still very real now as
35 ONAP creates its eighth release.
37 ONAP is addressing these challenges by developing global and massive scale
38 (multi-site and multi-VIM) automation capabilities for physical, virtual, and
39 cloud native network elements. It facilitates service agility by supporting
40 data models for rapid service and resource deployment and providing a common
41 set of northbound REST APIs that are open and interoperable, and by supporting
42 model-driven interfaces to the networks. ONAP’s modular and layered nature
43 improves interoperability and simplifies integration, allowing it to support
44 multiple VNF environments by integrating with multiple VIMs, VNFMs, SDN
45 Controllers, as well as legacy equipment (PNF). The Service Design & Creation
46 (SDC) project also offers seamless orchestration of CNFs. ONAP’s consolidated
47 xNF requirements publication enables commercial development of ONAP-compliant
48 xNFs. This approach allows network and cloud operators to optimize their
49 physical, virtual and cloud native infrastructure for cost and performance;
50 at the same time, ONAP’s use of standard models reduces integration and
51 deployment costs of heterogeneous equipment. All this is achieved while
52 minimizing management fragmentation.
54 The ONAP platform allows end-user organizations and their network/cloud
55 providers to collaboratively instantiate network elements and services in a
56 rapid and dynamic way, together with supporting a closed control loop process
57 that supports real-time response to actionable events. In order to design,
58 engineer, plan, bill and assure these dynamic services, there are three major
61 - A robust design framework that allows the specification of the service in all
62 aspects – modeling the resources and relationships that make up the service,
63 specifying the policy rules that guide the service behavior, specifying the
64 applications, analytics and closed control loop events needed for the elastic
65 management of the service
66 - An orchestration and control framework (Service Orchestrator and Controllers)
67 that is recipe/ policy-driven to provide an automated instantiation of the
68 service when needed and managing service demands in an elastic manner
69 - An analytic framework that closely monitors the service behavior during the
70 service lifecycle based on the specified design, analytics and policies to
71 enable response as required from the control framework, to deal with
72 situations ranging from those that require healing to those that require
73 scaling of the resources to elastically adjust to demand variations.
75 To achieve this, ONAP decouples the details of specific services and supporting
76 technologies from the common information models, core orchestration platform,
77 and generic management engines (for discovery, provisioning, assurance etc.).
79 Furthermore, it marries the speed and style of a DevOps/NetOps approach with
80 the formal models and processes operators require to introduce new services and
81 technologies. It leverages cloud-native technologies including Kubernetes to
82 manage and rapidly deploy the ONAP platform and related components. This is in
83 stark contrast to traditional OSS/Management software platform architectures,
84 which hardcoded services and technologies, and required lengthy software
85 development and integration cycles to incorporate changes.
87 The ONAP Platform enables service/resource independent capabilities for design,
88 creation and lifecycle management, in accordance with the following
89 foundational principles:
91 - Ability to dynamically introduce full service lifecycle orchestration (design
92 , provisioning and operation) and service API for new services and
93 technologies without the need for new platform software releases or without
94 affecting operations for the existing services
95 - Scalability and distribution to support a large number of services and large
97 - Metadata-driven and policy-driven architecture to ensure flexible and
98 automated ways in which capabilities are used and delivered
99 - The architecture shall enable sourcing best-in-class components
100 - Common capabilities are ‘developed’ once and ‘used’ many times
101 - Core capabilities shall support many diverse services and infrastructures
103 Further, ONAP comes with a functional architecture with component definitions
104 and interfaces, which provides a force of industry alignment in addition to
105 the open source code.
107 Architecture Overview
108 ---------------------
110 The ONAP architecture consists of a design time and run time functions, as well
111 as functions for managing ONAP itself.
113 Note: Use the interactive features of the below ONAP Architecture Overview.
114 Click to enlarge it. Then hover with your mouse over an element in the
115 figure for a short description. Click the element to get forwarded to a more
116 detailed description.
118 .. image:: media/onap-architecture-overview-interactive-path.svg
121 **Figure 1: Interactive high-level view of the ONAP architecture with its
122 microservices-based platform components. Click to enlarge and discover.**
124 The figure below provides a simplified functional view of the architecture,
125 which highlights the role of a few key components:
127 #. ONAP Design time environment provides onboarding services and resources
128 into ONAP and designing required services.
129 #. External API provides northbound interoperability for the ONAP Platform.
130 #. ONAP Runtime environment provides a model- and policy-driven orchestration
131 and control framework for an automated instantiation and configuration of
132 services and resources. Multi-VIM/Cloud provides cloud interoperability for
133 the ONAP workloads. Analytic framework that closely monitors the service
134 behavior handles closed control loop management for handling healing,
135 scaling and update dynamically.
136 #. OOM provides the ability to manage cloud-native installation and deployments
137 to Kubernetes-managed cloud environments.
138 #. ONAP Shared Services provides shared capabilities for ONAP modules. The ONAP
139 Optimization Framework (OOF) provides a declarative, policy-driven approach
140 for creating and running optimization applications like Homing/Placement,
141 and Change Management Scheduling Optimization. The Security Framework uses
142 open-source security patterns and tools, such as Istio, Ingress Gateway,
143 oauth2-proxy, and Keycloak. This Security Framework makes ONAP secure external
144 and inter-component communications, authentication and authorization.
145 Logging Framework (reference implementation PoC) supports open-source- and
146 standard-based logging. It separates application log generation from log
147 collection/aggregation/persistence/visualization/analysis; i.e., ONAP
148 applications handle log generation only and the Logging Framework stack will
149 handle the rest. As a result, operators can leverage/extend their own logging
151 #. ONAP shared utilities provide utilities for the support of the ONAP components.
153 Information Model and framework utilities continue to evolve to harmonize
154 the topology, workflow, and policy models from a number of SDOs including
155 ETSI NFV MANO, ETSI/3GPP, O-RAN, TM Forum SID, ONF Core, OASIS TOSCA, IETF,
160 **Figure 2. Functional view of the ONAP architecture**
162 Microservices Support
163 ---------------------
164 As a cloud-native application that consists of numerous services, ONAP requires
165 sophisticated initial deployment as well as post- deployment management.
167 The ONAP deployment methodology needs to be flexible enough to suit the
168 different scenarios and purposes for various operator environments. Users may
169 also want to select a portion of the ONAP components to integrate into their
170 own systems. And the platform needs to be highly reliable, scalable, secure
171 and easy to manage. To achieve all these goals, ONAP is designed as a
172 microservices-based system, with all components released as Docker containers
173 following best practice building rules to optimize their image size. Numerous
174 optimizations such as shared databases and the use of standardized lightweight
175 container operating systems reduce the overall ONAP footprint.
177 ONAP Operations Manager (OOM)
178 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
179 The ONAP Operations Manager (OOM) is responsible for orchestrating the
180 end-to-end lifecycle management and monitoring of ONAP components. OOM uses
181 Kubernetes with IPv4 and IPv6 support to provide CPU efficiency and platform
182 deployment. In addition, OOM helps enhance ONAP platform maturity by providing
183 scalability and resiliency enhancements to the components it manages.
185 OOM is the lifecycle manager of the ONAP platform and uses the Kubernetes
186 container management system and Consul to provide the following functionality:
188 #. Deployment - with built-in component dependency management (including
189 multiple clusters, federated deployments across sites, and anti-affinity
191 #. Configuration - unified configuration across all ONAP components
192 #. Monitoring - real-time health monitoring feeding to a Consul GUI and
194 #. Restart - failed ONAP components are restarted automatically
195 #. Clustering and Scaling - cluster ONAP services to enable seamless scaling
196 #. Upgrade - change out containers or configuration with little or no service
198 #. Deletion - clean up individual containers or entire deployments
200 OOM supports a wide variety of cloud infrastructures to suit your individual
203 Starting with the Istanbul-R9, as a PoC, OOM provides Service Mesh-based
204 mTLS (mutual TLS) between ONAP components to secure component communications,
205 by leveraging Istio. The goal is to substitute (unmaintained) AAF
208 In addition to Service Mesh-based mTLS, OOM also provides inter-component
209 authentication and authorization, by leveraging Istio Authorizaiton Policy.
210 For external secure communication, authentication (including SSO) and
211 authorization, OOM configures Ingress, oauth2-proxy, IAM (realized by
216 **Figure 3. Security Framework component architecture**
219 Microservices Bus (MSB)
220 ^^^^^^^^^^^^^^^^^^^^^^^
221 Microservices Bus (MSB) provides fundamental microservices support including
222 service registration/ discovery, external API gateway, internal API gateway,
223 client software development kit (SDK), and Swagger SDK. When integrating with
224 OOM, MSB has a Kube2MSB registrar which can grasp services information from k8s
225 metafile and automatically register the services for ONAP components.
227 In London release, ONAP Security Framework components provide secure communication
228 capabilities. This approach is a more Kubernetes-native approach. As a result, MSB
229 functions will be replaced by the Security Framework, and MSB becomes an optional
232 In the spirit of leveraging the microservice capabilities, further steps
233 towards increased modularity have been taken. Service Orchestrator (SO) and the
234 controllers have increased its level of modularity.
239 .. warning:: The ONAP :strong:`portal` project is :strong:`unmaintained`.
241 ONAP delivers a single, consistent user experience to both design time and
242 runtime environments, based on the user’s role. Role changes are configured
243 within a single ONAP instance.
245 This user experience is managed by the ONAP Portal, which provides access to
246 design, analytics and operational control/administration functions via a
247 shared, role-based menu or dashboard. The portal architecture provides
248 web-based capabilities such as application onboarding and management,
249 centralized access management through the Authentication and Authorization
250 Framework (AAF), and dashboards, as well as hosted application widgets.
252 The portal provides an SDK to enable multiple development teams to adhere to
253 consistent UI development requirements by taking advantage of built-in
254 capabilities (Services/ API/ UI controls), tools and technologies. ONAP also
255 provides a Command Line Interface (CLI) for operators who require it (e.g., to
256 integrate with their scripting environment). ONAP SDKs enable operations/
257 security, third parties (e.g., vendors and consultants), and other experts to
258 continually define/redefine new collection, analytics, and policies (including
259 recipes for corrective/remedial action) using the ONAP Design Framework Portal.
261 Design Time Framework
262 ---------------------
263 The design time framework is a comprehensive development environment with
264 tools, techniques, and repositories for defining/ describing resources,
265 services, and products.
267 The design time framework facilitates reuse of models, further improving
268 efficiency as more and more models become available. Resources, services,
269 products, and their management and control functions can all be modeled using a
270 common set of specifications and policies (e.g., rule sets) for controlling
271 behavior and process execution. Process specifications automatically sequence
272 instantiation, delivery and lifecycle management for resources, services,
273 products and the ONAP platform components themselves. Certain process
274 specifications (i.e., ‘recipes’) and policies are geographically distributed to
275 optimize performance and maximize autonomous behavior in federated cloud
278 Service Design and Creation (SDC)
279 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
280 Service Design and Creation (SDC) provides tools, techniques, and repositories
281 to define/simulate/certify system assets as well as their associated processes
282 and policies. Each asset is categorized into one of four asset groups: Resource
283 , Services, Products, or Offers. SDC supports the onboarding of Network
284 Services packages (ETSI SOL007 with ETSI SOL001), ONAP proprietary CNF packages
285 (embedding Helm Chart), ASD-based CNF packages (ETSI SOL004 and embedding Helm
286 Chart), VNF packages (Heat or ETSI SOL004) and PNF packages (ETSI SOL004). SDC
287 also includes some capabilities to model 5G network slicing using the standard
288 properties (Slice Profile, Service Template).
290 Since Kohn-R11 release, SDC supports the onboarding of another CNF-Modeling
291 package, Application Service Description (ASD) package. ASD is a deployment
292 descriptor for cloud native applications/functions. It minimizes information
293 needed for the CNF orchestrator, by referencing most resource descriptions to
294 the cloud native artifacts (e.g., Helm Chart). Its CSAR package adheres to
297 The SDC environment supports diverse users via common services and utilities.
298 Using the design studio, product and service designers onboard/extend/retire
299 resources, services and products. Operations, Engineers, Customer Experience
300 Managers, and Security Experts create workflows, policies and methods to
301 implement Closed Control Loop Automation/Control and manage elastic
304 To support and encourage a healthy VNF ecosystem, ONAP provides a set of VNF
305 packaging and validation tools in the VNF Supplier API and Software Development
306 Kit (VNF SDK) and VNF Validation Program (VVP) components. Vendors can
307 integrate these tools in their CI/CD environments to package VNFs and upload
308 them to the validation engine. Once tested, the VNFs can be onboarded through
309 SDC. In addition, the testing capability of VNFSDK is being utilized at the LFN
310 Compliance Verification Program to work towards ensuring a highly consistent
311 approach to VNF verification. ONAP supports onboarding of CNFs and PNFs as
314 The Policy Creation component deals with policies; these are rules, conditions,
315 requirements, constraints, attributes, or needs that must be provided,
316 maintained, and/or enforced. At a lower level, Policy involves machine-readable
317 rules enabling actions to be taken based on triggers or requests. Policies
318 often consider specific conditions in effect (both in terms of triggering
319 specific policies when conditions are met, and in selecting specific outcomes
320 of the evaluated policies appropriate to the conditions).
322 Policy allows rapid modification through easily updating rules, thus updating
323 technical behaviors of components in which those policies are used, without
324 requiring rewrites of their software code. Policy permits simpler
325 management / control of complex mechanisms via abstraction.
329 VNF SDK provides the functionality to create VNF/PNF packages, test VNF
330 packages and VNF ONAP compliance and store VNF/PNF packages and upload to/from
335 VVP provides validation for the VNF Heat package.
339 The runtime execution framework executes the rules and policies and other
340 models distributed by the design and creation environment.
342 This allows for the distribution of models and policy among various ONAP
343 modules such as the Service Orchestrator (SO), Controllers, Data Collection,
344 Analytics and Events (DCAE), Active and Available Inventory (A&AI). These
345 components use common services that support security (access control,
346 secure communication), logging and configuration data.
350 The Service Orchestrator (SO) component executes the specified processes by
351 automating sequences of activities, tasks, rules and policies needed for
352 on-demand creation, modification or removal of network, application or
353 infrastructure services and resources, this includes VNFs, CNFs and PNFs,
354 by conforming to industry standards such as ETSI, TMF.
355 The SO provides orchestration at a very high level, with an end-to-end view
356 of the infrastructure, network, and applications. Examples of this include
357 BroadBand Service (BBS) and Cross Domain and Cross Layer VPN (CCVPN).
358 The SO is modular and hierarchical to handle services and multi-level
359 resources and Network Slicing, by leveraging pluggable adapters and delegating
360 orchestration operations to NFVO (SO NFVO, VFC), VNFM, CNF Manager, NSMF
361 (Network Slice Management Function), NSSMF (Network Slice Subnet Management
364 Starting from the Guilin release, the SO provides CNF orchestration support
365 through integration of CNF adapter in ONAP SO:
367 - Support for provisioning CNFs using an external K8S Manager
368 - Support the Helm-based orchestration
369 - Leverage the CNF Adapter to interact with the K8S Plugin in MultiCloud
370 - Bring in the advantage of the K8S orchestrator and
371 - Set stage for the Cloud Native scenarios
373 In London, ONAP SO added ASD-based CNF orchestration support to simplify
374 CNF orchstration and to remove redundancies of CNF resource attributes and
375 orchestration process.
377 - Support for onboarding ASD-based CNF models and packages in runtime
378 - Support the SO sub-component 'SO CNFM' for ASD-dedicated CNF orchestration
379 to isolate ASD management from other SO components - separation of concerns
380 - Use of ASD for AS LCM, and use of associated Helm Charts for CNF deployment
381 to the selected external K8s Clusters
382 - Use of Helm Client to communicate with external K8S clusters for CNF
384 - Monitoring deployed K8S resources thru Kubernetes APIs
386 3GPP (TS 28.801) defines three layer slice management function which include:
388 - CSMF (Communication Service Management Function)
389 - NSMF (Network Slice Management Function)
390 - NSSMF (Network Slice Subnet Management Function)
392 To realize the three layers, CSMF, NSMF and/or NSSMF are realized within ONAP,
393 or use the external CSMF, NSMF or NSSMF. For ONAP-based network slice
394 management, different choices can be made as follows. Among them, ONAP
395 orchestration currently supports options #1 and #4.
399 **Figure 4: ONAP Network Slicing Support Options**
402 Virtual Infrastructure Deployment (VID)
403 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
405 .. warning:: The ONAP :strong:`vid` project is :strong:`unmaintained`.
406 .. Warning:: The ONAP :strong:'vid' component is no longer part of the ONAP
407 deployment from the London release.
409 The Virtual Infrastructure Deployment (VID) application enables users to
410 instantiate infrastructure services from SDC, along with their associated
411 components, and to execute change management operations such as scaling and
412 software upgrades to existing VNF instances.
414 Policy-Driven Workload Optimization
415 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
416 The ONAP Optimization Framework (OOF) provides a policy-driven and model-driven
417 framework for creating optimization applications for a broad range of use
418 cases. OOF Homing and Allocation Service (HAS) is a policy driven workload
419 optimization service that enables optimized placement of services across
420 multiple sites and multiple clouds, based on a wide variety of policy
421 constraints including capacity, location, platform capabilities, and other
422 service specific constraints.
424 ONAP Multi-VIM/Cloud (MC) and several other ONAP components such as Policy, SO,
425 A&AI etc. play an important role in enabling “Policy-driven Performance/
426 Security-Aware Adaptive Workload Placement/ Scheduling” across cloud sites
427 through OOF-HAS. OOF-HAS uses cloud agnostic Intent capabilities, and real-time
428 capacity checks provided by ONAP MC to determine the optimal VIM/Cloud
429 instances, which can deliver the required performance SLAs, for workload
430 (VNF, etc.) placement and scheduling (Homing). Operators now realize the true
431 value of virtualization through fine grained optimization of cloud resources
432 while delivering performance and security SLAs.
436 Controllers are applications which are coupled with cloud and network services
437 and execute the configuration, real-time policies, and control the state of
438 distributed components and services. Rather than using a single monolithic
439 control layer, operators may choose to use multiple distinct controller types
440 that manage resources in the execution environment corresponding to their
441 assigned controlled domain such as cloud computing resources (SDN-C).
442 The Virtual Function Controller (VF-C) and SO NFVO provide an ETSI NFV
443 compliant NFV-O function that is responsible for lifecycle management of
444 virtual services and the associated physical COTS server infrastructure. VF-C
445 provides a generic VNFM capability, and both VF-C and SO NFVO integrate with
446 external VNFMs and VIMs as part of an NFV MANO stack.
448 .. warning:: The ONAP :strong:`appc` project is :strong:`unmaintained`.
450 ONAP has two application level configuration and lifecycle management modules
451 called SDN-C and App-C. Both provide similar services (application level
452 configuration using NetConf, Chef, Ansible, RestConf, etc.) and lifecycle
453 management functions (e.g., stop, resume, health check, etc.).
454 They share common code from CCSDK repo. However, there are some differences
455 between these two modules (SDN-C uses CDS only for onboarding and
456 configuration / LCM flow design, whereas App-C uses CDT for the LCM functions
457 for self service to provide artifacts storing in App-C Database).
458 SDN-C has been used mainly for Layer1-3 network elements and App-C is
459 being used for Layer4-7 network functions. This is a very loose
460 distinction and we expect that over time we will get better alignment and
461 have common repository for controller code supporting application level
462 configuration and lifecycle management of all network elements (physical or
463 virtual, layer 1-7). Because of these overlaps, we have documented SDN-C and
464 App-C together. ONAP Controller Family (SDN-C / App-C) configures and maintains
465 the health of L1-7 Network Function (VNF, PNF, CNF) and network services
466 throughout their lifecycle:
468 - Configures Network Functions (VNF/PNF)
469 - Provides programmable network application management platform:
471 - Behavior patterns programmed via models and policies
472 - Standards based models & protocols for multi-vendor implementation
473 - Extensible SB adapters such as Netconf, Ansible, Rest API, etc.
474 - Operation control, version management, software updates, etc.
475 - Local source of truth
476 - Manages inventory within its scope
477 - Manages and stores state of NFs
478 - Supports Configuration Audits
480 Controller Design Studio (CDS)
481 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
482 The Controller Design Studio (CDS) community in ONAP has contributed a
483 framework to automate the resolution of resources for instantiation and any
484 config provisioning operation, such as day0, day1 or day2 configuration. The
485 essential function of CDS is to create and populate a controller blueprint,
486 create a configuration file from this Controller blueprint, and associate at
487 design time this configuration file (configlet) to a PNF/VNF/CNF during the
488 design phase. CDS removes dependence on code releases and the delays they cause
489 and puts the control of services into the hands of the service providers. Users
490 can change a model and its parameters with great flexibility to fetch data from
491 external systems (e.g., IPAM) that is required in real deployments. This makes
492 service providers more responsive to their customers and able to deliver
493 products that more closely match the needs of those customers.
497 Active and Available Inventory (A&AI) provides real-time views of a system’s
498 resources, services, products and their relationships with each other, and also
499 retains a historical view. The views provided by A&AI relate data managed by
500 multiple ONAP instances, Business Support Systems (BSS), Operation Support
501 Systems (OSS), and network applications to form a “top to bottom” view ranging
502 from the products end users buy, to the resources that form the raw material
503 for creating the products. A&AI not only forms a registry of products,
504 services, and resources, it also maintains up-to-date views of the
505 relationships between these inventory items.
507 To deliver the promised dynamism of SDN/NFV, A&AI is updated in real time by
508 the controllers as they make changes in the network environment. A&AI is
509 metadata-driven, allowing new inventory types to be added dynamically and
510 quickly via SDC catalog definitions, eliminating the need for lengthy
515 The Policy framework provides policy based decision making capability and
516 supports multiple policy engines and can distribute policies through policy
517 design capabilities in SDC, simplifying the design process.
519 Multi Cloud Adaptation
520 ^^^^^^^^^^^^^^^^^^^^^^
521 Multi-VIM/Cloud provides and infrastructure adaptation layer for VIMs/Clouds
522 and K8s clusters in exposing advanced cloud agnostic intent capabilities,
523 besides standard capabilities, which are used by OOF and other components
524 for enhanced cloud selection and SO/VF-C for cloud agnostic workload
525 deployment. The K8s plugin is in charge of deploying CNFs on the Kubernetes
526 clusters using Kubernetes APIs.
528 Data Collection Analytics and Events (DCAE)
529 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
530 DCAE provides the capability to collect events, and host analytics applications
533 Closed Control Loop Automation Management Platform in Policy (Policy - CLAMP)
534 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
536 .. warning:: The ONAP :strong:`CLAMP` function is now :strong: part of Policy.
538 Closed loop control is provided by cooperation among a number of design-time
539 and run-time elements. The Runtime loop starts with data collectors from Data
540 Collection, Analytics and Events (DCAE). ONAP includes the following collectors
541 : VES (VNF Event Streaming) for events, HV-VES for high-volume events, SNMP
542 for SNMP traps, File Collector to receive files, and RESTCONF Collector to
543 collect the notifications. After data collection/verification phase, data move
544 through the loop of micro-services like Homes for event detection, Policy
545 for determining actions, and finally, controllers and orchestrators to
546 implement actions. The Policy framework is also used to monitor the loops
547 themselves and manage their lifecycle. DCAE also includes a number of
548 specialized micro-services to support some use-cases such as the Slice Analysis
549 or SON-Handler. Some dedicated event processor modules transform collected data
550 (SNMP, 3GPP XML, RESTCONF) to VES format and push the various data into data
551 lake. CLAMP, Policy and DCAE all have design time aspects to support the
552 creation of the loops.
554 We refer to this automation pattern as “Closed Control loop automation” in that
555 it provides the necessary automation to proactively respond to network and
556 service conditions without human intervention. A high-level schematic of the
557 “Closed control loop automation” and the various phases within the service
558 lifecycle using the automation is depicted in Figure 4.
560 Closed control loop control is provided by Data Collection, Analytics and
561 Events (DCAE) and one or more of the other ONAP runtime components.
562 Collectively, they provide FCAPS (Fault Configuration Accounting Performance
563 Security) functionality. DCAE collects performance, usage, and configuration
564 data; provides computation of analytics; aids in troubleshooting; and publishes
565 events, data and analytics (e.g., to policy, orchestration, and the data lake).
566 Another component, Holmes, connects to DCAE and provides alarm correlation
567 for ONAP, new data collection capabilities with High Volume VES, and bulk
568 performance management support.
570 Working with the Policy Framework (and embedded CLAMP), these components
571 detect problems in the network and identify the appropriate remediation.
572 In some cases, the action will be automatic, and they will notify the
573 Service Orchestrator or one of the controllers to take action.
574 In other cases, as configured by the operator, they will raise an alarm
575 but require human intervention before executing the change. The policy
576 framework is extended to support additional policy decision capabilities
577 with the introduction of adaptive policy execution.
579 Starting with the Honolulu-R8 and concluding in the Istanbul-R9 release, the
580 CLAMP component was successfully integrated into the Policy component initially
581 as a PoC in the Honolulu-R8 release and then as a fully integrated component
582 within the Policy component in Istanbul-R9 release.
583 CLAMP's functional role to provision Policy has been enhanced to support
584 provisioning of policies outside of the context of a Control Loop and therefore
585 act as a Policy UI. In the Istanbul release the CLAMP integration was
590 **Figure 5: ONAP Closed Control Loop Automation**
592 Virtual Function Controller (VFC)
593 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
594 VFC provides the NFVO capability to manage the lifecycle of network service and
595 VNFs, by conforming to ETSI NFV specification.
597 Data Movement as a Platform (DMaaP)
598 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
599 DMaaP provides data movement service such as message routing and data routing.
603 UUI provides the capability to instantiate the blueprint User Cases and
608 ONAP CLI provides a command line interface for access to ONAP.
613 .. warning:: The ONAP :strong:`externalapi` project is :strong:`unmaintained`.
615 External APIs provide services to expose the capability of ONAP.
620 ONAP provides a set of operational services for all ONAP components including
621 activity logging, reporting, common data layer, configuration, persistence,
622 access control, secret and credential management, resiliency, and software
623 lifecycle management.
625 ONAP Shared Services provide shared capabilities for ONAP modules. These
626 services handle access management and security enforcement, data backup,
627 configuration persistence, restoration and recovery. They support standardized
628 VNF interfaces and guidelines.
630 Optimization Framework (OOF)
631 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
632 OOF provides a declarative, policy-driven approach for creating and running
633 optimization applications like Homing/Placement, and Change Management
634 Scheduling Optimization.
638 The Security Framework uses open-source security patterns and tools, such as
639 Istio, Ingress Gateway, oauth2-proxy, and KeyCloak. This Security Framework
640 provides secure external and inter-component communications, authentication,
643 Logging Framework (PoC)
644 ^^^^^^^^^^^^^^^^^^^^^^^
646 .. warning:: The ONAP :strong:`Logging Framework` project is a reference
647 implementation :strong:`PoC`.
649 Logging Framework supports open-source and standard-based logging. It separates
650 the application log generation from the log collection/aggregation/persistence/
651 visualization/analysis; i.e., ONAP applications handle log generation only, and
652 the Logging Framework stack will handle the rest. As a result, operators can
653 leverage/extend their own logging stacks.
655 Configuration Persistence Service (CPS)
656 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
657 The Configuration Persistence Service (CPS) provides storage for real-time
658 run-time configuration and operational parameters that need to be used by ONAP.
659 Several services ranging from SDN-C, DCAE and the network slicing use case
660 utilize CPS for these purposes. Its details in
661 :ref:`CPS - Configuration Persistence Service<onap-cps:architecture>`.
665 ONAP provides models to assist with service design, the development of ONAP
666 service components, and with the improvement of standards interoperability.
667 Models are an essential part for the design time and runtime framework
668 development. The ONAP modeling project leverages the experience of member
669 companies, standard organizations and other open source projects to produce
670 models which are simple, extensible, and reusable. The goal is to fulfill the
671 requirements of various use cases, guide the development and bring consistency
672 among ONAP components and explore a common model to improve the
673 interoperability of ONAP.
675 ONAP supports various models detailed in the Modeling documentation.
677 A new CNF modeling descriptor, Application Service Description (ASD), has been
678 added to ONAP since the Kohn release. It is to simplify CNF modeling and
679 orchestration by delegating resource modeling to Kubernetes-based resource
680 descriptors (e.g., Helm Chart).
682 The modeling project includes the ETSI catalog component, which provides the
683 parser functionalities, as well as additional package management
688 ONAP support and collaboration with other standards and open source communities
689 is evident in the architecture.
691 - MEF and TMF interfaces are used in the External APIs
692 - In addition to the ETSI-NFV defined VNFD and NSD models mentioned above, ONAP
693 supports the NFVO interfaces (SOL005 between the SO and VFC, SOL003 from
694 either the SO or VFC to an external VNFM).
695 - Further collaboration includes 5G/ORAN & 3GPP Harmonization, Acumos DCAE
696 Integration, and CNCF Telecom User Group (TUG).
698 Read this whitepaper for more information:
699 `The Progress of ONAP: Harmonizing Open Source and Standards <https://www.onap.org/wp-content/uploads/sites/20/2019/04/ONAP_HarmonizingOpenSourceStandards_032719.pdf>`_
703 ONAP can support an unlimited number of use cases, within reason. However, to
704 provide concrete examples of how to use ONAP to solve real-world problems, the
705 community has created a set of blueprints. In addition to helping users rapidly
706 adopt the ONAP platform through end-to-end solutions, these blueprints also
707 help the community prioritize their work.
711 The 5G blueprint is a multi-release effort, with five key initiatives around
712 end-to-end service orchestration, network slicing, PNF/VNF lifecycle management
713 , PNF integration, and network optimization. The combination of eMBB that
714 promises peak data rates of 20 Mbps, uRLLC that guarantees sub-millisecond
715 response times, MMTC that can support 0.92 devices per sq. ft., and network
716 slicing brings with it some unique requirements. First ONAP needs to manage the
717 lifecycle of a network slice from initial creation/activation all the way to
718 deactivation/termination. Next, ONAP needs to optimize the network around real
719 time and bulk analytics, place VNFs on the correct edge cloud, scale and heal
720 services, and provide edge automation. ONAP also provides self organizing
721 network (SON) services such as physical cell ID allocation for new RAN sites.
722 These requirements have led to the five above-listed initiatives and have been
723 developed in close cooperation with other standards and open source
724 organizations such as 3GPP, TM Forum, ETSI, and O-RAN Software Community.
728 **Figure 6. End-to-end 5G Service**
730 Read the `5G Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_5G_062519.pdf>`_
733 A related activity outside of ONAP is called the 5G Super Blueprint where
734 multiple Linux Foundation projects are collaborating to demonstrate an
735 end-to-end 5G network. In the short-term, this blueprint will showcase
736 three major projects: ONAP, Anuket (K8S NFVI), and Magma (LTE/5GC).
740 **Figure 7. 5G Super Blueprint Initial Integration Activity**
742 In the long-term, the 5G Super Blueprint will integrate O-RAN-SC and LF Edge
745 Residential Connectivity Blueprints
746 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
747 Two ONAP blueprints (vCPE and BBS) address the residential connectivity use
752 Currently, services offered to a subscriber are restricted to what is designed
753 into the broadband residential gateway. In the blueprint, the customer has a
754 slimmed down physical CPE (pCPE) attached to a traditional broadband network
755 such as DSL, DOCSIS, or PON (Figure 6). A tunnel is established to a data
756 center hosting various VNFs providing a much larger set of services to the
757 subscriber at a significantly lower cost to the operator. In this blueprint,
758 ONAP supports complex orchestration and management of open source VNFs and both
759 virtual and underlay connectivity.
763 **Figure 8. ONAP vCPE Architecture**
765 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>`_
768 Broadband Service (BBS)
769 """""""""""""""""""""""
770 This blueprint provides multi-gigabit residential internet connectivity
771 services based on PON (Passive Optical Network) access technology. A key
772 element of this blueprint is to show automatic re-registration of an ONT
773 (Optical Network Terminal) once the subscriber moves (nomadic ONT) as well as
774 service subscription plan changes. This blueprint uses ONAP for the design,
775 deployment, lifecycle management, and service assurance of broadband services.
776 It further shows how ONAP can orchestrate services across different locations
777 (e.g. Central Office, Core) and technology domains (e.g. Access, Edge).
781 **Figure 9. ONAP BBS Architecture**
783 Read the `Residential Connectivity Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_BBS_062519.pdf>`_
786 Voice over LTE (VoLTE) Blueprint
787 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
788 This blueprint uses ONAP to orchestrate a Voice over LTE service. The VoLTE
789 blueprint incorporates commercial VNFs to create and manage the underlying
790 vEPC and vIMS services by interworking with vendor-specific components,
791 including VNFMs, EMSs, VIMs and SDN controllers, across Edge Data Centers and
792 a Core Data Center. ONAP supports the VoLTE use case with several key
793 components: SO, VF-C, SDN-C, and Multi-VIM/ Cloud. In this blueprint, SO is
794 responsible for VoLTE end-to-end service orchestration working in collaboration
795 with VF-C and SDN-C. SDN-C establishes network connectivity, then the VF-C
796 component completes the Network Services and VNF lifecycle management
797 (including service initiation, termination and manual scaling) and FCAPS
798 (fault, configuration, accounting, performance, security) management. This
799 blueprint also shows advanced functionality such as scaling and change
804 **Figure 10. ONAP VoLTE Architecture Open Network Automation Platform**
806 Read the `VoLTE Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNL.pdf>`_
809 Optical Transport Networking (OTN)
810 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
811 Two ONAP blueprints (CCVPN and MDONS) address the OTN use case. CCVPN addresses
812 Layers 2 and 3, while MDONS addresses Layers 0 and 1.
814 CCVPN (Cross Domain and Cross Layer VPN) Blueprint
815 """"""""""""""""""""""""""""""""""""""""""""""""""
816 CSPs, such as CMCC and Vodafone, see a strong demand for high-bandwidth, flat,
817 high-speed OTN (Optical Transport Networks) across carrier networks. They also
818 want to provide a high-speed, flexible and intelligent service for high-value
819 customers, and an instant and flexible VPN service for SMB companies.
823 **Figure 11. ONAP CCVPN Architecture**
825 The CCVPN (Cross Domain and Cross Layer VPN) blueprint is a combination of SOTN
826 (Super high-speed Optical Transport Network) and ONAP, which takes advantage of
827 the orchestration ability of ONAP, to realize a unified management and
828 scheduling of resources and services. It achieves cross-domain orchestration
829 and ONAP peering across service providers. In this blueprint, SO is responsible
830 for CCVPN end-to-end service orchestration working in collaboration with VF-C
831 and SDN-C. SDN-C establishes network connectivity, then the VF-C component
832 completes the Network Services and VNF lifecycle management. ONAP peering
833 across CSPs uses an east-west API which is being aligned with the MEF Interlude
834 API. CCVPN, in conjunction with the IBN use case, offers intent based cloud
835 leased line service. The key innovations in this use case are physical network
836 discovery and modeling, cross-domain orchestration across multiple physical
837 networks, cross operator end-to-end service provisioning, close-loop reroute
838 for cross-domain service, dynamic changes (branch sites, VNFs) and intelligent
839 service optimization (including AI/ML).
841 Read the `CCVPN Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_CCVPN_062519.pdf>`_
844 MDONS (Multi-Domain Optical Network Service) Blueprint
845 """"""""""""""""""""""""""""""""""""""""""""""""""""""
846 While CCVPN addresses the automation of networking layers 2 and 3, it does not
847 address layers 0 and 1. Automating these layers is equally important because
848 providing an end-to-end service to their customers often requires a manual and
849 complex negotiation between CSPs that includes both the business arrangement
850 and the actual service design and activation. CSPs may also be structured such
851 that they operate multiple networks independently and require similar
852 transactions among their own networks and business units in order to provide an
853 end-to-end service. The MDONS blueprint created by AT&T, Orange, and Fujitsu
854 solves the above problem. MDONS and CCVPN used together can solve the OTN
855 automation problem in a comprehensive manner.
859 **Figure 12. ONAP MDONS Architecture**
861 Intent Based Network (IBN) Use Case
862 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
863 Intent technology can reduce the complexity of management without getting into
864 the intricate details of the underlying network infrastructure and contribute
865 to efficient network management. This use case performs a valuable business
866 function that can further reduce the operating expenses (OPEX) of network
867 management by shifting the paradigm from complex procedural operations to
868 declarative intent-driven operations.
872 **Figure 13. ONAP Intent-Based Networking Use Case**
874 3GPP 28.812, Intent driven Management Service (Intent driven MnS), defines
875 some key concepts that are used by this initiative. The Intent Based Networking
876 (IBN) use case includes the development of an intent decision making. This use
877 case has initially been shown for a smart warehouse, where the intent is to
878 increase the output volume of automated guided vehicles (AVG) and the network
879 simply scales in response. The intent UI is implemented in UUI and the
880 components of the intent framework interact with many components of ONAP
881 including SO, A&AI, Policy, DCAE and CDS.
885 The virtual firewall, virtual DNS blueprint is a basic demo to verify that ONAP
886 has been correctly installed and to get a basic introduction to ONAP. The
887 blueprint consists of 5 VNFs: vFW, vPacketGenerator, vDataSink, vDNS and
888 vLoadBalancer. The blueprint exercises most aspects of ONAP, showing VNF
889 onboarding, network service creation, service deployment and closed-loop
890 automation. The key components involved are SDC, CLAMP, SO, APP-C, DCAE and
891 Policy. In the recent releases, the vFW blueprint has been demonstrated by
892 using a mix of a CNF and VNF and entirely using CNFs.
894 Verified end to end tests
895 -------------------------
898 Various use cases have been tested for the Release. Use case examples are
899 listed below. See detailed information on use cases, functional requirements,
900 and automated use cases can be found here:
901 :doc:`Verified Use Cases<onap-integration:docs_usecases_release>`.
903 - E2E Network Slicing
904 - 5G OOF (ONAP Optimization Framework) SON (Self-Organized Network)
905 - CCVPN-Transport Slicing
907 Functional requirements
908 ^^^^^^^^^^^^^^^^^^^^^^^
909 Various functional requirements have been tested for the Release. Detailed
910 information can be found in the
911 :doc:`Verified Use Cases<onap-integration:docs_usecases_release>`.
915 - ONAP CNF orchestration - Enhancements
916 - ONAP ASD-based CNF orchestration
920 - Lifecycle Management
922 - Policy Based Filtering
923 - Bulk PM / PM Data Control Extension
924 - Support xNF Software Upgrade in association to schema updates
925 - Configuration & Persistency Service
933 - ETSI-Alignment for Guilin
934 - ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES
935 - Extend ORAN A1 Adapter and add A1 Policy Management
937 - NFV testing Automatic Platform
939 - Support for Test Result Auto Analysis & Certification
940 - Support for Test Task Auto Execution
941 - Support for Test Environment Auto Deploy
942 - Support for Test Topology Auto Design
946 The ONAP platform provides a comprehensive platform for real-time, policy-
947 driven orchestration and automation of physical and virtual network functions
948 that will enable software, network, IT and cloud providers and developers to
949 rapidly automate new services and support complete lifecycle management.
951 By unifying member resources, ONAP will accelerate the development of a vibrant
952 ecosystem around a globally shared architecture and implementation for network
953 automation —with an open standards focus— faster than any one product could on
958 See the Resources page on `ONAP.org <https://www.onap.org/resources>`_
960 .. |image1| image:: media/ONAP-architecture.png
962 .. |image2| image:: media/ONAP-fncview.png
964 .. |image3| image:: media/ONAP-securityFramework.png
966 .. |image4| image:: media/ONAP-NetworkSlicingOptions.png
968 .. |image5| image:: media/ONAP-closedloop.png
970 .. |image6| image:: media/ONAP-5G.png
972 .. |image7| image:: media/ONAP-5GSuperBP-Integration.png
974 .. |image8| image:: media/ONAP-vcpe.png
976 .. |image9| image:: media/ONAP-bbs.png
978 .. |image10| image:: media/ONAP-volte.png
980 .. |image11| image:: media/ONAP-ccvpn.png
982 .. |image12| image:: media/ONAP-mdons.png
984 .. |image13| image:: media/ONAP-IntentBasedNetworking.png