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